Scenarios and Personas
Rikard Harr
November 2010
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
© Rikard Harr 2010
3
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
© Rikard Harr 2010
4
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 goalmaintaining actions
– Identifying obstacles to goal fulfillment
– Elaborating subgoals or actions to defend against the occurrence of
obstacles or to mitigate their effects
© Rikard Harr 2010
5
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
© Rikard Harr 2010
6
Scenarios throughout design
• Useful throughout the design process
• Benyon et al. (2005) identify four different types of use
Specify
Design
Constraints
Abstract
Formalize
Design
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
implementation
© Rikard Harr 2010
7
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)
© Rikard Harr 2010
8
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)
© Rikard Harr 2010
9
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
© Rikard Harr 2010
10
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
© Rikard Harr 2010
11
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
© Rikard Harr 2010
12
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
© Rikard Harr 2010
13
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 use
1.
2.
3.
4.
Not believable characters
Characters were not communicated well
Little understanding of how to use the characters
Projects of grass-rot efforts, little high-level support
© Rikard Harr 2010
14
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 photoshoots
© Rikard Harr 2010
15
A foundation document
© Rikard Harr 2010
16
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
© Rikard Harr 2010
17
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
© Rikard Harr 2010
18
Pruitt’s risks of Personas
• Getting the right Personas is a challenge
• Risk of reuse
• Persona mania
Other 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)
© Rikard Harr 2010
19
The end
© Rikard Harr 2010
20