A Process By Any Other Name...: Applying Information Architecture with bridges, cooking & hardware
Upcoming SlideShare
Loading in...5
×
 

A Process By Any Other Name...: Applying Information Architecture with bridges, cooking & hardware

on

  • 2,896 views

This is my presentation from the 2006 IA Summit in Vancouver, BC. The summary is that the practice of IA is not about artifacts but the thinking that goes into them and the way you assess which ...

This is my presentation from the 2006 IA Summit in Vancouver, BC. The summary is that the practice of IA is not about artifacts but the thinking that goes into them and the way you assess which artifacts to use.

Statistics

Views

Total Views
2,896
Views on SlideShare
2,891
Embed Views
5

Actions

Likes
4
Downloads
46
Comments
0

2 Embeds 5

http://www.slideshare.net 4
http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-NoDerivs LicenseCC Attribution-NoDerivs License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

A Process By Any Other Name...: Applying Information Architecture with bridges, cooking & hardware A Process By Any Other Name...: Applying Information Architecture with bridges, cooking & hardware Presentation Transcript

  • Adam Polansky Lead Information Architect Travelocity.com A PROCESS BY ANY OTHER NAME… Applying Information Architecture With Bridges, Cooking & Hardware
  • Some bridges occur naturally
  • Some bridges occur intuitively
  • Some bridges extend from their environments
  • Some bridges augment their environments
  • Some bridges are purely functional
  • Some bridges are aesthetic
  • Some bridges are used for people
  • Some bridges are not
  • Some bridges take on purposes for which they weren’t intended
  • Worse Thing: Push-back because time needed for artifacts seen as bottle-neck Bad Thing: Misguided demand for a process based on artifacts. Good Thing: IA is becoming recognized in more firms. THERE AIN’T NO RECIPE!
  • Shhhhhh! Matters not…. the process does
  • Every development process includes three basic areas of activity. The job of the IA is to find ways to close the gaps between them COMMON FOR ALL PROCESSES Idea Plan Build IA IA
  • So there’s this guy….
  • Origin Info Vehicle Destination Disposition INFORMATION TRANSFER
    • Look at these elements.
    • Characterize the forces that act
    • upon them.
    • Decide what you can do to bridge
    • the communication gaps.
  • Domain Expertise Institutional Knowledge System Constraints Location of Resources New Development New Technology Mature or Existing Product Skill Sets Time Cost Quality CHARACTERIZATION FORCES Size of Team
    • Annotated Wireframe
    • Annotated Mock-ups
    • Narrative Document
    • Interaction-Level Spec
    FACTORING FORCES IN Idea Plan Build IA IA
    • Conversation
    • White board
    • Thumbnail Sketch
    • Process Flow
    • Site Map
    • Lo-Fi Wireframe
    • Hi-Fi Wireframe
    • Interactive Wireframe
    FORCES? FORCES?
    • IF:
    • The team is small
    • They’ve all worked together on the product before
    • They’re all located in the same room
    • Time is short (but reasonable)
    • The features exist elsewhere in same site
    • Documentation exists from previous projects
    • THEN:
    • White-board session to see where high level changes occur
    • Tactical Wireframes to model the functionality
    • Annotated Screen shots from existing product to show where changes occur
    FACTORING FORCES IN Idea Plan Build
    • BUT… IF:
    • The team is small
    • Some of them worked together on the product before
    • Some of them are located in Bangalor and they are new to the team
    • Time is short (but reasonable)
    • The features are new to the site
    • No documentation exists from previous projects
    • THEN:
    • Process Flows to see where high level changes occur
    • Tactical Wireframes to model the functionality
    • Detailed functional spec to include screen shots and interaction details
    FACTORING FORCES IN Idea Plan Build
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  • It’s not the process. It’s not the tools. It’s the practitioner. Choose artifacts based upon your understanding of the forces that will affect communication
  •