As mentioned near the beginning of this chapter, paper prototyping is a process. We had also mentioned that the core focus of paper prototyping was on usability testing. What we hadn't mentioned was that paper prototyping should be a part of the software development methodology that your development team uses—be it waterfall, or some form of agile. Specifically, paper prototyping should come immediately after the requirements documents are delivered to the project manager. That is the high-level view of what paper prototyping is and where it fits in.

Let's now take a look at the mechanics of the process at the lower level, meaning the interaction of the development team with the users of the application that is to be developed.

The mechanics, or process in which paper prototyping is done is to first create the wireframes and print them out (I know, more trees will be cut down and global warming becomes an even larger threat, but paper prototyping is important). Once the paper version is in front of you, your boss, your client, or a group of intended users (such as a focus group), you, or whomever else, will use the paper prototype just like they would by clicking their mouse onto the actual web application as if it were already finished and in production. You would ask them to pretend that it was the actual finished application. It sounds silly at first but human beings have an incredible imagination, and with little effort, they will be using it as they would the real thing! This is not hypnosis here but rather something quite magical starts to happen. Without your direction, except for at the very beginning when you explain what you're requesting of them and why, they will start to ramble on, talking out loud about the actions they are taking, or are thinking of taking, such as, Ok, so now I need to fill this out and submit the form, or Where is the button to undo what I just did. I made a mistake. The best information you're going to get from people going through this exercise is when they offer suggestions for how something may be improved, such as It'd be nice if I can easily navigate back to where I... . Can you imagine coding web pages and then realizing the changes being asked to have a far-reaching effect and would be a time-consuming change? It happens a lot.

Do you realize what you have by doing this? You have test users and you haven't written a single line of code! It is quite a powerful exercise! Try it, and email me your story.

So, when I explain this to a client—not to be the user, but how to present the paper prototyping process to their users and/or clients, I'm usually asked, But this is paper. How do we change the screen? I reply the best way I can—by showing them an example. I usually have a sample set of wireframes with me. Not only to demonstrate the paper prototyping process but also to just show a good example of wireframes. I lay down the login screen on the table we're seated at, and I ask them to log in using their finger as the mouse pointer, and then typing on their imaginary keyboard. After they chuckle and just play along with me by typing their username and password by fake typing on the table under the wireframe, they then hit the login button, and I become the computer—I pick up the login wireframe and put down the dashboard wireframe. They usually stop chuckling, look at the dashboard page, take a few seconds, and then look at me nodding and say, This is cool. I get it.