Scenarios and Personas Rikard Harr November 2010.

Scenarios and Personas

Rikard HarrNovember 2010

© Rikard Harr 2010 3

Outline

• Scenarios– What is a scenario?– Schemata and the Potts’s paper (1995)– Scenarios throughout design (Benyon et al. 2005)

• Personas– Previous use and origin of personas– Pruitt and Grudins use of personas ”the process”– Risks/problems/critique of Personas


What is a scenario?

• “A scenario is a story with a setting, agents, or actors who have goals or objectives, and a plot or sequence of actions and events.” (Carroll, 2000)

• “Narrative descriptions of interactions between users and proposed systems” (Potts 1995)

• Scenarios have:– Their starting point in descriptions of system and user goals– Main characters with goals– Background info from the start– A point that make them interesting

• Scenarios clarify design thinking in several ways:– Comparison of competing system proposals– When a goal can be fulfilled in several ways scenarios can be

good for comparing different courses of action– Useful for thinking through the consequences of goal-blocking

obstacles


Potts’s paper

• Concentrates on scenarios for understanding user needs

• Because of their concreteness scenarios can help people assimiliate complex and abstract descriptions

• Identified risk of inflation• Presents a schema for helping designers, a schemata• Scenarios must be salient i.e. have a point and

correspond to a goal• Writing and using scenarios:

– Defining and decomposing goals– Assigning goals to system and environmental actors– Providing operational definitions of goal-achieving and goal-

maintaining actions– Identifying obstacles to goal fulfillment– Elaborating subgoals or actions to defend against the occurrence

of obstacles or to mitigate their effects


Creating scenarios

• Each goal and obstacle is represented by one episode

• A set of salient scenarios is constructed in which each scenario has a single “point”

• Each scenario is constructed according to the scenario schema


Scenarios throughout design

• Useful throughout the design process• Benyon et al. (2005) identify four different types of

use

User stories Conceptual scenarios

Concrete scenarios

Use cases

Use for understanding what people do and what they want

Use for generating ideas and specifying

requirements

Use for prototyping ideas and evaluation

Use for documentation

and implementatio

n

AbstractSpecify Design

ConstraintsFormalize

Design


User Stories

• Real-world experience of people, ideas, anecdotes and knowledge

• Can be captured in different ways• Brief descriptions of activities and their context• Example: I needed to make an appointment for

Kristy, my little one. It was urgent – she had been having a lot of bad ear-ache every time she had a could – but i did want to see Dr Fox since she’s so good with the children. And of course ideally it had to be when Kirsty was out of school and I could take time off work… (Benyon et al. 2005)


Conceptual scenarios

• More abstract• User stories are combined by designers• Patterns emerge• A number of stories results in one conceptual

scenario• Example: (Booking an appointment) People with

any degree of basic computer skills will be able to contact the doctors’ surgery at any time via the internet and see the times which are free for each doctor. They can book a time and recieve confirmation of the appointment. (Benyon et al. 2005)


Concrete scenarios

• Each conceptual scenario might generate several• More concrete versions• Notes can highlight certain problems or design

features• Begins to dictate interface design and functionality• Useful for prototyping• Example: Andy Dalreach needs a doctor’s

appointment… the appointment needs to be outside school-time and Andy’s core working hours, and ideally with Dr. Fox… Andy uses a PC and the Internet at work… He logs in [1] and from a series of drop-down boxes, chooses to have free times for Dr. Fox [2] displayed for the next two weeks[1] Is logging in necesarry? Probably, to discourage bogus users, but check with the surgery


Use cases

• Describes interaction between people and devices

• Each use case covers many slight variations in circumstances – many concrete scenarios

• Finally, all design issues are solved and concrete scenarios form the basis for design

• Use case: Booking an appointment

Make appointment

To make an appointment:- Go to doctors homepage- Enter username and password- Select appointment for specific doctor- Browse available dates- Select suitable date and time- Enter patients name- Click OK


Personas

• ”An interaction design technique with considerable potential for software product development” (Pruitt and Grudin, 2003)

• Authors consider Personas to be more engaging than scenarios

• Make use of personas in two projects:– MSN Explorer– Support of the Microsoft Windows product development

team


The personas process

• A persona is a fictional person• Alan Cooper, made early use of personas

– Designers often have a vague idea about who the future user is

– Started out as rough sketches, became more detailed– Others promoted use of abstract representations of users

to guide design, through e.g. Contextual inquiry

• Pruitt and Grudins use of personas differ:– Cooper downplays ongoing data collection and usability

engineering– Underestimate the value of user involvement


Pruitt and Grudins personas

• Personas can aid design, but are more important as complements

• Might help a designer in finding focus• Provides a shared basis for communication• The authors found 4 shortcomings of previous

use1. Not believable characters2. Characters were not communicated well3. Little understanding of how to use the characters4. Projects of grass-rot efforts, little high-level support


Creating and using Personas

• Deciding which Personas to make– Use market segmentation studies, gathered data, strategic

or competitive placement etc.

• Creating the personas– Creating anti-Personas, dedicate people to different

Personas, divided research documents, held affinity sessions

– Writing Personas’ stories– Applied qualitative data and anecdotes– Use of a central foundation document that contains goals,

fears, typical activities – As Persona descriptions are done, models are selected for

photo-shoots


A foundation document


Making use of Personas

• A kick-off meeting is held to launch the Personas• The foundation documents are available for

everyone• Posters, flyers and handouts, email ”persona fact

of the week”• Coopers view of Personas as a discussion tool:

”Would Alan use this feature?”• Pruitt and Grudin expands this use

– Spreadsheet tools and document templates


Personas vs Scenarios

• Easy to predict the behaviour of a Persona while ”a scenario covers what it covers”

• Actors or agents in scenario-based design are typically not defined fully enough to promote engagement


Pruitt’s risks of Personas

• Getting the right Personas is a challenge• Risk of reuse• Persona maniaOther risks or problems• Logics, as personas are fictional, they have no clear

relationship to real customer data and are therefore not considered as scientific (Chapman & Milham, 2006)

• Practical implementation, personas actually distances a team from engagement with real users and their needs Portigal (2008)

• Empirical results, descriptions with more than a few attributes likely describes very few if any real people. Personas cannot be assumed to describe actual customers (Chapman et al., 2008)


The end

Scenarios and Personas Rikard Harr November 2010.

Documents

Transcript of Scenarios and Personas Rikard Harr November 2010.