Paper Prototypes
Often people ask us "how did you come up with the ideas for the Office 12 user
interface?"
That's a big question. And the answer isn't simple.
What is easier to describe is the process by which we work to validate the
design choices that we make as we go along. The very first ideas we have
are seldom right; instead we continually iterate and improve based on our
usability feedback loop.
One of the conundrums of an iterative design process is how to get feedback
early enough to impact the development process. If we waited until the
development team was finished coding the product and then put the fully-working
software in the usability lab for the first time, we'd be in a world of hurt.
There would be no time left to actually make the changes we would learn about.
As you might expect, we rely heavily on prototypes at the earliest design
stages. We often create these prototypes in PowerPoint, believe it or not.
(You can create surprisingly rich, interactive prototype experiences in
PowerPoint)
But even these prototypes take time to create--often more time than you have to
spare when you're trying out a risky, new, untested idea.
So, more times than not we use a cheap but surprisingly effective way of getting
quick usability feedback from real people: paper prototypes.
Paper prototypes are simply printouts of what the computer screen would look
like when running your software. Usability subjects are given a pencil and
asked to pretend that it's the cursor and to virtually "click" just as they
would with a mouse. Whomever is running the test (usually a usability
engineer or program manager) sits at the table with them and is responsible for
reacting to the subject's actions by updating the virtual screen with the right
printouts. For example, if the subject launched a dialog box, I would find
a picture of that dialog box and lay it over the window they were looking at.
There are limitations to the kind of features that can be tested well with paper
prototypes. A feature that relies on "feel" (such as the
Office 12
MiniBar) doesn't lend itself to this kind of testing.
That said, there's no cheaper way to get real, actionable feedback about a
design. Many of the Office 12 designs were first vetted in the paper
prototype stage, after which we refined the designs and tested them again.
Most of the time, there was a strong correlation between the feedback we got at
the paper prototype stage and that we got with richer, interactive prototypes
(and even the fully working product!)
For more detailed information about this technique, I recommend Carolyn Snyder's
book
Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces.
