Making a Paper Prototype

This blog and summary is on Chapter 4, Making a Paper Prototype, from Carolyn Snyder’s book Paper Prototyping: The fast and easy way to design and refine interfaces (2003). 

SUMMARY

The chapter deals with the mechanics of building a paper prototype.  It explains the what and how; what you will need, and how you will build the paper prototype. 

In the opening paragraph she reminds us to:  “First define the users and tasks and build the paper prototype around them.”  

She divided the Chapter into topic and subtopics which I summarize below.

Paper Prototyping Materials – Most of the needed materials are common office supplies; a few are speciqlized and may need to be ordered online (e.g., removable tape).  See also the author’s website www.paperprototyping.com.  She offers some good ideas – nothing that I found to be particularly earth shattering.  She provides a list of both supplies she uses and those she does not use.

Creating a Background – The use of a background is optional.  The background serves as the “desk top” (my words) and sertves the same purpose as a master slide in a Power Point slide show.  It provides an overall look and feel for the project.  The background can represent the computer and contain permanent or constant elements.

Software Application Background – The developer needs to decide if the background needs to represent the operating system or just your applications desktop.  This is particularly useful if building for a particular system e.g., a Palm Desktop with its controls.

Browser Backgrounds – You normally are not testing or prototyping the browser window or its usability; you are normally testing your own application site.  Backgrounds can be used to “build-in the standards and conventions (look and feel) your site will be using.  Some standard buttons that may be included:  Next; Back; Home; Glossary; Help, etc.  Desktops do not normally show URL address fields and other fields if the student tester does not need to us.  She also warns, “Be careful not to make too many assumptions about what a student can do.”

Small Screen Interface – When designing/developing for small screens – pixels may matter.   If you are going to be designing for small screens, need to be “aware” from early on.  If necessary, grab a screen shot of the screen (e.g., Snagit) and use a graphics program to create your background.

How to prototype Interface Widgets – She provided several pages on ideas and tips on how to incorporate the following widgits into a paper prototype:  buttons and checkboxes, tabbed dialog boxes, text fields, drop down lists, select bar/highlights, expandable dialog boxes, expandable lists, disabled controls, and cursors.

Representing the Users’ Choices – Use removable tape for having the user record his/her actions is important for recording/remembering what a user does when making a choice or selection.  Having the observer monitor and record the computer actions is too cumbersome. 

Hand-Drawing versus Screen Shots – As previously stated by the Frick and Boling handbook, hand drawn is normally fine.  In fact, boxes and words may be all that is needed, instead of trying to draw GUIs.  i.e., don’t draw a logo. Use a box with the word “logo” to represent a logo.  The exception is when the GUI is needed for making a choice and you feel it is needed to convey a concept – selecting the right GUI.

Simulating Interaction – The one exception to “paper prototyping can do anything good enough” is when it comes to simulating interactions.  For interactions, the observer may need to make exceptions and be willing to provide answers and/or oral guidance – brief before you start the test.  Examples that may be exceptions:  Tooltips/Mouse-overs, Rollover/pop-up menus, Beeps, Drag and Drop, Right mopuse menus, Sliders, progress indicators, Animation and video, Web site links, Scrolling

Beyond the Computer Screen – Incorporating Other Elements.  These are the interfaces the user will have to interact with that are not on the screen.

Hardware Props – Items that may be needed as an interface part of the ultimate web based course, and include:  Cameras, Tape backup systems, Portable MP3 players, Touch screen control panel, and inter-connecting cables.  The Keyboard is not normally included as its use is well understood and should not be a problem.

Hardware Devices – Used for building training for real equipment, when the student will have access to the real equipment to practice on?  She is discussing simulating tasks not directly involving a computer screen.  Her example is simulating a can crusher.  I am not sure how this would translate, unless we are building training on how to operate the can crusher and she is recommending we build a 3D mock-up to simulate it.  I would be hesitant to tell the student to go practice on their own without guidance/supervision.  But, what if it is a school house where a “safe” simulator is provided for free play and exploration before going to the real thing?

“Incredibly Intelligent Help” – This is needed or used to help the student when they get stuck.  It can be used to simulate a “help Desk” or similar Expert System.  The “help” may be a single designated person.  Have them start with short answers and build on the answer as needed.  Record all questions and the amount of help required to get the student back on track.  Is this the start of a FAQ?

Human Actors – use when they would be simulating the need to access real people; for example, when calling a 1-800 number or doing a phone interview.  Do not have the tester and observer looking at each other.  This might be a designated person – not the normal observer.

Wizard of Oz testing – Paper prototyping is a type of Wizard of Oz testing where a person (the observer) is playing the role of the technology. Rarely, Wizard of Oz testing can require the observer or some other person to provide more advanced simulations use a computer or other technology.  It is especially useful when the technology is not fully developed yet. 

Documentation, Help, and Training – This section is for people working on documentation, help, or training for an interface.  It included three tips/areas to focus on: Content and Method of Access, Preparing Material for Testing, and Prioritizing the Informational Needs.

CONCLUSION

To me, some of her ideas come across as a cross (blending) of war-boarding (A type of storyboarding used for developing proposals), prototyping, and storyboarding.  She recommend using a storyboard in a format – a poster board – that won’t fit in a std loose-leaf binder from the Frick and Boling book.

It is obvious, that as an ID I do not know or understand the vocabulary of the IT programmer.  I needed to have a glossary of terms as I read her article since she used terms I am not aware of.  She keeps using the term widget and I didn’t really know what a widget is/was.  I used dictionary.com as my glossary. 

• Widget – an application, or a component of an interface, that enables a user to perform a function or access a service.
•  Blinder - Something that prevents someone from gaining a full understanding of a situation.

As I stated in my previous blog (Frick and Boling Chapter 3 and 4 Summary), I still think this process looks rather cumbersome and time consuming – unless it is used for a brand new project with new ideas and concepts the designer/developer is not familiar with.  For example, we normally develop for desk top and laptop screens and not for mobile devices.  As the Navy and DoD starts to explore mobile devices I am staring to see how prototyping may be useful for the first project.