motivation so that anyone presented
with a scenario for our system can
read the persona and come away
thinking, “Ah, that’s why we need to
do it that way.” Ideally, each persona
should occupy one side of a sheet of
paper. The back of the same sheet
should provide practical information along the lines of, “How would
I know this persona if I saw one?”
used to recruit participants for
research and usability evaluation.
Specific personal details should be
provided to the extent they help the
persona seem like a real person.
More general demographics, however, should always go on the back
(they are not part of the persona
proper; see Figure 2).
Collaborative. Agile is collaborative
at heart. Agile teams make hundreds of detailed design and planning decisions every day. If the core
team does not appreciate or understand the user-experience aspects
of the project, it is likely to fail.
(The popular alternative of specifying the entire user experience in
advance, before any code is written
or any learning has taken place, is
actually a waterfall approach, with
all of the inherent dangers and
drawbacks that waterfall methodology had in the 1980s and 1990s.)
The core team should be involved in
the user research required for personas—at least as observers—and
must be actively involved in the
development of personas. There is
substantial evidence that involving
people in the decision-making process is essential if they are going to
feel any sense of ownership of the
One of the primary goals of personas is to create empathy and motivation for the team. Personas do this
by allowing us to connect emotionally with other individuals rather than
abstract collections such as “users”
or “Single TicketPurchasers” [ 4, 5].
Persona stories. Persona stories
differ from user stories in several
important respects. Persona stories
• …about personas, not roles.
Where it is useful or important to
refer to roles, we simply qualify the
persona name. Let’s say we decide
to characterize a warehouse returns
operative as “Jack.” In many cases we
probably would not need to describe
his role, since it would be obvious
from the story. So a persona story
would be as simple as: “Jack processes a return.” Note that as a persona,
it’s Jack’s behaviors and needs that
are important. It may be there are
other Jacks in our system, probably
working in a cold and dusty warehouse and without particularly good
typing skills (these points would be
part of the Jack persona). So Jacks
might also process pick lists or label
packages for dispatch.
• …in the third person, that is,
about the persona. So the form
is: <persona[:role]> <performs a
task>[so that<unobvious goal>].
The persona:role element is based
on the Unified Modeling Language
notation name:class. An alternative
would be simply to place the role in
parentheses when it is needed. The
optional “so that” clause should be
provided only if the goal of the task
is not obvious. “Julie adds an item to
the shopping basket” does not really
need an explanation.
• …by user experience specialists in collaboration with business
analysts and/or members of the
core team. They are subsequently
elaborated into scenarios and visual
designs (again in collaboration with
the core team) one or two project
cycles ahead of their implementation [ 6]. This avoids the Agile/
Waterfall conflict that is brought
about by up-front UX design.
• …after user research and rough
design. The research is required to
discover the needs and behaviors
of users of interest to a project.
Rough design defines the scope and
shape of our venture. For example,
if we are selling houses, we may
decide that a comparative shortlist
feature is more appropriate than a
shopping basket and would write
our persona stories accordingly.
One of the main benefits of
persona stories, when produced
as outlined here, is they and their
resulting scenarios and visual
designs will be descriptive rather
than prescriptive. That is to say
they describe interactions we have
good reason to believe will work
(because we have done research
and evaluation with real users)
rather than just prescribing what
users must do. It is a subtle but
extremely important difference.
1. Hudson, W. Adopting user-centered design
within an Agile process: A conversation. Cutter I T
Journal 16, 10 (2003), 5–12; http://www.syntagm.
2. Hudson, W. Reduced empathizing skills increase
challenges for user-centered design. Proc. CHI
2009 and BCS HCI 2009 Conferences. 2009; http://
3. Polman, E. and Emich, K. J. Decisions for others are more creative than decisions for the self.
Personality and Social Psychology Bulletin 37, 4
4. Nordgren, L.F. and McDonnell, M.H. M. The
scope-severity paradox. Social Psychological and
Personality Science 2, 1 (2011), 97–102.
5. Sears, D. The person-positivity bias. Journal
of Personality and Social Psychology 44, 2 (1983),
6. Hudson, W. User requirements in the 21st century. Agile Record. 2012. 12–16; http://www.syntagm.
ABOUT THE AUTHOR
William Hudson has been building
interactive systems for more than
40 years, focusing on user-cen-
tered design for the past 20. He
has written more than 30 publica-
tions and is the creator of the
Guerrilla UCD series of webinars ( www.guerril-
laucd.com). He is also the founder and principal of
Syntagm Ltd, a small Oxfordshire, U.K. consultancy
specializing in user-centered design and training.
Copyright held by author
Publication rights licensed to ACM $15.00 i n