Thanks again to Alan Musselman at Adobe!

I recently wrote about how I had high hopes for Fireworks CS3, in part because of how the prototyping process had been integrated into the design process, and because of the generally increased integration between former Macromedia products and Adobe products. But alas, after having now worked with the tool for a while, it turns out that, at least for now, FW will not be added to my design toolbox. But why oh why you say? After all, with the new version, it’s so easy to sketch out some ideas, hotlink them together into pages, and post it for discussion (I was able to crank out some simple prototypes literally in minutes.)

Well, as it happens, one seemingly innocuous missing feature spelled the end of my short (but intense) love affair with Fireworks CS3: no inline styling of text boxes. Huh? Why would that be such as big deal? Well, here take a look at this example:

So here we’ve got a snippet from a pretty generic contact form wireframe. Notice the privacy policy link. I was working on this wireframe and wanted to add this seemingly simple little text link. The only way I was able do it was by placing any differently styled text in its own layer. Not good if you’ve got loads and loads of these links on a page, like on a search results page, for example. Here is a snippet from a wireframe of one:

Ok, so this one is pretty crazy-busy, but even so, having this many links on a page is not out of the question. Can you imagine having each of them in their own layer?! FW apparently treats text boxes as the most granularly defined object, so for example if you want to apply a style, you have to apply it to the whole block of text. Considering how critical the ability is to control the style of virtually every character on a page is in the world of modern user interface design, I’m very surprised that FW doesn’t have better support for this, especially considering that old clunkers like Visio have amazing formatting capabilities (clunky to do sometimes, but at least you can do it.) Hopefully, better support for this will be part of a future version of FW. Or, more likely, someone somewhere will figure out a hack for getting around this issue….

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.