Now we finally get to wireframes!

A lot of information architects think the first step of doing a user experience project is going straight to doing the wireframes. I counter that it’s fairly far down the path after doing user research and establishing the use cases, and that wireframes really establish the spirit and intent of a web application; they are the visual framework from which the developers use to build the application.

Wireframes are never seemingly done: I can’t tell you how many projects I’ve been on where at one point or another, we abandoned the wireframes and communicated directly with the developers. Wireframes are a starting point for development and a tool that should be used as such.

What Is A Wireframe?

A wireframe is a visual representation of a single page or screen, and the elements for that page. It is used as a communication tool with developers, designers and the client, and some agencies use them to get signoff from the client. Wireframes contain all kinds of annotations and notes what each element means, and are usually paired with use cases so they are a meaningful guide for software or web development.

Is it possible to illustrate every single step in a wireframe? Yes and no. You can spend the time to do it, but I’ll contend that most developers won’t read the wireframes closely, so when I do them, I usually do just enough detail to get development started but not too much as to overwhelm the developers. Talk to the developers to get an idea of how much detail they need, and refine based on feedback.

Why Wireframes?

The last thing you want to do is let a developer decide the placement of a submit button.

Seriously.

Wireframes are good for two reasons:

• Placement of elements and the visual pattern of the application are important, because they affect the usability and profitability of the application
• Wireframes make great lo-fi prototypes to test your assumptions with users, albeit in an artificial environment

On to the first point: When developing an application, there’s always a process of “does this actually work,” and the best way to develop that visual pattern is to go through the process of making wireframes. Eighty percent of what you are trying to do should fit nicely into some kind of page architecture, and if the elements aren’t working, doing the wireframes will help discover this.

From the wireframes you’ll be able to see design patterns from templates, common navigational needs, and overall site structure. After seeing the forest, you’ll be able to place the trees better. Many times when working with a client, I’ll tape the screens to the wall so I can see the flow of the application and walk clients, programmers and clients throw that flow. When walking through that flow, you’ll find issues that aren’t discovered in simple requirements gathering, and sometimes use cases ill need to be adjusted to fit.

The second point: Once you are done with the wireframes, you can take those wireframes (hide the annotations) to users, and ask them, “so what do you think this button does?”

I’m still on the fence about using wireframes this way, because I think they react much more positively to a clickthrough that involves a screen, but sometimes I take those wireframes and do the lo-fidelity testing, either sitting down or taping it to a wall.

If the users can’t explain what’s going to happen next, it’s probably not obvious enough.

How Detailed Should The Wireframes Be?

It depends.

If you are working closely with a development team, the wireframes don’t have to be very detailed at all, and may or may not include annotations of user interactions. Some development methodoligies like XP don’t even suggest much requirements gathering at all other than writing stories with hand-drawn wireframes as the artifacts.

If the team is outsourced, overseas and 10 hours behind you, you might consider adding as much detail as possible. That includes full annotations, written use cases, process flows and all of the nifty requirements documents to provide the developers as much detail as possible, because they aren’t sitting next to you to ask, “So what does this button do?”

The amount of direction and literal usage to the wireframe depends on the team: sometimes the designers took the wireframes as a literal guide, and in other environments, designers and developers were given some flexibility on how to redesign the screens based on the elements needed.

What Tool Should I Use To Do Wireframes?

The tool used to do the wireframes should be important (Visio, Omnigraffle, Azure, PowerPoint and InDesign all come to mind of past projects I’ve done), but it’s how the communication is carried out. For all intents and purposes, hand-drawn wireframes are effective.

The tools I like are:

• Visio
• Omnigraffle
• InDesign

Now that I’m consulting again, Omnigraffle will probably be the tool I use most often. I’m been contemplating using InDesign, but on the PC side, I’ve found that Visio is portable enough for most environments.

It really comes down to what’s the quickest way to illustrate a concept. Use what you are comfortable with — nothing else.