information architect

I call myself an information architect. I don’t use it exactly the same way as Wikipedia defines it, but since there are similarities, I’ll start there:

Information architecture (IA) is the structural design of shared information environments; the art and science of organizing and labelling websites, intranets, online communities and software to support usability and findability; and an emerging community of practice focused on bringing principles of design and architecture to the digital landscape. Typically, it involves a model or concept of information which is used and applied to activities that require explicit details of complex information systems. These activities include library systems and database development. –Wikipedia

I read this definition as more of a software systems designer, kind of similar to a software architect.

This doesn’t quite fit my definition, because I’m not a hard-core programmer (although I did start programming 45 years ago at the age of 6 on a 6502 Jolt kit computer: pre-Apple I.)  I didn’t study Computer Science in school. I’ve been programming my entire career, but I’ve always focused on the user experience, and have focused exclusively on client-side software. This has guided me more toward script-based platforms, and since the Internet, I’ve focused on JavaScript, Flash, Adobe Flex, CSS, XML, XSLT… you get the idea. I just believe that focusing on the user experience is my unique value-add.

But my definition of “information architecture” transcends the realm of software.

Here is my definition:

Ideas have shape. A mental model of an idea can be created in a single consciousness, and transferred to others, though a process of discovery, diagramming, analyzing, and discussing. Sometimes an idea feels like it can be fully documented, and sometimes big areas of the idea are left to other parties to figure out. But architected ideas include the ‘why’: the big picture of where this concept fits into the next larger system of thought. And they include the concrete: the details of that make this realizable in the world, and therefore give it credibility. For years, I’ve described ideas like a blob, floating above the table we share when we discuss and deliberate, listen and argue. We can spin the blob, seeing it from different perspectives, flipping the axis, or discovering the N-dimensions that may be required to see it in adequate clarity.

I would agree with the Wikipedia definition in these aspects:

• These ideas are usually complex (and real-world.)
• Labeling is key: the process of categorizing, organizing aspects of an idea into mental buckets, is vitally important.

Ideas that need architecting can be seen as ‘problems’ needing solutions, in which case the both the problem and the solution may need to be analyzed and ‘architected’, and then the solution needs to fit the problem like a 3D Tetris.

Ideas that need architecting transcend a single consciousness. The first goal is to build a shared mental model, and that involves the concretizing of the idea into documentation.

Ideas that need architecting can’t be merely described in prose. Diagrams are key. Ideally diagrams should be able to ‘zoom’ from the macro view to the micro view, the why and the concrete, and then back to the macro view quickly to re-affirm the big picture. I use Prezi for this: not as a slideshow replacement, but as an interactive, sharable whiteboard with infinite zoom capabilities (I should do another post about this!) I also use colored pens to draw words and lines on pure white sheets of loose paper. The colors convey multiple dimensions, as well as provide a more memorable visualization. Words are key, even more important than little stick-figures or other visual representation. I say that a word is worth a thousand pictures. Put a word on a piece of paper in the middle of the table, and soon everyone is pointing to it and saying “this,” and everyone sees how “this” is connected to “that.” A new shorthand language appears spontaneously, and the team is actively developing a shared mental model.

Every discussion of consequence that uses language can be a candidate for information architecture, including politics, religion, history, and the arts. As an anti-example, pure art transcends language: for example, words only hint at the emotive expression of dance, and Taoism explicitly transcends words. Love transcends language so it is also not a good candidate, although that is an interesting idea: maybe if more of us had a clear mutual understanding our deepest relationship, many practical long-term benefits are possible.

Sidebar: I’ve realized I’ve violated my rule of information architecture! I described it in prose without diagrams and examples! Most of my best info design has been with medical customers with proprietary information, so I can’t share them as-is. I’ll have to rectify this in my next post!

Here is one trivial example of the micro/macro view: a photograph I took this morning:

Lupine on Table Mountain

What do I like about this photo? The crisp detail of a single flower is a micro view, very real and concrete. But it has its place in a vast field of flowers, which would merely be a wash of color without the micro view. And it has a relationship to the macro view (not as in “macro photographic lens”, but as in big-picture view) which is the moment of sunrise, which gives a sense of place and meaning to the flower. Your eye naturally flows around the photo: back and forth between the flower in focus, and the sun, and the tree, and the other close-up flowers, and the sun, circling around and around.

The micro view gives credibility to all the other flowers: you trust that you can understand each one of them without needing to zoom to each element. A manager will only look at one detail in a big picture: when she finds that the detail is adequate, then she assumes that all the other details are in good order and leaves them to her subordinates because she can trust them on the basis of the single well-documented detail.

The macro view becomes the story within which I can mentally file away the detail. In a Montessori classroom, a timeline rings the room’s walls right up against the ceiling. And every history lesson starts with students finding its time period on the timeline. This gives a mental filing-place for the lesson, and relationships are seen and remembered. An abstract history lesson without a proper context would be confused and forgotten, similar to what happens in many less-inspired classrooms.

By this point, I’ve spent many years doing information architecture. I do aspects of this at every meeting: if something is worth discussing, it is worth documenting and understanding. I try to see every meeting as an opportunity to create a shared, concrete, meaningful mental model. And that is how I define Information Architecture.