Popping my Paper-Prototyping Cherry

We did a paper-prototyping dry run the other day in preparation for some similar sessions for a client (not involving me, unfortunately). It was the first time I’d done it hands-on, having only read about the theory before. Here we were basically evaluating the technique.

We played the roles of “stakeholders” from diverse parts of the business (the real thing will be properly diverse: marketing, management, legal, or whatever) and collaboratively designed an interface for a particular set of tasks by scribbling on bits of paper and pasting these to a cardboard “terminal.”

Interestingly, we had a brief to make the user experience “pleasing.” In fact, that was more than interesting in my opinion – it was pretty radical. At first I simply took that to mean being “easy to use” or “efficient,” but the more I thought about this the more interesting it became. The exercise was like writing a haiku: the constraints were tough (we were only designing a small part of the system, with main navigation already decided), but somehow that made it easy to get the main job done because. But to make it “pleasing” was a pretty lofty challenge. In the end, the best we could do was to make the language used polite, but friendly.

Then we got our “test participant” in, sat them down and asked them to perform the task that we’d designed the interface for. They didn’t accomplish the task as well as we’d hoped. But no matter – we could adjust the prototype instantly if we wanted. We then asked if they could guess the “design principle” we’d been set. They didn’t really guess it, but they did notice the language, so thought it might be “simple” or some such.

Overall though, it’s clear that paper-prototyping has a number of advantages over the standard scribble-then-Visio/Freehand route. The main one is the fact that with such little invested effort in putting screens together, you can work on the higher-level stuff much faster (“Hang on, does that step even need to be there?” and other things that might take a while to shake out otherwise). So it gets my vote for lowing the effort threshold at least.

One area I did think might be problem: trying a quick series of iterations on successive test subjects is very easy. But this might mean that you’re simply designing the interface for the last person to test it. You have to keep your user testing quite firmly fixed on; taking suggestions for new features, etc. with a pinch of salt rather than diving in and implementing changes immediately.

Hope to be able to post more about this if I get the chance. I know it’s not exactly cutting-edge, but real-world reports of the use of paper-prototyping in an agency/client context is something that I think some people might find useful.