Paper prototyping for the genius designer
It’s very convenient for us designers to think that we always know the best way to do things. Genius design, explained aptly by Dan Saffer in his excellent book, is probably a favourite method among web designers, especially in today’s web-two-point-oh environment of quickly-hacked web apps. After all, there’s only so much you can do with a web interface, and so much of it has been done before, it must be quite difficult to get anything wrong!
Yet we manage to get things horribly wrong with startling frequency. And almost always the reason could be traced back to lack of proper user input in the early stages of design. In a rare productive meeting yesterday, a Client shattered all our assumptions and injected a good dose of common sense in to our heads when he pointed out some glaring flaws in the design of a web application we were developing. In addition to saving us a lot of wasted effort and significantly improving the usability of the interface, that meeting also reminded us of the importance and usefulness of paper prototyping.
What on earth is a list?
This particular web application facilitates online recruitment, and a primary function involves an employer (the user in this instance) picking suitable candidates from a pool of applicants, and adding them to “lists”. For example, if the user wants to hire a designer, she would create a list for this purpose and add candidates to that list. In our design, the list name was independent from the actual job title: she could just create a list named “my hot list” and add people, and set the job title for that list later.
In true Getting Real fashion, we had the interfaces done first. We started explaining the above process to the client (who, fortunately, fits the role of the user perfectly), using a set of crude wireframes:
Lankitha: First, the user creates a list-
Client: Hold on, what’s a list?
L: That’s just a place for you to add candidates, like a folder in your computer-
C: Why is it called a list then? Why not folder or something?
L: Because it’s not really a folder; it’s a list of candidates
C: Er, OK…
L: So, the user creates a list-
C: Hold on, this is confusing… What on earth is a list?
It went steadily downhill from there onwards. Our first reaction was to be defensive: after all, we had put a considerable amount of effort in to designing the process and the interfaces, and before we could even get started, we were faced with a stumbling block. Surely the client was wrong?
It took a couple of minutes to realize what was happening. Paper (or, in this instance, on-screen) prototyping was already paying dividends.
Paper prototypes to the rescue
Highlighting our mistaken labeling was only the beginning. We continued with a different label and along the way found out several other problems too. At the end of the session we realized that a major overhaul of the process was called for, and a number of changes to the interfaces were in order.
Cheap yet effective
I wouldn’t call what we had a usability test: it turned out to be one by chance. But it did show how simple and cost efficient usability tests could be carried out for projects that have budget constraints and tight deadlines. People like Jakob Nielsen have been harping on this for years, but the true value of simple methods such as paper prototyping can only be understood once you do it and see the results for yourself.
Live redesigns
Another advantage of paper prototyping is you could make quick changes based on user input and see how the new interfaces are received. Since paper prototyping happens at the beginning of a project, the cost of throwing away is minimal. In fact, almost always you’ll have to throw away your first few attempts. That’s a very small price to pay for the guaranteed improvements in usability.
Towards the end of our session, the client was the one talking and sketching, and we were the ones listening. Much of the upcoming revamped design of the application would be directly from the sketches of our client rather than our genius designers.
Test early, test often
Our attempt at genius design wasn’t a total failure: a lot of other sections of the application were readily accepted, and some are already implemented. But, we’ve learnt our lesson from this meeting: the genius designer is a myth. Unless, of course, you’re Jonathan Ive.
As Steve Krug says in Don’t Make Me Think, testing one user is 100 percent better than testing none. Our first test wasn’t even intended, but surely it won’t be the last.
