Paper Prototypes

Often people ask us "how did you come up with the ideas for the Office 12 user

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

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
) 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

Paper Prototyping: The Fast and Easy Way to Design and Refine User Interfaces

Comments (16)

  1. John Topley says:

    "Paper prototypes are simply printouts of what the computer screen would look like when running your software."

    So where do these images of the computer screen come from? It sounds like they’re from something time-consuming like PowerPoint or Photoshop rather than a paper sketch.

  2. Andreas Häber says:

    "So where do these images of the computer screen come from?"

    Just grab a paper and a pen(cil), and then start drawing your dialog box or whatever you’d like. It shouldn’t be more complicated then that 🙂

    But maybe they do it more fancy at Microsoft…?

  3. MSDN Archive says:

    I suspect Visio is the easiest way to spit out a UI image, but Power Point could work and even just spending a bit of time in the Visual Studio form designer with some version of what you want could do it.

  4. Terry Blanchard says:

    At my company we use Visio. It’s extremely quick and easy to put screens and dialogs together. Depending on the number of screens, or paper prototypes we have, we sometimes put the images in a web page with hot spots the user can click on that link to the other images.

    We use this technique with TechSmith Morae to capture all of the events as the participant completes their tasks. This also gives the participant a more accurate representation of the interaction and better test results for us.

  5. Brian Shih says:

    While you could go and draw the prototypes in Visio or Powerpoint, I think Andreas has the idea – they really should just be quick sketches the first time you go out. (screenshots are fine, but you can hand draw a dialog box if you need one) I’m pretty sure the book that Jensen refers to says something about not spending too much time refining the paper prototypes, and to just bring things along with you to make adjustments as needed (post-it notes, paper, pens, transparencies, etc).

  6. Mark Nelson [MSFT] says:

    Yes, many of the Office teams use Visio for screenshots although not necessarily for the Ribbon UI given its unique look. Images can be assembled in Visio and pasted into PowerPoint, or Visio has its own rudimentary slide show capabilities.

    Keep in mind that there are multiple levels of refinement here. It is often best not to use high fidelity images in the initial design phase since you are supposed to focus on the basic usability and workflow, not the final layout and alignment. However, for prototypes you put in front of customers, it is helpful to show something a bit more fleshed out.

  7. MSDN Archive says:

    Well, if there were computer-drawn paper prototypes of the ribbon early on, I’d expect the look wasn’t really that unique yet, and so Visio would still be quite adequate.

  8. It may seem based on my writing that the ideas behind the Office 12 user
    interface kind of popped out…

  9. A couple of weeks ago when I talked about
    Feature Bob Invented, I mentioned that we use PowerPoint…