Wireframes of Reference

Wireframes or schematics (also known as "paper prototypes") are a common way to create a mock up of a user interface. In the best case, they can function in a similar way to architectural drawings and blue-prints, providing a detailed and authoritative representation of the intended navigation, and basic content heirachy. They allow various stakeholders to contribute to discussions about how the interface will work, and provide a clear pathway to a successful design solution. In the worst case, wireframes lead to mistaken expectations about the actual visual design. They cause dissonance between developers and clients, and maddeningly stifle the creativity of visual designers. The issues of using wireframes as deliverables have been well documented, as have strategies to avoid potential problems. What's less well documented is the overlap between wireframes and rapid prototyping, something I've been increasingly drawn to explore on recent projects.

A tendency of specification driven processes is a separation between design and implementation phases of a project, which can sometimes lead to months or even years between the creative ideas in a paper prototype being translated into a usable site interface. Rarely will enough detail be captured in diagrams to actually determine a plan for a real interface implementation. The fluid nature of web interfaces and the technology behind them tends to lead to a whole host of issues arising in implementation, that would never be considered in the planning and solution design phase of a project. Sticking to a fixed plan is not an option. Either the wireframes must be updated to correspond to the new design challenges, or the prototype itself evolves in it's own direction away from the wireframes, making them out of date and irrelevant. It's awkward, and so I'm starting to believe that paper prototypes actually work best when there is a real implementation process happening at the same time. Shorten the path between an idea and it's implementation, and all the discussion, creativity and feedback from presenting diagrams becomes immediately relevant to the real on-screen prototype.

One of the best case studies I've seen of rapid prototyping in action is highlighted in this post about the creation of Backpack. If anything, this demonstrates that HTML is quite possibly the best rapid-prototyping tool in existence. In the time that it takes to align a set of boxes in Freehand, an experienced designer can knock together an equivalent web layout, and actually have it working in the browser. It's always helpful to scribble all over schematics with pen and pencil, but once an HTML wireframe is set up, it's possible to immediately improve the design by directly integrating comments and feedback. Theres no putting it off til later.

Another benefit I hope, is that seeing more web designers and information architects focusing on rapid prototyping will lead to a greater industry wide appreciation for usability testing as part of the design process itself, not a separate process of analysis and review.

Explore the user interface straight away, get a feel for whether it works and where it should go. Throw the prototype in front of your audience, and find out that your expectations were completely wrong. Get your audience interested, then refine, refactor, and keep them interested. Evolve a website with small incremental changes, rather than one all encompassing redesign. It works awfully well.