Information Architecture

Think of the role a regular architect plays in building a house. That's the role an information architect should play on web projects. She knows about all aspects of building. Structural engineering, plumbing, electrical wiring. If she's good she knows how to lead and communcate with all the people who are working for her client—the plumbers, the electrical contractors. You get the idea.

To our way of thinking a good information architect needs to have the same level of knowledge about web sites that a traditional architect has about buildings.

But good information architects are also usability geeks. This means they have spent a lot of time wathcing real people use web sites. We think that this "time in the field" is the only way to gain a deep understanding of human cognitive and motor abilities (or to put it simply: to get a clear idea of what people can and can't do easily).

Developing a real world web application can get complicated fast. For the same reason you wouldn't hire a general contractor to design and build your house, you don't want a visual designer, programmer, or other specialist to oversee your development process. We're not talking project management here. We're talking about making sure the design (what the user experiences) fulfills the business goals of the application in every detail.

An IA is a designer in the broadest sense. IAs should have a lot of experience solving tough design problems in multiple industries. IA's have to have a clear understanding of what the technology can do. IA's have to have a clear understanding of what the user is capable of.

Until information architecture is taught with the same rigor that traditional architecture is taught in universities (there's a reason getting a BA in architecture is called "architorture"), hard won experience in the trenches has been our only certification process.

That said there are some things every information architect must know.

• How to translate business goals into user experiences
• Anything "Web 2.0" (social media and otherwise)
• What AJAX is and what it does to the user interface
• How to design and run a usability study
• How to write clearly and efficiently
• How to draw clearly and efficiently
• How to storyboard, craft user personas and otherwise get inside users heads
• Have a clear understanding of the unique problems faced by developers, copywriters, and visual designers
• Have the ability to lead developers, copywriters, and visual designers
• Be able to execute beautiful and cohesive and at times subversive visual designs to achieve the business intent of communication

It's time for a manifesto. Because the world needs more manifestos!

Something has happened in the last 10 years. People (and we mean everyone) have lost their patience for bad design in all its forms. Remember how we used to blame ourselves (well maybe you didn't but some of us did) when we had trouble figuring out something on our computers? We said it was user error. We thought we needed training (as though we were circus animals!).

Well, times have changed. Less and less, people blame themselves when something goes wrong. Instead they just say "This website sucks!" and return to Google to find another one.

Well, how did we get here?

Our personal bandwidth is at capacity. All of these gadgets we once thought were going to save us time and simplify our lives have only conspired to make our lives more complicated.

How much time did I spend trying to get Bluetooth set up for my wife's Blackberry because the Dell laptop had the wrong Bluetooth stack? About an hour. Did I figure it out? No. Will I try to do it again, ever? Probably not. USB works well enough.

This is time I could have spent with my kids. This is time that was stolen from me by bad design. All around the world people are waking up to this.

Information architects to the rescue!

We promised a manifesto so here it is. People who build radically simple web sites recognize and practice the following things.

• Bad design steals life
• User goals fulfill business goals
• Simplification does not always mean taking things away; sometimes messages/cues need to be added to clarify
• Any process, no matter how simple it is, can probably be simplified more
• Simplification is a moving target (other sites are getting better all the time)
• It is possible and essential to measure the relative simplification of a process against other similar processes

Just as a traditional architect focuses on producing blueprints, elevations and other forms of documentation, an information architect focuses on producing a series of documents that communicate how complex sites should be developed. Good information architects create documents that produce the maximum communication for the least cost and consider this to be a key aspect of their craft. These documents include the following.

• Personas and scenarios
• Page flow diagrams (for multi-page processes)
• Wireframes (page layout and flow)
• Content strategy and tactics
• Functional prototypes
• Visual design comprehensives

Just as with a traditional architect, figure 5-10% of total construction costs.

We've been doing web work for almost 15 years (yes it's almost been that long!) and know the process, technology, and most importantly the users, through and through. Another way of putting it is we know all the ways teams and technology can go wrong, and we have the battle scars to prove it. Did we mention we're on a mission?