not just wireframed that way

Like so much else, the definition of wireframe (also spelled wire frame; both are correct) has evolved over the past few years. In the web world I’ve seen them frequently presented as conceptual page layouts, typically not interactive, with comments. But things were not always thus.

My first encounter with wire frames was in 1990, doing CAD diagrams to be used designing jewelry displays. These were skeletons of the product to be created, sometimes fairly complex, sometimes not—precursors to more detailed exploded diagrams used for actual manufacturing in our process. (Oddly, I ended up doing a little jewelry structure wireframing in 2003 for Barse, through their Shannon Diego line. But that’s not relevant to the subject at hand.)

Then, early in my web career in the late nineties, wireframes were text-and-table layouts of web sites with working links. They existed in HTML format and were used to test functionality and information flow as well as overall page layout. They did not have to be black and white—in fact, this approach made it exceptionally easy to test color palettes by tweaking CSS, etc. Notes were made within the layout. This allowed for detailed flow analysis, layout evaluation, etc., and provided programmers with a great reference as they developed the actual web app.

Products like Visio quickly appeared to make this process easier, allowing the compilation of Visio work within one document into a linked screen flow.  A Usability Interface article observed in 2000 that

…[Y]ou are not creating a true HTML prototype. Instead you are creating something that mimics a prototype but does not contain all of the HTML controls you normally encounter on a page (e.g., drop-down boxes, data entry, etc.). So, there are limitations to what you can easily do in this Visio export. However, you can create a reasonable prototype much quicker than if you coded the entire screens in HTML.

I’m not sure I agree with that across the board—a lot depends on your coding expertise—but it can’t be denied that Visio empowered quite a few IAs and UI designers.

Today, despite the prototyping capabilities of applications such as Axure, there is much less live wireframe use. While the work is done digitally, the consultation process is essentially paper prototyping using a printed diagram.  The wireframe is a flat file, created in everything from the ubiquitous Visio to PowerPoint, and often saved as a pdf for easy distribution and printing. This seriously undermines the potential usefulness of wireframes in the architecture and design process, but is the nature of corporate life for many IAs.

Additionally, the style conventions of wireframes vary from department to department within a company, which can make it difficult to share ideas and development.

Here are some tips in creating useful wireframes:

• Use consistent design cues so a non-IA, non-design person can make intuitive sense of it.
• If at all possible, put your notes on the same page as the wireframe itself.
• Incorporate text where possible and relevant, instead of limiting your page description to numbers that lead to a list. Which of these approaches seems more usable to you?
  –A box with a (3) in it, directing you to a list that reveals (3) to be “Page header, h1 format for SEO, one per page.”  Said list may or may not be on the same page as the diagram.
  OR
  –A box with “Page header (3)” in it, and an on-page list for a paper prototype, or a link in a web prototype to the same list item.
• Leverage your notes to capture details such as SEO needs (”single H1 tag,” or “menu keyword analysis needed”)

If you can get your company to do interactive wireframes and share them on your intranet, or present them via projector, it empowers both your wireframes and you. You’ll also provide a place for your design team to test fonts, text, etc. on the fly, and give yourself a sort of “pre-QA” for your navigation design.

Wireframes are not all cut from the same cloth, and your needs will vary according to your company culture and project needs. But for me, knowing the options helps me provide the best possible experience to my team members when working on a project.

June 2009
More in UX
More in UXtraordinary