Features

XX.6 November + December 2013
Page: 50
Digital Citation

User stories don’t help users: Introducing persona stories


Authors:
William Hudson

User stories are one of the most popular alternatives to traditional user requirement specifications. But despite their promising name, user stories are not about—and don’t necessarily help—users at all. In most cases, user stories are written about roles that users adopt and take no account of the needs and behaviors of real users. Were that not indictment enough, user stories suffer from demonstrable flaws in structure and are often written by the wrong people at the wrong time.

Here, I examine the background of user stories in their current form, highlight their failings, and propose a more appropriate alternative for the development of interactive systems: persona stories.

User stories—as brief scenarios of use written on small cards—were used in the first extreme programming project, C3 at Chrysler, in 1996 and described by Kent Beck in his book eXtreme Programming Explained in 1999. The idea of describing requirements as stories of use has a long history, much of it in human-computer interaction. In Scenario-Based Design, Jack Carroll traces the thinking about scenarios in design back to a 1959 article by C. W. Mills. But it was Ivar Jacobson who, in a 1987 paper on use cases, proposed describing the requirements of industrial systems from this scenario perspective.

Like use cases, early user stories did not have a specific form. The lack of form and consistent content was seen as problematic by some in the Agile community and was addressed by a team at Connextra in 2001. They proposed that user stories should take the form:

  • As a <role>, I want <goal/desire> [so that <benefit>]

Elements in angled brackets (such as role) are to be supplied and elements in square brackets are optional. This style of user story was popularized by Mike Cohn in User Stories Applied in 2004.

User Stories

While there is frequent debate on the value of user stories in general and of the Connextra form in particular, both give rise to substantial issues when viewed from an HCI perspective, which I will address in some detail. In particular, the focus on roles is inappropriate for many systems, and the narrative structure as outlined here is unsuitable for a number of reasons.

The role of roles. A role is a systemizing concept that has widespread use in business and industry. Its primary function is to describe an individual’s activities and responsibilities. In software development, Jacobson made use of roles in use cases (here, quoting Kristen Nygaard from a 1986 lecture): “A role is defined through a specified task or a group of closely related tasks, which are performed by persons during the development and/or operation of a system.”

But roles are not as simple as they might first appear. In Understanding Organizations, Charles Handy devotes an entire chapter to roles and interactions, describing issues such as role ambiguity, role incompatibility, role conflict, role overload, role underload, role strain, and many others. Role ambiguity is particularly relevant to systems design since it describes the lack of clarity that an individual, his or her colleagues, and the organization itself may have about roles. Those of us conducting user research have usually had firsthand experience of this.

Daniel Ilgen and John Hollenbeck describe the issue explicitly: “The simplicity of the role definition as a set of expected behaviors masks the complexity and ambiguity that is discovered as one probes more deeply into the underlying assumptions behind the definition.”

Roles are only a tiny part of the picture when it comes to the needs and behaviors of users. They tell us, approximately, what kind of activities a user may undertake, but they say nothing about how and when tasks are performed. So, for example, we may identify an accounting or bookkeeping role, but we would need to do user research to discover that some tasks are performed many times a day while others are relatively rare. The implications of these differences are significant for interactive systems design.

Larry Constantine and Lucy Lockwood have acknowledged the need for research and role modeling in their usage-centered design process. Constantine and Lockwood’s user roles are more descriptive, including characteristic detail that results in role names such as SingleTicketPurchaser. However, since this role is somewhat tautologous—anyone purchasing a single ticket is by definition a SingleTicketPurchaser—it is hard to see where the role ends and the use case or user story begins. In this instance, applying the Connextra/Cohn form of user story yields: “As a customer I want to purchase a single ticket so that I can travel.”

But herein lies a significant problem. Roles are not particularly useful in consumer-oriented systems. We end up with stories with roles like “customer,” “visitor,” or “subscriber,” which tell nothing about what we call the contexts of use. These contexts cover a range of issues beyond simple role descriptions. And for many systems, these are things that we should research at an early stage.

What we need is an approach to requirements that focuses on those differences in the behaviors and needs of users that will require us to provide substantially different forms of interaction. But first, some more challenges with user stories.

Wrong people. While user stories are the child of extreme programming (XP), they have since been adopted by other Agile approaches, most notably Scrum. In XP and Scrum, user stories should be written by the business, product owner, customer team, or user representative, depending on where and when you look (it changed between the first and second editions of Extreme Programming Explained, for example). But as I argued during the early excitement about user stories, no one person (or even small team) can dictate or represent the needs of users [1]. This is particularly true of users on the Agile team who are almost always chosen for the wrong reasons—after all, you would not select someone who wasn’t particularly good at their job to act in this capacity, but they may actually be much more representative of real users.

There is a further complication that needs to be mentioned. From my own research, using methods normally applied to the study of autism, I found that technology-focused men working in IT had significantly reduced empathy. Figure 1 shows the result of the study for men (EQ is empathizing quotient, SQ is systemizing quotient [2]). These results are indicative of something that had been observed decades earlier by Nathan Ensmenger in his book The Computer Boys Take Over: “Programmers dislike activities involving close personal interaction. They prefer to work with things rather than people.”

Reduced empathy, however, doesn’t just explain the lack of enthusiasm for personal interaction. It also means that technologists, who are very good at building and understanding systems, find it hard to see a problem from a perspective other than their own. And low empathy isn’t confined to technologists; in the normal population, empathizing and systemizing skills are unrelated. So we need to take concrete action to ensure that any artifacts describing users’ interactions with a system are written by someone who has empathizing skills and a good understanding of user behavior, and in such a way as to promote empathy within the team. (Women, on average, have higher empathizing scores than men. Both men and women who were people-oriented in their job roles scored above population averages for empathy in the study.)

Wrong time. In XP, user stories are meant to feed into the planning game (adapted from “The New New Product Development Game,” 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 structurally flawed:

  • 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 counterproductive.

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 monotonous and time-consuming. When we look at how people scan and read material, superfluous words at the beginning of sentences are particularly 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].

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, collaborative personas:

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 different interface necessary. There should be a small amount of back-story (character description) and 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 resulting personas.

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 “SingleTicketPurchasers” [4, 5].

Persona stories. Persona stories differ from user stories in several important respects. Persona stories are written:

  • ... 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.

References

1. Hudson, W. Adopting user-centered design within an Agile process: A conversation. Cutter IT Journal 16, 10 (2003), 5–12; http://www.syntagm.co.uk/design/articles.htm

2. Hudson, W. Reduced empathizing skills increase challenges for user-centered design. Proc. CHI 2009 and BCS HCI 2009 Conferences. 2009; http://www.syntagm.co.uk/design/articles.htm

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 (2011), 492.

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), 233–250.

6. Hudson, W. User requirements in the 21st century. Agile Record. 2012. 12–16; http://www.syntagm.co.uk/design/articles.htm

Author

William Hudson has been building interactive systems for more than 40 years, focusing on user-centered design for the past 20. He has written more than 30 publications and is the creator of the Guerrilla UCD series of webinars (www.guerrillaucd.com). He is also the founder and principal of Syntagm Ltd, a small Oxfordshire, U.K. consultancy specializing in user-centered design and training.

Figures

F1Figure 1. Technology-oriented men showed a marked reduction in empathy (EQ and SQ controls are for the average population). (n=156 men, n=285 women)

F2Figure 2. Suggested content for a minimal persona (front) and recruiting brief (back)

Copyright held by author. Publication rights licensed to ACM $15.00

The Digital Library is published by the Association for Computing Machinery. Copyright © 2013 ACM, Inc.

Post Comment


*

Comments submitted to this site are moderated and will appear if they are relevant to the topic.


@Luis Daniel Rodriguez (2013 11 22)

For an idea on how to move forward with narratives & complexity see “Design Stories Are The New User Stories”: http://www.slideshare.net/uxcodeline/ux-intel-2

@Ralph Lord (2014 02 14)

Lots of food for thought in this short piece Mr Hudson.  Thank you for writing it.
The biggest problem I see with much of this “UX practices squeezed into Lean/Agile build methodologies” is simply that they don’t have the same purposes or goals.  User Stories are just one example and a good one to call out.  I really appreciate your focus on minimal personas.  Those multi-page, fawning biographical sketches often contain little that is useful for guiding development but lots of evidence that your UX team is made of frustrated novelists.

The personas and the user stories (or persona stories, I construct I agree with) are relatively easy for our team to fix.  More challenging is the integration with the Agile process.  I’ve worked on a number of Agile projects and tried a number of different integration methods.  Trying to stay one or two sprints ahead of the Dev team always seems to turn into a frantic race to keep up.  I’m thinking lack of resources has been the reason for this.  Perhaps with a larger UX team we could do it.

Despite the Agile constraint of “no big design” and the fact you’ll be blamed for following a waterfall model (Oh, the shame!) we’re moving towards doing lots of the UX design up front.  Our “Sprint 0” is going to be at least 6 weeks so we can do some research, overall UI framework for the application, development of personas and stories (we’ll be writing Epics with the team), task modelling (our application has many complex and fairly long task flows) and creating assets for the Dev team.

I think this is what you mean by “rough design”.  We just call it “getting ready for the build” by getting all our ducks in a row (geese in line, chickens in order, etc.)  To reference another industrial process, I liken it to the work that an architect does before a house is built.

One last observation from my experience is simply that UX work often takes longer than dev work.  That is to say that if we were to decide how many stories to build in a given sprint by the “UX points” count, our sprints would contain far fewer stories.  Again, this may be a question of resources and could be specific to my experiences.

Maybe that question of how many UX folks you need to keep up with X points of dev work during a sprint is one that deserves investigation.

Thanks again for your insightful article.

@Ashley Cook (2014 03 13)

A very well written article! Thank you for citing the research!

My current team is preparing to build an enterprise set of personas to guide widespread development that Mr Hudson specifically warns against this in his “collaboration” section. My last project purposefully included developers in persona development, as Mr Hudson recommends. We won’t have that luxury with my current project. We are targeting Agile teams as the primary users of these personas. Anyone here have experience developing enterprise personas and can specifically address how to mitigate the “collaboration” risks identified by the author?

@David McNamara (2014 03 16)

I really like this thinking, but I’m struggling to get my head round the practical differences between “User Stories” and “Persona Stories”. Some more examples of implementation would be really useful, contrasting the user and persona versions.

However, if we do nothing other than revise a user story using a persona name and simplify the language by using third-person I think that’s a real improvement, integrating personas into the process and promoting empathy with the purpose of the story.

Thanks.

@mnotess (2014 03 18)

This article makes some great points about design principles, but the proposed revision of how we state requirements in Agile I find uncompelling. For my reasons, see http://www.learningux.com/2014/03/18/personas-again-vs-roles-in-user-stories/ .