sit in your project #2 groups · cis4930 / cis6930: user experience design instructor: dr. lisa...

CIS4930 / CIS6930:USER EXPERIENCE DESIGNINSTRUCTOR: DR. LISA ANTHONY

Fall 2015

9/24/2015CIS4930/6930 User Experience Design, Fall 2015 -- Dr. Lisa Anthony -- [email protected] 1

SIT IN YOUR PROJECT #2

GROUPS

USER PERSONAS, SCENARIOS, AND STORYBOARDS + IN-CLASS ACTIVITY

Week 5b


TOPICS


• Understanding User Needs

• Requirements

• User Characteristics + Personas

• Understanding User Tasks

• Scenarios

• Storyboards

• In-class activity

Tagline: From User Research to User Needs….

UNDERSTANDING USER NEEDS

User Personas, Scenarios, Storyboards


UNDERSTANDING USERS’ NEEDS


• How do we find out what users needs are for a certain interaction?




• What kinds of tasks / activities do they want to do?

• What are the steps involved in those tasks / activities?

• What order do they want to perform the steps in?




• Ask your users …




• Ask your users …

• User research!

• Discussed methods for doing this during week 3 (Lecture 6) and you’re engaged in this process now for Project #2.

DATA GATHERING REVIEW


• Focus on identifying the stakeholders’ needs:

• Involve all the stakeholder groups.

• Involve multiple representatives from each stakeholder group.

• Use a combination of data gathering techniques:

• Run a pilot session.

• Support the process with props such as prototypes and task descriptions.

• Consider carefully how to record the data.

From IDRSP, Ch.10, p.370

DATA INTERPRETATION AND ANALYSIS


• Start soon after data gathering session.

• Initial interpretation before deeper analysis.

• Walk through the data and write interpretations of:

• Everything the user said.

• Everything the user did.

• Themes that emerged (positive or negative).

• Breakdowns in existing practice/apps/situation.

• Opportunities for new practice/apps/situation.

NEXT…


• We’ll talk about translating from data from your user research into a picture of the user you can use to inspire design…

QUESTIONS?


REQUIREMENTS



WHAT ARE REQUIREMENTS?


WHAT ARE REQUIREMENTS?


• “A requirement is a statement about an intended product that specifies what it should do or how it should perform.” (IDRSP, Ch.10, p.355)

• Many different forms, many levels of abstraction

• Goal: ensure requirements are as clear as possible and include clear success criteria to tell when they have been fulfilled

IMPORTANCE OF REQUIREMENTS


From IDRSP, Ch.10, p.354

How the customer explained it

How the project leader understood it

How the analyst designed it

How the programmer wrote it

How the business dev. described it

How the project was documented

How operations installed it

How the customer was billed

How it was supported

What the customer really needed

TYPES OF REQUIREMENTS


• Functional requirements – what product should do

• Data requirements – what is the type, volatility, size/amount, persistence, accuracy, and value of the required data

• Environmental requirements – what is the context of use, the circumstances in which the interactive product will be expected to operate

• Ex: physical, social, organizational, technical

• User requirements – who are your users, what are their capabilities, needs, and expectations

From IDRSP, Ch.10, p.357-360

Focus of this course

REQUIREMENTS ANALYSIS


• “…the activity of investigating and analyzing an initial set of requirements that have been gathered, elicited, or captured.” (IDRSP, Ch.10, p.355)

• Use the interpretation of the data, rather than the facts themselves, to inspire design.

• Developing requirements is an iterative process.

• Requirements must be based on a sound understanding of user needs.

• Requirements must be justified by the data, and must relate back to the data.

QUESTIONS?


PERSONAS



WHO ARE YOUR USERS?


• Characteristics: ability, background, attitude to computers

• System use: novice, expert, casual, frequent

• Novice: step-by-step (prompted), constrained, clear info

• Expert: flexibility, access/power

• Frequent: short cuts

• Casual/infrequent: clear instructions, e.g., menu paths

WHAT ARE YOUR USERS’ CAPABILITIES?


• Size of hands: affects the size, positioning of input buttons

• Motor abilities: affects suitability of input / output devices

• Height (if designing a physical kiosk)

• Strength: a child’s toy requires little strength to operate, but greater strength to change batteries

• Disabilities (e.g., sight, hearing, dexterity)

PERSONAS


• A persona is a fictional personality profile developed “to help a team identify and understand its target audience” (Pruitt and Grudin, DUX 2003).

PERSONAS



• Personas are “rich descriptions of typical users of the product under development that the designers can focus on and design the product for” (IDRSP, Ch.10, p.360).

PERSONAS



• Personas are “rich descriptions of typical users of the product under development that the designers can focus on and design the product for” (IDRSP, Ch.10, p.360).

• Otherwise, teams might be tempted to think of how they would want to use a product rather than the true audience.

• A persona helps ground communication among team members – a common point of reference.

• “Would Alan like this feature?”

TIPS ON PERSONAS

9/24/2015CIS4930/6930 User Experience Design, Fall 2015 -- Dr. Lisa Anthony -- [email protected]

• Not real people, but synthesized from real user characteristics

• Should not be idealized (e.g., no stereotypes)

• Bring them to life with a name, characteristics, goals, personal background

• Develop multiple personas

26

EXAMPLE PERSONA


Source: http://www.user.com/persona-example.htm

EXAMPLE PERSONA


Source: IDRSP, Ch.10, p.360

WHY PERSONAS?


• Personas help designers and developers get into the mind of the user.

• Humans are very good at predicting another person’s behavior through understanding / empathy of mental state.

• Ability starts developing as children and we refine via experience.

• Personas offer a structure to allow designers and developers to project what will happen in new situations for target users.

• Also: power of narrative, availability of detail.

CREATING PERSONAS


• Personas are created based on:

• Market research

• Quantitative studies

• Observational studies

• …and more

• Use what you know about the target users from your user research.

• Interpretation of the data.

• Listen to what the users say, go beyond to what they mean.

CRITERIA FOR GOOD PERSONAS


1. Is the persona based on contextual interviews with real customers?

2. Does the persona evoke empathy by including a name, a photograph and a product relevant narrative?

3. Does the persona appear realistic to people who deal with customers day to day?

4. Is each persona unique, having little in common with other personas?

5. Does the persona include product relevant high level goals and include a quotation stating the key goal ?

6. Is the number of personas small enough for the design team to remember the name of each one, with one of the personas identified as primary?

7. Can the development team use the persona as a practical tool to make design decisions?

From http://www.userfocus.co.uk/articles/personas.html

TYPES OF PERSONAS


• Focal – Primary users of the product who are its main focus. We will optimize the design for them. At least one persona must be a focal persona.

• Secondary – Also use the product. We will satisfy them when we can.

• Unimportant – Low-priority users, including infrequent, unauthorized or unskilled users, as well as those who misuse the product.

• Affected – They don’t use the product themselves, but are affected by it (for example, someone who gets reports from a user of a application, or the spouse of someone using a travel Website to plan a trip).

• Exclusionary – Someone we’re not designing for. It’s often useful to specify this to prevent nonusers from creeping back into product development discussions.

From http://www.interactionbydesign.com/presentations/olsen_persona_toolkit.pdf

TOOLKIT FOR PERSONA CREATION


• List of possible persona creation components, including:

• Biographic information

• Relationship to the business (and vice versa)

• Goals / needs / attitudes

• Knowledge / proficiency

• Context of usage

• Characteristics of usage (interaction, information, sensory / immersive, emotional)

• Accessibility

• Design issues

• Relationships between personas

• Any one persona will not define details for all components; focus components on those most critical to this persona and the product.

From http://www.interactionbydesign.com/presentations/olsen_persona_toolkit.pdf

CHALLENGES OF PERSONAS


• Making sure your personas are representative

• Not very re-usable, designed for one context (one project / product)

• Creating personas that work for multiple teams(e.g., marketing and development)

• Creating personas for their own sake or over-usingthem (to the detriment of iterative user research and actual product evaluations)

• (From Pruitt & Grudin, DUX 2003)

QUESTIONS?


UNDERSTANDING USER TASKS



UNDERSTANDING USER TASKS


• Task descriptions are often used to envision new systems or devices.

• Task analysis is used mainly to investigate an existing situation.

• (but both can be used, depending on design phase)

• Focus only on key activities:

• What are people trying to achieve?

• Why are they trying to achieve it?

• How are they going about it?

TASK DESCRIPTIONS

9/24/2015CIS4930/6930 User Experience Design, Fall 2015 -- Dr. Lisa Anthony -- [email protected]

• Scenarios – an informal narrative story, simple, ‘natural’, personal, not generalizable

• Use cases – assume interaction with a system; assume detailed understanding of the interaction

• Essential use cases – abstract away from the details; does not have the same assumptions as use cases

38

Focus of this course

QUESTIONS?


SCENARIOS



SCENARIOS


• A scenario is a written story explaining how a user will use a product to achieve a goal.

• Also: “a story with a setting, agents, or actors who have goals or objectives, and a plot or sequence of actions and events” (Cooper, 1999).

• Similar to a use case (but has more context).

• Components:

• Personas – who will be using the system

• Context – how will the interaction start

• Goals – what are the user’s goals (prioritized)

EXAMPLE SCENARIO


• A sample user:

• “Fred Fish is the manager of a group of cafeteria managers at corporate offices in eastern Massachusetts. He uses a computer in his work, but he's a chef by trade. A computer is just another tool for getting his administrative tasks done.”

• A usage scenario for this user:

• “Fred wants to work more efficiently, so he's going to try sending the monthly menu suggestions by email instead of fax. He realizes that he has two choices: write each menu directly in a mail message, or attach a formatted text file. He's never done an attachment, so he decides to try that. After writing up the information (which he's done many times before), he goes to the mail program and looks for how to attach the file. He looks through the toolbar, but doesn't recognize anything. He looks through the menu bar but nothing makes sense right away. Eventually he finds a menu with two interesting choices: Attach and Attach File. Attach has a submenu, but there's nothing on it, so he tries Attach File. Choosing that brings up the familiar File Open box, so he finds his file and clicks OK. He sees the filename in the header of the message, so he assumes that it's working. Because he's never done this before, he includes himself in the CC list so he can check the message to see if the document was sent along with it. He sends the message and finds that it did, in fact, work.”

Source: http://www.user.com/scenario-sample.htm

EXAMPLE SCENARIO


• A sample user:





A sample user:“Fred Fish is the manager of a group of cafeteria managers at corporate offices in eastern Massachusetts. He uses a computer in his work, but he's a chef by trade. A computer is just another tool for getting his administrative tasks done.”

EXAMPLE SCENARIO


• A sample user:





A usage scenario for this user:“Fred wants to work more efficiently, so he's going to try sending the monthly menu suggestions by email instead of fax. He realizes that he has two choices: write each menu directly in a mail message, or attach a formatted text file. He's never done an attachment, so he decides to try that. After writing up the information (which he's done many times before), he goes to the mail program and looks for how to attach the file. He looks through the toolbar, but doesn't recognize anything. He looks through the menu bar but nothing makes sense right away. Eventually he finds a menu with two interesting choices: Attach and Attach File. Attach has a submenu, but there's nothing on it, so he tries Attach File. Choosing that brings up the familiar File Open box, so he finds his file and clicks OK. He sees the filename in the header of the message, so he assumes that it's working. Because he's never done this before, he includes himself in the CC list so he can check the message to see if the document was sent along with it. He sends the message and finds that it did, in fact, work.”

CRITERIA FOR GOOD SCENARIOS


1. Acts as a bridge between an initial design idea or problem and a solution

2. Advances the fidelity of an idea

3. Stands on its own, without explanation

4. Does not prescribe interface elements in any great detail

5. Includes a rich description of a person

6. Includes a rich description of a goal

7. Is credible

From http://library.ac4d.com/d/AC4D_designlibrary_UseCasesScenarios.pdf

STEPS TO WRITING SCENARIOS


1. Identify the people involved

2. Identify the starting state / context

3. List the goals a user may have, as they pertain to your product or service

4. Prioritize the goals based on your understanding of your users

5. Craft stories

From http://library.ac4d.com/d/AC4D_designlibrary_UseCasesScenarios.pdf

QUESTIONS?


STORYBOARDS



TYPES OF STORYBOARDS


• Sequential storyboards

• State transition diagrams

• Branching storyboards

• Best used during later design phases (prototyping)

• Mainly focus on showing interface screens

• Narrative storyboards

• Best used during early design phases

• Show both interface and user in context of use

• What we will focus on in this course

NARRATIVE STORYBOARDS


• A narrative storyboard is an illustrated scenario (comic-book style):

• Each panel emphasizes one step in the story.

• Sketch user’s interactions with digital products.

• Emphasize state and transitions (user actions).

Source: http://library.ac4d.com/d/AC4D_designlibrary_worksheet_Storyboarding.pdf

EXAMPLE NARRATIVE STORYBOARD


Source: http://library.ac4d.com/d/AC4D_designlibrary_Storyboarding.pdf

WHY NARRATIVE STORYBOARDS?


• Illustrations include the elements of physical context necessary to tell story of interaction…

• Why is it important to put people in their physical context?

• Cultural / interpersonal relationships

• Workflow or information handoffs

• Sequence of use

• Evolution of your product over time

From http://library.ac4d.com/d/AC4D_designlibrary_Storyboarding.pdf

CRITERIA FOR GOOD STORYBOARDS


1. Emphasizes screens over scenes

2. Advances the fidelity of an idea

3. Stands on its own, without explanation

4. Dedicates one panel to one idea, and uses panels generously

From http://library.ac4d.com/d/AC4D_designlibrary_Storyboarding.pdf

TIPS FOR CREATING STORYBOARDS


• Should you show the user in the scene?

• What key frames should anchor the sequence?

• What key transitions should be shown?

• What annotations are needed to make storyboard understandable? (should be minimal!)

From SUEWB, Ch.4, p.148

QUESTIONS?


IN-CLASS ACTIVITY: PERSONAS, SCENARIOS, AND STORYBOARDS



IN-CLASS ACTIVITY


• You should be sitting with your Project #2 groups…

• TAs are handing out activity sheets…

IN-CLASS ACTIVITY


• Spend the next 20 minutes on the scenario activity.

• Use your Project #2 context.

• Start by creating (simple) personas for the characters in scenario(s).

• Base them on any user research you’ve already done, or create general personas based on your knowledge of domain.

• Write scenario(s) out in text.

• Do not include implementation details in your scenario(s)!

IN-CLASS ACTIVITY


• Let’s discuss…

• Now we will hear from as many groups as possible. Read us your scenario.

• 15 minutes

IN-CLASS ACTIVITY


• Spend the remaining time on the storyboard activity.

• Use your Project #2 context.

• Illustrate one of the scenario(s) you created today.

• Discuss how to frame the storyboard as a group. Everyone should give a try at sketching the storyboard individually.

• Continue activity after class as part of Project #2.

QUESTIONS?


TAKE-AWAY POINTS


• Successful, iterative interpretation of the data from user research is critical to inspire design.

• Personas capture user requirements, and should be representative users, not specific users.

• Narrative storyboards include details of context of use.

• Why use personas, scenarios, & storyboards?

• Identify your user audience…

• Understand what they would like to do with your product…

• Extrapolate to new situations…

• Communicate your ideas to your team, customer, manager…

• Don’t worry about drawing ability! Practice simple symbols, build up sketches piecemeal.

FOR NEXT TIME…


• Slides will be posted after class.

• Readings through Week 8 are already posted on Canvas, or links are given on the website.

• Finish your discussion posts for Week 5 on Canvas.

• Posts can cover classroom topics or reading topics or both.

• Due: 11:59pm Sunday September 27th.

• Grad students: post Week 6 facilitating questions.

• Keep going on Project #2.

• Groups are formed. You should be doing user research.

• Post questions about the assignment on Canvas.

• Next time: in-class working session for Project #2!

END


sit in your project #2 groups · cis4930 / cis6930: user experience design instructor: dr. lisa...

Documents