When you sit down to design a user interface, where do you start? Do pull up Visual Studio and start creating forms and dragging controls onto them? Do you go talk to the server guys to see what they need and then just go for it? Or do you wait until the design phase is done and then create a dialog for each class in the system? Doesn’t sound pretty, does it? Well, have you ever pushed away the keyboard and pulled out a pencil and paper? Believe me, I’m no fan of the old school input methods (I can barely read my own handwriting), but there may be some use for that dead tree after all.

With paper prototyping, you can design user interfaces (graphical or even hardware) and get real life user input about the usability of that interface without ever touching the mouse. Basically, the drill is to draw the different states and dialogs that your UI contains on several pieces of paper and then observe as users interact with them. During the session, a person playing the role of the computer puts down the appropriate pieces of paper as the user physically touches and interacts with UI, so that the paper prototype acts as the real application would… just in ink or graphite. Nothing in the UI (layout, navigation, etc) is the explained to the user beforehand. The user is simply given a task and is asked to perform the task on the paper prototype.

Right now, you might be thinking “Well, what the heck can you learn from this? It’s only paper!” That’s true, but the fact that it’s paper is key to the whole operation. The prototype only takes as much time and effort to develop as it takes for you to draw the dialogs. On the paper, the user can physically touch the buttons, links and other clickable controls and can even write character input into the appropriate controls. Better yet, the paper prototype can be quickly refined to fix discovered problems with the interfaces… sometimes even during the session itself! “We saw you had problems finding the place to input the name. Would you try it again with *this* prototype.” How cool is that?

So what sorts of problems can you really find from some scraps of paper? Well, let me tell you, dear reader:

Confusing UI and concepts

There are times when you really don’t know how to express your interface so that the targeted users of your application will be able to easily grasp and use the interface. Or worse, you may think that you have the interface nailed down… except that you don’t.

Maybe you think that adding an object by choosing the type of object and then clicking the “Add” button followed by configuring the object is a perfectly reasonable set of steps for the task at hand. Well, your users may disagree. Heck, your users may not even be able to find the dialog to add the object in the first place. They may even be “clicking” the options link in the upper right corner over and over because they’re sure that’s where they need to go to add the object. Acting this all out with a paper prototype will find that out.

Important pieces and not so important pieces

Sometimes you may think that a certain feature is really important. You’re positive that the user will have to have this flashing red spinning textbox. The interface just won’t make sense without the flashing red spinning textbox. You get to the paper prototyping session and the user doesn’t even touch the flashing red spinning textbox, but they keep commenting on how great the dull boring toolbar is. Now you know where your spend your valuable time.

Weird words and wrong words

Are you using terminology appropriate to the domain as well as words that your users actually know? Have you ever put “VOIP” as a label in a dialog and your users thought that it meant the Teen Girl Squad sound effect instead of Internet Telephony? I know I have…

But do you know what the best part about paper prototyping is?

You get all the bugs out of the way before you write any code at all!

Well, ok, not all the bugs, but a fair amount of them. You’ll have confidence that can be backed up with real data that your interface will, at the very least, not suck. Any improvements that need to be made after releasing the application should be minor adjustments… assuming that you’ve paper prototyped all the new features that crept in along the way too.

To get your feet wet in paper prototyping, check out PaperPrototyping.com, A List Apart and of course Jakob Nielsen’s Alertbox. To get your feet soaking and all prune-like, buy the book.

UPDATE: To see paper prototyping in action, check this out.