From Scenarios to Paper Prototypes Chapter 6 of About Face Defining requirements Defining the interaction framework.
Published byModified over 4 years ago
Presentation on theme: "From Scenarios to Paper Prototypes Chapter 6 of About Face Defining requirements Defining the interaction framework."— Presentation transcript:
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
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 http://world.std.com/~uieweb/paperproto.htm Using Paper prototypes http://world.std.com/~uieweb/paper.htm 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 http://www.oclc.org/usability/prototyping/oclc.htm