a process by any other name...: applying information architecture with bridges, cooking &...

Post on 06-Dec-2014

2.944 Views

Category:

Business

4 Downloads

Preview:

Click to see full reader

DESCRIPTION

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.

TRANSCRIPT

Adam PolanskyLead 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 Some bridges take on purposes for which purposes for which

they weren’t intendedthey 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!Shhhhhh!

Matters not…. the process does

Idea

12°

9'

4'

45'

Plan Build

Every development process includes three basic areas of activity.

The job of the IA is to find ways to close the gaps between them

IA IA

COMMON FOR ALL PROCESSES

So there’s this guy….

Origin

Info

Vehicle DestinationDisposition

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

TimeCostQuality

CHARACTERIZATION FORCES

Size of Team

Idea

12°

9'

4'

45'

Plan Build

IA IA

• Annotated Wireframe• Annotated Mock-ups• Narrative Document• Interaction-Level Spec

• Conversation• White board• Thumbnail Sketch• Process Flow• Site Map• Lo-Fi Wireframe• Hi-Fi Wireframe• Interactive Wireframe

FORCES? FORCES?

FACTORING FORCES IN

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

12°

9'

4'

45'

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 projectsTHEN: • 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

12°

9'

4'

45'

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

top related