In a recent blog post, Garret Dimon claims to be hot on the trail of something fabulous:
I donâ€™t have the details worked out yet, but Iâ€™m slowly putting together a vision of how we can really document web applications in a pragmatic way. The primary driver is to create something that people can understand, and to make documents that engineers actually look forward to using. Itâ€™s a hybrid of wireframes, page description diagrams, and functional specs.
I call this the “Holy Grail of Interaction Design. It’s a versatile, powerful, and entirely mythical document format that almost every IA has fantasized about. Depending on who you talk to, embodies most or all of the following qualities:
- It combines site mapping, process flow logic, and wireframeing into a single entity
- It allows atomic-level interface modules to be modified or replaced globally
- It is accessible via a web browser
- It can be printed
- It simulates the user experience via click-throughs from page to page or feature to feature
- It permits extensive feature annotation for programmers, bordering on functional specifications
- It is fast and fluid for the document creator
But I don’t think so any more. Until someone actually shows us the goods, I’m not holding my breath.
Designing for Communication
The term “information architect” was coined in the 1970’s by Richard Saul Wurman, who was talking very narrowly about the art of making charts, graphs, and diagrams that communicate dense information in efficient and effective ways. Think of the charts you see in USA Today or in science magazines illustrating, for example, “How the Internet Works”, or maps showing the state-by-state party breakdown in the last presidential election — that’s Wurman-style information architecture.
These old school designers, who today we’d call “information designers”, don’t just pick up a template every time they are given a new assignment. Instead they make up their design from scratch every time, drawing on their long experience but also utilizing a broad array of design techniques, tools, and visual languages.
Today’s information architects and interaction designers aren’t simply charged with the job of “coming up with good ideas”, or “documenting structures”… we are supposed to be communicating these ideas and structures to our teammates who need to understand them as deeply as we do.
Most IAs, however, begin their design process by opening up a document template and starting to execute sitemaps, flowcharts, and wireframes. Sometimes there are fancier models in the toolkit, too, such as mental maps and user scenarios, but even these formats are often approached by opening templates and filling them in. More often than not, we deliberately avoid “re-inventing the wheel”.
But why not re-invent the wheel now and then? What happens when the best way to communicate a structure simply isn’t among the tools in the templated toolkit? Is a site map the best way to communicate the critical fact that 90% of a site’s features requires a user to register, or can this be done in a simpler, unique new site diagram?
And what happens when the templates don’t fit the project’s needs? Does every site map need to avoid documenting the content within each page? Do site maps and wireframes need to be separate documents? Does a user persona have to just describe one person? Would a comic book-like storyboard do a better job of communicating an RIA’s functionality than a simple wireframe?
One of the best things about being a manager is my ability to interview information architects and look at their deliverables. I love it when a candidate shows me something I’ve never seen before, a design technique that they invented just to solve a particular problem for a particular project — in fact, several of the examples I described above I have seen in candidate portfolios.
Every client/project is unique. We simply cannot assume that any deliverable template will work for every job. Templates are great for “normal” design tasks, but more and more interaction design tasks simply aren’t normal.
This is the first reason why the Holy Grail will never be found.
Designing for Use
Another argument against the Holy Grail is that it may not even be usable for the designers and information architects who need to create the documentation in the first place.
Here’s a list of the tools I use to generate interaction designs:
- Sketching with pen and paper
- Whiteboarding concepts and structures
- Writing text descriptions of concepts
- Making documents in Visio, Word, OmniGraffle, Powerpoint, etc.
- Making documents in Illustrator, Photoshop, etc.
- Making and testing low-fi clickthrough prototypes
- Making and testing functional prototypes
- Building, testing, and revising the real end product
As you go down this list, the power and level-of-detail of each deliverable increases. But the ability to create or revise those deliverables decreases at the same time. It’s a lot easier to radically revise a whiteboard sketch than to do the same kind of revision to an Illustrator document.
In fact, one of the reasons many people like to use Visio or OmniGraffle instead of Illustrator to make flowcharts and site maps is that these programs are far better at permitting rapid changes to be made to the structure of the content on the page. The results aren’t pretty, but you can drag boxes around all day long and they will stay connected no matter how convoluted your flow becomes. You can radically revise your design ten times in as much time it would take an Illustrator user to revise their diagram once.
This is what I mean by “use”: The primary use of some design tools is to allow fast-and-loose changes to be made early on in the design process, before you become too committed to those design decisions.
In this sense, Visio/OmniGraffle resembles the low-fi fluid process of drawing with pencil and paper, where Illustrator resembles pen-and-ink drawing, or even painting with brushes. The farther down the list you go, the harder it is to iterate and improve your ideas — and the more likely you are to become irreversably attached to the ideas you’ve already documented.
Designing a System vs. Building a System
Another observation you might make about the list above is that the further down the list you go, the closer you are to actually building the final product. This is, to me, another problem with the Holy Grail: in pumping so many features into this imaginary documentation medium, we’re just not designing any more — we’re building.
Here’s an anecdote: Years ago I was designing an epic CD-ROM adventure game. The game involved hundreds of plot and script branching points, and it was a challenge to document and track all of these changes. We were documenting these branches using flowcharts and word-processor text documentation, but at one point I had a brilliant idea: “Let’s make a Microsoft Access database to store every one of the 500+ plot elements, with each element dynamically linked to the other elements via a rich Visual Basic user interface, with buttons and fields to let us author and browse the documentation almost as if we were playing the game itself.”
That’s the problem right there: We tried so hard to make the documentation feel like the game that we ended up spending days building the documentation tool and continually coming up with new features for the tool to support new ideas we had for the game itself. We were, in fact, doing the same work the programmers were doing. We were programming a game. It was insane.
Documentation needs to be kept simple enough to support fluid and rapid changes, and it shouldn’t be confused with prototyping, or worse, implementation.
Be Creative by Re-Inventing the Wheel
It all comes down to creativity: Our documents need to support our creativity. They need to be able to radically change at any time to permit new and unique project demands. The simpler the document format or template, the more likely it is to be able to be adaptable to new and innovative ways of thinking about our products.
Also, we need to be creative about the documents themselves. We need to create more and more new documentation formats and solutions. Garret Dimon’s quest is, actually, driven by this same motivation to build a better mousetrap. Where it is possibly misguided, I think, is that it pretends to be a Swiss Army Knife solution, a jack of all trades.
Instead we should all be constantly ready to invent a new template, a new deliverable, or a new process for creating effective interaction design documentation.
Maybe that’s the real Holy Grail.
UPDATE: Here’s a cool site documenting a hundred different techniques of visual communication, from Flow Charts to Gantt Charts to Zwicky’s Morphological Box(!). How many of these, or combinations of these, do you use on a typical IA project?