in General Coding

A few nails in the coffin for using Visio to specify web pages

To say Visio is the wrong tool for specifying web pages just doesn’t seem to make any sense. After all, Visio is probably the software most commonly used among information architects for communicating content and interaction on web pages. But after years of using Visio, I have found it to be an increasingly unreasonable choice for specifying evermore sophisticated websites, to the point where Visio (or drawing-based programs in general) no longer is my tool of choice for specifying web pages. Here are some reasons why:

Sorry, no recycling

Rework (not to be confused with iteration) is about as close as you can get to a deadly sin in software development. By producing wireframes in Visio, which generally are delivered as images (perhaps embedded in a Word document or in a PDF file), the IA is essentially guaranteeing rework. Nothing produced in Visio can (easily) be reused by other team members, meaning that they have to waste time recreating everything already produced by the information architect. This means that content such as labels and interface copy included in the wireframe will need to be retyped by the developer and/or the visual designer, which inevitably leads to typos and more rework.

Do you speak wireframe?

Many IAs proclaim the virtues of wireframes by calling them blueprints, evoking the precisely drawn schematics used in the world of physical architecture. Unfortunately, while blueprints are based on a standardized notation, virtually every IA has their own flavor of wireframe. This, in turn, means that team members are tasked with interpreting wireframes and translating their content into the world of the web. In some cases, this is pretty straightforward, such as producing a basic form from a wireframe. But too often, this means that what the IA meant and what in fact gets built turn out to be two very different things, which essentially defeats the fundamental purpose of the specification, in which a core principal is to be as unambiguous as possible.

Design compfusion

Ever received a question from a team member to the effect of “should I refer to the wireframe or the comp when building this feature?” What they’re really telling you is that there is redundancy problem. One likely reason you are being asked this is because wireframes, since they are visual representations, inherently will contain some form of layout information, and that layout information may or may not be the same as what is appearing in the comp. This seemingly innocent question begs a larger and more fundamental question regarding the role of information architects: should information architects be in the business of specifying visual design at all? Aren’t they first forcing the visual designers hand by, say, using a 3-column layout in their wireframe? Wouldn’t it be better if wireframes contained no layout information, and that was instead defined only in the design comp? This question, of course, flies in the face of the idea behind a wireframe, but it is one that needs to be asked. Regardless of the answer, continuing to use wireframes as a specification reference after comps have been produced almost guarantees confusion among team members. Once the comp has been produced, those annotations are better served referencing the comp.

Undefined is ill defined

Wireframes do not easily allow for specifying a lot of elements that, in my view, should be specified by the information architect, such as window properties (what should happen when the user resizes the window?), and content types (this one is more doable, but can become arduous to keep consistent across multiple templates in Visio.) Some might say that this information does not belong in a wireframe, or that it is not the job of the IA to define it. Whether or not it’s the job of the IA is less important than whether or not it belongs in a wireframe.  A good specification of a web page or template should be comprehensives, i.e. everything that the person implementing that page needs to know should either be contained directly in that specification, or there should be cross-reference to the additional specification information, such as for global elements.

Think about information architecture, not about Visio

Maintaining Visio wireframes, despite efforts to modularize and streamline, can be seriously hard work – and much of that time is spent wasting your time tackling the notoriously buggy and quirky Visio software. How Visio works has nothing to do with your information architecture. Yes, there are alternatives to Visio like Omnigraffle, but you’re still spending your time thinking about how to use Omnigraffle than about information architecture.In light of the issues raised here, I am increasingly mystified by why so many information architects still cling to Visio. Is it just because that is what they assume everyone else is using so they figure they have to use it too? Or is it because they think that is what their organization requires or expects that they use? My hunch is that many information architects are using Visio because that is the tool they are comfortable with and may not really be aware of the above-described havoc they are wreaking. I am far from the first to proclaim that wireframes should cease and desist. Christina Wodtke, Nate Koechley, Thomas Vander Wal, and others, have been pleading with information architects to stop making wireframes for some time. And to be clear, I am not talking about Visio as a design tool (a personal choice), or as a tool for producing flowcharts and site maps. That is a separate discussion. This is specifically about wireframes, web pages, specifications. As web sites become increasingly sophisticated, in turn raising the bar of expectations of user experience quality, all while project lifecycles continue to grow shorter and simultaneously more demanding, I think it will become increasingly difficult for IAs to continue using Visio and still remain competitive.