My five commandments for wireframing

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. Its 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 web site 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 anyway. 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 because 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?

  • I always wireframe, its an indespensible part of the design process, I don’t understand how anybody would want to skip this stage. I’ve recently written an article on wireframing myself –
    which looks like its starting a bit of a debate about the value of wireframing! Great post btw!

  • Great post, I think wireframes are sadly missed out on in the design/development process, but it can be a good/bad omen when presenting a wireframe to a client, either a) they like it, it’s fab, just what they had in mind, or didn’t, but it’s awesome anyway. or b) it’s not the final draft and if the client doesn’t have a creative (and colourful) imagination, they completely dismiss it. However, a hierarchy based wireframe, pretty much a sitemap, may help the client be part of the process. I know there is an app out there which a client can insert and drag/drop items/menus to help build the wireframe is a great and invaluable tool.

  • I’d add one more to this list – wireframe around ‘real’ content as soon as possible

  • Yup. We wireframe religiously. You’re right about your tips not being fully relevant to everyone though as I can’t imagine everyone in the team getting together for a wireframing session for every project. We’d never get anything done!

    • sebastian green

      Agree completely, design by council is my worst nightmare.

    • In my experience having lots of the key people there when wireframing helps to set expectations, develops understanding and produces better results. Wireframing with the client is invaluable in my opinion. In fact, I honestly believe that wireframing with the client produces more well rounded and considered websites.

      I disagree about getting nothing done – so long as the person holding the pen can lead everyone to focus and hold their attention – we are all working to one goal.

  • sebastian green

    Totally agree with everything you have put.

    I personally use wireframes because its quicker to scribble a rough layout than it is to create on in illustrator or photoshop. Its less time wasted if the client turns round and says “dont like that design” and you have to do another. Plus if the design only needs tweaking just use a rubber.

    I’m not saying that hand drawn wireframes should replace computer drawn ones, they should simply be created at the stage before the computer is used.

  • Sam K

    Really good read, Paul. I’m at a stage where I’m trying to convince people for whom this is a new concept that wireframing really is a vital part to UX/UI design.

    I may just point some people here to back up my constant harping abot it!

  • Great post. Wireframes are key, it gives you an opportunity to catch things that will not work before you get to far into a design.

    I use pencil and paper and then Omnigraffle. Omni is so easy to use and it produces very clean and professional looking wireframes, that look like you took weeks to put together ;)

    Thanks Paul!

  • intuitive stuff…..loved it

  • I’m glad to see more standing up for the benefits of wireframes,nice work.

    I believe the presentation you mentioned in the podcast was entitled ‘The Right Way to Wireframe’. They each created a video about their process. All were very well done.

    Will Evans

    Todd Zaki Warfel

    Fred Beecher

    Russ Unger

  • Rayna

    Great post – very useful. I would add ‘thou shall not wireframe without some type of annotations’

    It is quite difficult to get wireframes without any type of annotations and then rely on conversation to discuss how things will work and flow – Perhaps you have a different approach and tool for accompanying wireframes that then get handed off to developers. I would welcome your thoughts here.

  • aurel

    last few months was my very first time where i had to wireframe before starting to design the interface in photoshop and so on.

    by looking at few tutorials, i found (as you mentioned) wireframes do not have to be perfect drawings, so i created boxes and give the few lables like “logo here”

    after i started with photoshop, then css – i found these wireframes to be as a check list; as previously, i always would forget to include a feature or something.

    so yes, as a first time, i really think the process is vital to quickly collect ideas

    great post

  • Good post – especially about wireframing in isolation. The whole reason we are doing the wireframes is to expose functionality and usability issues/benefits that nobody has yet considered, and the more input the better. Successful wireframing results from a collaborative, iterative process. Nice read Paul.

  • Since starting out in web design / development about a year ago, I have realised the importance of wireframing. Wireframing helps build solid foundations on what to create great web site and web apps.

    I now use pen and paper to produce ruff drafts of the wireframes with clients and then tidy those up back on the Mac using CS4 Fireworks. Looking forward to Fireworks CS5 that has improved features and templates to speed up this process.

    I dont use moodboards at the moment and would love Paul to do a follow on post about where they fit into the design process?

  • Jo

    What are some usual questions you ask during user tests in wireframes? Since it’s so barebones you can’t really test users on completing a task.

    • Jo,

      We don’t paper prototype a lot but on our last test we had a lot of state changes so we gave the tester a testing identity (Jane Smith) so that we could actually lay out what she would see with each change. It was pretty simple to create duplicate pages in Omnigraffle and just adjust them to reflect the state changes she would see on screen. From there we treat it like an other user test. The key is to make sure the facilitator understands the process, especially when to switch out the page the user is currently on. If the user really goes off track it’s just like ending up on a 404 page only verbal (unless you want to create a paper 404 page).

  • I have one:

    “Thou shall always use graph paper when drawing a wireframe”

    might seem obvious but I used to use plain paper sketch pads. Using graph paper made it so much simpler for visualizing grids, and provided a really quick reference for widths and heights.

    • Interesting. I never use graph paper. Graph paper makes me too precious and too accurate in my initial doodles. Quick and dirty is always the key for me. Each to their own however.

    • caronnect

      Wireframes are an essential element of our UX design process – we begin by sketching with pen/paper and/or sketching on whiteboards, then an electronic or paper prototype. Lately, we’ve been using Axure for the electronic format as it can also produce a low-fidelity (or high-fidelity if there’s time) prototype for usability testing and quickly generate a UI Specification. Having said that, PowerPoint has often been used so that the wireframes can be shared as most Australian government employees only have the MS Office suite available to them.

      In the early stages (sketching), I never use graph paper or anything that hints at preciseness. The collaboration and co-design in the ideation process are the most important goals initially.

  • Wireframes are pretty much indispensable to the workflow between our UX team and developers, usually covered with sticky notes on functionality.

    I often wireframe on whiteboards, sometimes even before the sketched wireframe. It’s as fast as a sketch on paper but even easier to change. Since we share our workspace it also gives the rest of the team and others from our company who wander through a chance to see what we’re working on.

    Also, as a fairly new user, Omnigraffle can be frustrating if you’re not accustomed to it. It’s really helpful if you get the Konigi stencil library from online.

  • Great post, nothing like a commandment post to get you thinking :)