Wireframes: Unpacking the Boxes
As with any marriage, designers and information architects put a lot of effort into making it work. There are highs and lows - ultimately, we need each other. But set us down together on the therapist's couch, or the project post-mortem meeting, and the same old grievances are aired. It's goes something like this: clients want to see something they can sink their teeth into as early as possible; IA's need to organize information on and across pages. Wireframes result, and despite even the most earnest admonitions against doing so, clients begin to get attached to the wires. By the time visual designers come in, the job has been stripped down to not coloring too far outside the lines. Someone turns a crank, and on a spigot towards the back of this rusty machine, a middling design drips out. Shrugs ensue. That's just how it is, right? Wrong!
In a number of meetings I've had that center on improving the designer/IA relationship, the humble wireframe, sitting quietly in the corner, almost immediately begins to get some cold stares. And, in recent history, there have been an array of efforts to supplant (or supplement) the functional role of wireframes in design. While often driven by the scenario described above, the more dynamic interaction possibilities allowed by AJAX and Flash have also strained the seams of the wireframe, not to mention blurring the line between IA's and technologists.
Dan Brown, addressing the potential for heavy-handedness in wireframes, has proposed a very useful documentation solution with the 'page description diagram.' This is essentially a prioritized list of components. The components can than be detailed on subsequent pages but it is really up to the visual designer, working within the constraints of the prioritization, to arrange the components for maximum effect on the page. Your clients are going to have to use their imaginations a bit here, but that's good for everyone. The most important part if you're going to experiment with a novel format like this is to either use it solely as an internal tool, or do it in parallel with traditional wires. Regardless, you should acculturate your clients to this system as early as possible. You're messing with an expected deliverable here, and having something that vaguely resembles an interface can be important for your client's internal sales process.
Andres Zapata has an alternate solution in 'the guided wireframe' - a solution that addresses the design of more dynamic interfaces. This is a good solution for narrating an interaction to clients, and not really a huge modification to the traditional process of wireframing. At frog, and probably elsewhere, we've experimented with a number of ways to document dynamic interactions. In the New York office, we had developed a tool which would allow for easy specification of HTML components that could then be easily swapped in and out of pages. This had the advantage of being able to create real links that can move through a series of simulated states. It also allowed changes to ripple out into whole systems of documents very easily. Quick and dirty Flash animations work - and I've found you can never underestimate the importance of making a well-chosen sound effect with your mouth to illustrate how something works. The difference between an object "bloop"-ing or "merrrrr"-ing into place, is actually quite profound.
If you haven't tried an alternative documentation system, it's worth it. It's worth it even if only to expose deficient areas in the way you work that may have been masked by adherence to a single way of doing things over the years. However, I've found that a well-considered process is as or more important than almost any documentation. Obviously your process is going to be suited to the particular dynamics of your team - here are a few points on process that I have found helpful though:
1) Get the visual designer on board with the project as early as you can, and get as much information into his or her hands as possible. If you did ethnographic research, make sure the designer knows how the target customers decorate their apartments. I've often found design insights to hinge on very specific details gathered about the people who are intended to use the product. While these details may imply interaction possibilities for an IA, for a good visual designer these same details can be a treasure trove of cultural cues to inform visuals. Everyone works better when they have a more complete sense of the challenges and opportunities.
2) Make a description of the priorities and components, then let the designer come up with a rough grid for the components. This can require some negotiation. One of the biggest flaws of over-IA'd design is a lack of consideration for the timeless wisdom of the Muller-Brockmann grid system and the potential to create dramatic space with it. Over-IA'd grids tend to be regular, or scaled on a fairly smooth continuum wherein the most important thing is about 15% larger than the next-most-important thing. I like to let the designer shoot first here. If well briefed, the designer will probably get close to the mark IA-wise in the initial round, and you begin with something that's had a little room to breathe. Once you can compromise on a grid that is both dramatic, well proportioned, and appropriately prioritized, you're more than halfway out of the swamp.
3) In my experience, once you have a smart grid, you can pretty much write the name of each component in the appropriate box, and this is enough to communicate the most basic gist of your plan to your client. More detail will undoubtedly be expected in short order, but you've pretty much abstracted a lot of what needs to be talked about in the first round. This is very lightweight prototyping in a way, but I've been surprised how good people's imaginations are when they see a box with just the words "video player" in it.
If you're designing a highly dynamic Flash or AJAX application, you can iterate on this process quickly and generate a series of lightweight grids whose function is not unlike a story board. Ultimately, what I've learned from my explorations is to pay more attention to the process and relationship. It seems simple enough that when good collaboration happens, good work follows.
