Personas and Persona Stories
Given the case against user stories,
but the undeniable interest in using
something so relatively immediate
(compared with traditional requirements or use cases), what alternatives do we have? My belief is that
user stories can be adapted to be
more user-centered by changing
their structure and shifting their
focus from roles to minimal collaborative personas.
Minimal collaborative personas.
Although the term persona and its
related concepts in English are quite
old (originating from the Latin for
person), Alan Cooper is the first to
have applied the term to characterize users of an interactive system
during design in his 1999 book,
The Inmates Are Running the Asylum.
Cooper’s goal with personas was to
give designers focus and to make
users seem more like real people.
Personas have since become very
popular in the fields of usability
and user experience, but unfortunately the original purpose has
become somewhat blurred. It is
not uncommon to hear about UX
teams spending many weeks or
even months developing personas;
I have seen individual personas
of six pages in length. These are
not likely to help give developers
focus. Nor is the common practice
of the UX team researching and
writing personas in isolation, then
providing them as a fait accompli
to developers likely to make the
personas seem like real people.
To be Agile we need minimal, collab-
Minimal. Each primary persona
requires a different user interface.
The persona descriptions need to
explain what behaviors and needs
each persona has that make a dif-
ferent interface necessary. There
should be a small amount of back-
story (character description) and
a frequently cited 1986 article in
the Harvard Business Review by H.
Takeuchi and J. Nonaka). But if a
team is going to make estimates and
plans based on user stories, they
need to at least know what needs
to be done and approximately how.
This is particularly true of novel systems, where there are no established
current practices to be described.
That means we need to give some
thought to the purpose, shape, and
size of the system before writing user
stories. Unfortunately, many Agile
adopters believe that design is a bad
thing, even though this is not actually what the Agile Manifesto and its
“Twelve Principles of Agile Software”
say (“big design” up front is bad, but
rough design is not). So, not surprisingly, estimates and plans made
with premature user stories may not
be very reliable.
Structural flaws. I mentioned at
the outset that user stories, certainly
in their Connextra/Cohn form, are
• Roles are not a suitable focus of
attention for many systems.
• The “As a <role> I want…” form
is unnecessarily wordy and repetitive.
• The use of the first person is
Since I have already outlined the
case against roles, let me address the
two remaining points. Even in small
systems there are likely to be scores,
if not hundreds, of user stories. To
read and write “As a <role> I want…”
each and every time is both monoto-
nous and time-consuming. When
we look at how people scan and read
material, superfluous words at the
beginning of sentences are particu-
larly troublesome, since they move
the more important content further
into the text, thereby making it
harder to process.
On the final point listed here,
there are two separate reasons
for declaring that the use of the
first person is unhelpful. The first
reason is very familiar to all who
have worked in usability and user
experience: Many usability issues
arise because developers assume the
users are similar to themselves. In
the majority of cases this is simply
untrue, although reduced empathy
(as discussed earlier) makes this
hard for developers to understand.
In fact, a Google search for the
phrase “you are not the user” produces more than 470,000 results.
The second reason is that thinking about yourself is not actually
as effective in a design context as
thinking about others unknown to
you. In four studies published in
2011, researchers found that participants were more creative and better
able to solve problems when doing
it for distant others (people they did
not know personally) rather than
close others or themselves [ 3].
Name, specific age,
Goals in using
used (how often?)
• Figure 2.
Suggested content for a minimal
and recruiting brief