He was referring, of course, to wireframes, though at the time we called them page schematics. We’d been burned too many times, and it started creating a rift between the visual designers and me. A wireframe, as you probably know, describes the contents of a web page by illustrating a mock layout. Usually wireframes are rendered in some kind of drawing program, like Visio or Illustrator, but can also appear as bitmaps or even HTML.
It would have been easy for me to resent the directive. After all, I’m an IA, that’s what we do! But I could see the value in his suggestion, particularly since I’d experienced conflict on projects where I’d trod a bit too heavily on designers’ toes.
The conflict arose after clients had seen the wireframes. The layout, even explicitly caveated, would set their expectations, and they did not appreciate screen designs that strayed too far from them, no matter how carefully crafted. Clients also struggled to talk about information priorities, taxonomies, and functionality. Placing these concepts in a layout made them more accessible, but our conversations were too tactical, and their feedback had more to do with design than with structure.
We tried using wireframes as a strictly internal tool: no client viewing allowed. But as much as a wireframe helped designers visualize the functionality and interaction of the site, it cramped their style. Designers who stuck close to the wireframes did not exercise their creativity, and all our sites started to look the same.
These are the two main risks associated with wireframes: client expectations and designer innovation. (There are others. See below.) While strategies exist to mitigate these risks, they are not 100% avoidable. When the creative director asked me to “take design out of IA,” I had to make a choice:
I could pursue risk mitigation strategies, learning how to set client expectations better and work with designers to avoid compromising their creativity.
I could develop a different approach to documenting information architecture, one that would avoid these issues completely. Devising a way to communicate issues that sit squarely in my court means no more conflict with designers over client expectations or layout. Such an approach would also force clients (and designers for that matter) to talk about content, priorities, and functionality —the issues we needed to address in early stages of the project.
The first option felt desperate, as if I were the little boy trying to plug the dam with no end in sight to the number of leaks. (In college, I took a class in social ethics. The professor, Gary Comstock, once said that if people are fighting over pie, make a bigger pie.)
It was on the redesign of USAirways.com in 1999 that I decided to try a different approach. After building a site map, which described the relationships between the web pages, I created the first “page description diagram” —a bigger pie, as it were.
In a page description diagram, the content areas of the page are described in prose, as in a functional specification. The content area descriptions are arranged on the page in priority order. Typically, I will define the horizontal axis of the diagram as the page priority. Thus, content areas described on the left side of the page are higher priority than those on the right side of the page.
With this approach, the diagram represented the two main issues: priority and content. I found that I could include layouts of individual content areas to show, for example, how the “check flight status” form might look. These mini-layouts helped our client visualize the interactivity, but did not lock the designer into any particular approach. Our conversations with the client focused on the nature of the content and functionality and the relative priority of the page contents.
On this particular project, the art director appreciated the approach. He found he could focus more on creating a synergy between the brand and the functionality, rather than being forced into wrapping colors around a predetermined layout. At the risk of speculating on his thoughts too much, I wonder if he had to spend less effort than he would have with a wireframe, which predisposed him to a particular layout.
The page description diagram, by demonstrating priorities and providing a context for the content and functionality, gives visual designers the information they need to create an effective layout. On any given web page, a piece of information can have more or less visual weight depending on the use of color, contrast, typography, and position. But these are the tools of a visual designer, the fundamentals of graphic design, and no business of the information architect.
If a project requires an information architect, the scale of information must be vast. Without a person who understands the nature of the information, other people on the team would spend their valuable time trying to get their heads around it, preventing them from focusing on their own tasks. Information architects who have to worry about layout are distracted from their tasks: defining functionality, content, and structure.
Ultimately, designers are paid because they are good at thinking about visual relationships. Presumably, an information architect focuses on relationships among information, categories, and content, not among shapes, color, and contrast. The page description diagram is a tool to allow designers and information architects to stay comfortably within their own realms without compromising communication.
(This idea, of course, reopens the “defining the damn thing” discussion. Perhaps some definitions of information architecture include page layout, but as a creative director who must consider the interests of both architects and designers, I need to draw a discrete line between the two.)
Whenever I show a page description diagram to designers, they love it. It provides more information without compromising their processes. Information architects, on the other hand, have mixed responses. Some latch onto the concept, eager for some relief from common project problems. Others do not see value in the approach, perhaps because they have not faced the same issues, or perhaps because they have associated their craft with wireframes, they cannot conceive of one without the other.
Page description diagrams do not have to replace wireframes. Indeed, if we are to grow as a craft, we must find additional means for communicating information architecture ideas. Just as laptop computers and desktop computers do similar things but are used in different situations, wireframes and page description diagrams can also peacefully coexist as useful information architecture tools.
|The Pros and Cons of Wireframes
These lists originally appeared on the poster I presented at the ASIS&T 2002 IA Summit in Baltimore, “Where the Wireframes Are: The Use and Abuse of Page Layouts in the Practice of Information Architecture.” You can find the poster at http://www.greenonions.com/dan/portfolio/
|Dan Brown has been practicing information architecture and user experience design since 1994. Through his work, he has improved enterprise communications for Fortune 500 clients, including US Airways, Fannie Mae, First USA, British Telecom, Special Olympics, AOL, and the World Bank. Dan has taught classes at Duke, Georgetown, and American Universities and has written articles for the CHI Bulletin and Interactive Television Today.