My five commandments for wireframing

Paul Boag

When it comes to wireframes I am a fanatic. I believe they are an indispensable part of the development process. That is why I enforce 5 unbreakable rules.

I am a fundamentalist when it comes to wireframing. It’s almost like a religious furore. To me, they are utterly indispensable and when they are not used it makes me want to smite people!

However, I am not writing this to convince you of the value of wireframing. If you need convincing read “The 7 Wonders Of Wireframes“. But, what I do want to share is my five commandments for wireframing. They are…

  • Thou shall not neglect to wireframe
  • Thou shall not wireframe alone
  • Thou shall not be afraid
  • Thou shall start with pen and paper
  • Thou shall test thy wireframes

Let our sermon for the day begin with “Thou shall not neglect to wireframe”.

Thou shall not neglect to wireframe

From my perspective, things start to go wrong when you decide to skip wireframing. After all, there are always plausible excuses…

  • This is such a small change it doesn’t need wireframing
  • The client won’t pay for wireframes
  • There isn’t time to wireframe

The problem is that these objections simply are not true. Hand drawn wireframes are incredibly quick to produce. For example, creating a sketch of a tiny change to your website takes only seconds. However, the benefit these quick sketches provide is incalculable. Ultimately they will save time, money and a lot of potential aggravation. Without them, misunderstandings over requirements can quickly creep in. So let me be clear – I believe in wireframing every piece of new functionality even if it is just on the back of a napkin.

Thou shall not wireframe alone

Another big danger I have observed in wireframing is what one of our developers calls the ‘chinese whispers effect‘. This starts with the information architect who produces the wireframe alone. He then passes it to the project manager who gives it to the designer. The designer turns it into a design and finally passes it to the developer. With each step along the line, the vision of what the site should do becomes degraded. Another problem with this approach is that the other team members get little input into the wireframe so it’s possible the information architect will produce something that for whatever reason is impractical. By the time the designer or developer has seen the wireframe it has already been signed off by the client.

I believe the best way to overcome this problem is to wireframe as a group. Get together the entire project team (including the client if possible) and produce the wireframes. This makes it a much more collaborative process and ensures that any possible problems are identified early.

Thou shall not be afraid

The dirty secret of wireframing is that many people avoid it because they “can’t draw” or are “afraid of looking stupid” when put on the spot in a group. Instead, they want to hide away and craft carefully considered wireframes. My message to these people is simple – get over it. Photo of wireframes This fear undermines the power of wireframes. Wireframing should be about thinking out loud. It should involve throwing ideas out there and discussing different approaches. You should come away with a final set of wireframes borne out of many iterations and approaches.

Thou shall start with pen and paper

To keep a light weight, spontaneous approach, wireframes should be initially produced with pen and paper. This also aids group working. It is easy for everybody to participate, to scribble on other people’s work and put together their own ideas. It takes the power away from the person sitting behind the laptop that is plugged into the projector. I am not saying that wireframes cannot become more sophisticated as they are finalised. You can use whatever tool you want from Balsamiq to FlairBuilder or even Powerpoint. However, they should start with paper.

Thou shall test thy wireframes

Finally, I believe wireframes should always be tested. However, that does not have to be a major undertaking. It is enough to show them to three or four people and simply ask if they get it. It doesn’t need to be documented or formalised in any way. It just acts as a sanity check with somebody from outside of the project.

A personal perspective

Okay so I admit it, I am not really a fundamentalist when it comes to wireframes. I think they’re really important but also recognise my ‘commandments’ do not apply in every company and every situation. The reason I am using such strong rhetoric is that I have seen too many projects falter without the clarity wireframes bring. It’s such a simple thing to do that there really is no reason not to wireframe. So what about you? What stops you from wireframing and what advice do you have to make wireframing more effective?