Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

While Origami takes the cake on using paper to express elaborate creativity, Paper prototyping, in my geeky mind, comes a close second. Paper prototyping in early software design process is under-rated and can get you asking questions like only a curious child deeply engrossed in pretend play can.

Simulating the product/user experience via sheets of paper that can represent screens and flow has many advantages. The best of those being the speed with which you can whip up a tangible product the user can visualize and play hands-on, and the speed with which you can quickly course correct the flow of your application during this process. I took paper prototypes of two products in their early inception phase to user conferences to get them tested and found the experience very rewarding.

First off, my PPs werent all that elaborate. I started by making a baseline wireframe page(in our case, a normal sized page with the browser window drawn on it and product title, navigationon and footers added). I took several copies of this page to be the starting points for the rest of my screens and to maintain a consistent application feel to the paper.

Next I used colored cards and post-its to simulate data-grids, dialogs and other screen elements that I could quickly replace based on the user action. One really effective trick I learnt is to use transparencies to cover the prototype so users can actually “enter” data into the fields using markers that I could erase out at the end of the session, without having to use a seperate paper form for each user. Another use of the transparencies was to place small rectangular strips of colored transparencies on top of data-grids and data tables to indicate that a certain record in the data table was selected or highlighted.

Then I prepared a few test scenarios, which are specific tasks handed to the user to perform on your application. It helps if the scenario contains a brief background of the user persona, the task they are asked to accomplish with this application and when the task would be considered complete. Make sure you are not using “leading” words in your scenarios to give hints to the user on where to look for certain options etc.

For example, if you were designing a website to cater to a restaurant, prepare a user scenario that reads like “Scenario 1: You are Bob smith, a manager at a small local firm, a husband and father of 2 teenagers, and a food enthusiast who believes in using local organic ingredients for cooking food. You are scoping out this new restaurant to see if it fits your organic and nutritional requirements.  Browse through  the restaurant website to check the menu and find out where their vegetables come from and what are their healthiest options. Follow-up scenario: Order one portion of the item you picked.”

Next you need to have one person to play the computer/moderator and another person to take notes. The key to being a good computer/moderator while running the paper prototype tests is to know your flow very well, go through the various paths a user can take and be prepared for the ones you are interested in getting feedback on and then throw a catch-all “under construction” card for all the paths you havent thought through or not interested in for the current paper prototyping session.

Also, make sure you look at your paper prototypes as real applications and insist that the user touch/click the relevant button and enter real data in the forms before you switch the papers to navigate to the next part of the flow. To make this process really effective, you have to be able to iterate very quickly to change the screens and application flow in between sessions so you are adjusting your course as you listen to user feedback and presenting the modified flow to the next set of users testing the prototype.

That’s all it takes to take your prototype to market with some potential users and have them play with it. Many teams do paper porotyping internally within their team and across teams in the same company to catch kinks in the flow before going to real users. Whether you chose to stop at the first step or take it all the way to real users, this rudimentary prototyping technique provides a very quick and effective way to pound your design.