As a design tool for web development paper wireframes drawn with a computer suck. If you still use them I suggest you stop.

In a recent UIE podcast Lean Buley of Adaptive Path suggested that paper wireframes are an awful design tool. She describes a familiar scenario in which a designer takes their pre-defined list of required functionality and plops their ideas straight onto pages in a drawing package. She then goes on to note the problem with this situation is that it reduces the design process to the act of pushing shapes around a page.

She’s right. I’ve personally sat in an ad hoc meeting where a senior designer has brought people in to help them push these shapes around. The whole time I had to resist to impulse to say ‘this isn’t design’, ‘ watching your copy and paste isn’t creative’ and ‘I don’t know what the right label is, we should do some research to find out what the users think’.

Why they suck

• They’re too high-fidelity. There is something too definitive about wireframes produced as client-facing deliverable. It’s hard to question something with hard lines and neatly aligned annotations. It’s hard to question something that has obviously taken considerable time to produce and would take a great deal of effort to iterate.
• Nobody understands them. When someone describes an idea for a website your mind starts reeling and your subconscious instantly provides a crystal-clear fully-realised vision of that idea. Alas, everybody has a different vision in that scenario, and your wireframe of that vision is vague enough to allow everyone to visualise a different endgame. You can’t build consensus from a paper wireframe.
• You can’t test a paper wireframe. I’ve read a lot about paper prototyping. High-end design firms like IDEO and consultants like UIE tell tales of how you can put users in-front of paper prototypes and run user tests. I’ve tried to do this. But I’ve always ended up with pieces of paper flying all over the place and had no real idea of what was going on.

A case study

I worked on a project last summer where I was designing an extension to a client’s site. I’d just been to UX London and attended an HTML wireframe workshop with James Box and Richard Rutter.

I was in an agency at the time and as agency people will understand there was great pressure to get anything-at-all out to the client. I decided that annotated paper was the way to go. It would take 4 hours to produce paper wireframes while HTML would take maybe 8. Bada-boom, 4 days late, I get a PDF to the project manager.

A little later on a word document full of questions and as long as my arm came back to me from the client. ‘What’s the user journey here?’, ‘What happens when a user clicks on Show 20 results?’. The client didn’t understand the wireframes. Or, at least, they couldn’t understand the behaviour they should have represented. And I don’t blame them. The wireframes were a shoddy visualisation of my personal mental image.

It took me a total of 6 hours to respond to their questions.

On the way back from UX London I built a HTML prototype of the site for fun. It took about 6 hours. The duration of the east coast train journey from London to Glasgow.

When more feedback came it from the client I decided to build it into the prototype and send it over. Surprisingly they understood it straight away. With the prototype they could ask themselves questions about behaviour and immediately test to see if the prototype could answer them.

Paper wireframes plus written responses 10 hours. Prototype 6 hours.

How it should be done

The right way, or should I say the RITE way, to work with interactive prototypes it to put real users in-front of them.

As Steve Krug suggests, a user test on a site that’s already designed and about to launch isn’t a user test – it’s a disaster check.

If you can go from some early pen sketches to an interactive prototype which you can run user tests on you may learn that your design doesn’t work. It’s best that you find this out before you take it to your development team and waste an awful lot of money.

• You’ll save money
• You’ll save time
• You’ll build something better

I hope to write more about how I prototype website and apps on the future, and release a bunch of the code I use. I actually don’t use any of the commercial packages (although I’ve tried Axure). Just HTML/CSS and Javascript. I do this for two reasons:

1. Nothing behaves more like a plain old HTML/CSS/JS in a browser than plain old HTML/CSS/JS in a broswer
2. jQuery is easier to learn and more powerful that any interaction scripting I’ve seen in prototyping apps to date

Get in touch if you’d like to share stories of how you’re prototyping.