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’.
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.
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.
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:
Get in touch if you’d like to share stories of how you’re prototyping.
