DMS 546/446 INTERFACE DESIGN AL LARSEN – SPRING 2008 PAPER PROTOTYPING Lecture draws from multiple sources, including: Jakob Nielsen, Shawn Medero ( .

DMS 546/446INTERFACE DESIGNAL LARSEN – SPRING 2008

PAPER PROTOTYPING

Lecture draws from multiple sources, including: Jakob Nielsen, Shawn Medero ( www.alistapart.com/articles/paperprototyping ), Carolyn

Snyder ( www.snyderconsulting.net/article_paperprototyping.htm )

DMS 546/446INTERFACE DESIGNAL LARSEN – SPRING 2008

A THING

AND

A PROCESS

DMS 546/446INTERFACE DESIGN

Why?


“Paper prototyping is one of the fastest and cheapest techniques you can employ in a design process.” - Jakob Nielsen


Paper prototyping allows you to get user data early.

You can use paper prototyping to test out more than one design concept before settling on the one to implement.


Early user data = bigger improvements in usability

It's cheaper to make changes early.


Paper prototyping is not technology-dependent. (Can be used when the current software platforms are obsolete.)


It is obviously a work-in-progress... not intimidating to user...

“Paper prototypes ... invite people with little-to-no technical background into the design process.” - Shawn Medero


How?


Identify Tasks Design

Build Prototype (screen shots and/or hand-sketched drafts of the windows, menus, dialog boxes, popup messages, etc. needed to perform those tasks.


Removable Glue StickPost-ItsIndex CardsPens, PencilsTransparency for user to write onScreenshot of desktop (?)PDFs of interface graphics for using in paper prototyping (?)http://www.infodesign.com.au/usabilityresources/design/paperprototypinggraphics.asp


Where does paper prototyping fit into the design process?


There are two dominant uses:

1. The design team uses paper for their presentation to a group of people who have a vested interest in the product.

2. The design team observes users as they navigate through the paper prototype.


Conducting a Usability Test


Test users should reflect your user audience

Have scenarios prepared for the user

Document with video to record users' emotions as they use the prototype

Observe/take notes

Debrief afterwards to measure interface recall


You can also...Allow users to mock up ideas they think would solve a problem.

Mark on the prototype where a user attempted to “click” or otherwise interact with the interface.

Ask users to draw what they expect to happen next.


One or two developers play the role of "computer," manipulating the pieces of paper to simulate how the interface would behave.

Give users realistic tasks to perform by interacting directly with the prototype -- they "click" by touching the prototype buttons or links and "type" by writing their data in the prototype's edit fields.

Using transparency or removable tape prevents the prototype from being written on directly.


A facilitator (usually someone trained in usability) conducts the session while other members of the development team observe and take notes.

The “computer” does not explain how the interface is supposed to work, but merely simulates what the interface would do. (Remember card sorting project...)

In this manner, you can identify which parts of the interface are self-explanatory and which parts are confusing.


Prototype only needs to be good enough for you to get answers to the questions you're most concerned about.

Most paper prototypes don't need:

* Straight lines or typed text. If the user can't read something, it's OK to tell them what it says. (But if the user doesn't understand a term, don't explain it -- change it.)

* Images or icons. Use words instead. For example, for the company logo, you can just draw a box around the words "“company logo”. If images are part of the content (a product catalog, for example), you can paste them into your prototype using restickable glue.

* Color. - color can be added later

* Consistent sizing of components.

OK if the prototype looks a bit messy -- if it's legible, it's good enough.


Paper prototyping is especially useful for gathering data about the following kinds of problems:

Concepts and terminology. Do the target users understand the terms you've chosen? Are there key concepts they gloss over or misconstrue?

Navigation / workflow. If there's a process or sequence of steps, does it match what users expect? Do they have to keep flipping back and forth between screens?

Content. Does the interface provide the right information for users to make decisions? Does it have extra information that they don't need, or that annoys them?

Page layout. Do you have the fields in the order that users expect? Is the amount of information overwhelming, not enough, or about right? Functionality. You may discover missing functionality that users need, or functionality you'd planned but users don't care about.


Paper prototyping isn't ideal if your biggest questions pertain to:

Technical feasibility. There should always be at least one person involved at this stage who understands the technical constraints.

Download time or other response time. Scrolling.

Colors and fonts. Although it's a good idea to involve the graphic designer in the paper prototype tests because he may find issues that influence the visual aspects of the final design.

You can use paper prototypes in the early stages to uncover major issues and then do additional usability tests later with high-fidelity prototype or the completed interface.


1. Test your design with users before you code - finding out whether you're on the right track.

2. Make fast changes - You can revise the interface very quickly, even during a usability test.

3. Find out what marketing really wants. (“Bring me a light.”)

4. Eliminate technology variables from the usability testing equation

DMS 546/446 INTERFACE DESIGN AL LARSEN – SPRING 2008 PAPER PROTOTYPING Lecture draws from multiple sources, including: Jakob Nielsen, Shawn Medero ( .

Documents

interface designhow

interface designwhy

interface designconducting

interface designthere

interface recalldms

interface designit

interface designwhere

interface designyou