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.