Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations

Presentation on theme: "From Scenarios to Paper Prototypes Chapter 6 of About Face Defining requirements Defining the interaction framework."— Presentation transcript:

1 From Scenarios to Paper Prototypes Chapter 6 of About Face Defining requirements Defining the interaction framework

2 Defining requirements Steps: Problem and Vision statements Brainstorming Identifying persona expectations  Scenarios  Identifying needs

3 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)

4 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

5 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?

6 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

7 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

8 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)

9 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

10 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

11 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

12 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?

13 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

14 Paper prototype examples




18 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

19 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

20 Online references User Interface Engineering Five Paper prototyping tips Using Paper prototypes Online Computer Library Center Nice step by step article of how they do paper prototyping

Download ppt "From Scenarios to Paper Prototypes Chapter 6 of About Face Defining requirements Defining the interaction framework."

Similar presentations

Ads by Google