From Scenarios to Paper Prototypes Chapter 6 of About Face Defining requirements Defining the...

20
From Scenarios to Paper Prototypes Chapter 6 of About Face Defining requirements Defining the interaction framework
  • date post

    21-Dec-2015
  • Category

    Documents

  • view

    213
  • download

    0

Transcript of From Scenarios to Paper Prototypes Chapter 6 of About Face Defining requirements Defining the...

From Scenarios to Paper Prototypes

Chapter 6 of About Face Defining requirements Defining the interaction framework

Defining requirements Steps:

Problem and Vision statements Brainstorming Identifying persona expectations Scenarios Identifying needs

Persona based Scenarios “a concise description of a persona

using a software-based product to achieve a goal“ [Cooper, Inmates are Running the Asylum, pg. 179]

Derived from information gathered during User Modeling (interviews etc)

Context Scenarios Focus on Context Scenarios

Textual description Broad outlines of how someone

interacts with your application Not a description of interaction details

like dialogs. Focus on goals, don’t worry yet about

how things will be accomplished

Questions addressed by Context Scenarios (Cooper, pg 80) What is the setting in which the product will be used? Will it be used for extended amounts of time? Is the persona frequently interrupted? Are there multiple users on a single

workstation/device? What other products is it used with? How much complexity is permissible, based on

persona skill and frequency of use? What primary activities does the persona need to

accomplish to meet her goals? What is the expected end result of using the product?

Identifying needs List what needs to be in the application

to satisfy the context scenario Data needs: objects and information Functional needs: operations need to be

performed on objects“Call (action) a person (object) directly from

an appointment (context)” Similar to tasks, but also includes the

objects

Defining the interaction framework

Note –This diverges from Cooper’s steps.

Determine Form Factor and Input methods: Tablet using pen

Construct Key Path Scenarios Paper prototype

Determine functional and data elements

Construct Key Path Scenarios Spell out the gritty details at the

task level for the primary actions and pathways through the system E.g. For email: viewing and

composing mail Start with a list of tasks Interaction best shown through

paper prototypes (Cooper calls it storyboarding)

Paper Prototypes Prototypes using paper that

represent of the user’s interaction with the application

Advantages: Easy and fast to create Hand drawn nature focuses on structure

of interaction rather than on visual features (icon design etc)

Encourages users to suggest change

Paper Prototypes You do a paper prototype for a

particular set of key path scenarios Complete high-level menu structure

and interactions All the dialogs, menus, etc to

complete the key path scenario(s) Include “real” data in the

prototype so users have context

Functional & Data Elements Look back at the needs you

identified and think about how those needs will be supported in the interface Panes, frames, other containers Individual on-screen buttons, menus,

controls needs Groups of on-screen controls

Questions to consider

Which elements need a large amount of real estate and which do not?

Which elements are used together?

In what sequence will a set of related elements be used?

Building the paper prototypes One piece of paper or card stock is the

screen Put everything that might need to move

on a post-it (pull down menus, buttons, ..) Windows: pieces of paper, decorate

windows with title bar Pull-down menus, name goes on window,

contents on a post-it. Draw buttons, check boxes on windows

Paper prototype examples

Interviewing with a paper prototype Don’t do a demo. Give user a task to accomplish with

prototype (e.g. grade this assignment) Critical that this user actually does the work

your application is for Ask the user to talk out loud as they do

things, explaining what they are doing. Be flexible – the user is never wrong,

adjust the prototype to meet their expectations

Team responsibilities One person facilitates the interview,

talking with the user and acting as “super help”.

One person acts as the “computer” making the prototype work as it should Have another person assist the “computer”

if there is lots of data to configure on the spot (write on post-its)

Everyone else takes notes

Online references User Interface Engineering

Five Paper prototyping tips http://world.std.com/~uieweb/paperproto.htm

Using Paper prototypes http://world.std.com/~uieweb/paper.htm

Online Computer Library Center Nice step by step article of how they do paper

prototyping http://www.oclc.org/usability/prototyping/oclc.htm