The UX of User Stories, Part 1

95 Replies

If you are a UX designer who wants to quickly get up to speed with integrating Agile and UX, there are few better places to start than with User Stories. They are both a quintessential embodiment of Agile thinking (i.e. if you understand User Stories, you understand Agile thinking) and a potential power tool for a UX designer on an Agile team. But like any tool, they can be highly effective, or, if you have no idea how stories work, cause some serious damage, especially to the UX dimension of your product. So, if you’re using User Stories or thinking about adopting them as a tool, here are ten tips to help UX designers understand User Stories (we’ll just call them Stories from hereon) and wield them to both yours and the team’s benefit.

1. Know What the Story Is

Ok, first things first. Before we can offer any advice about stories we need to understand what we’re talking about. Take a look at this and tell me what it is:

As a substitute teacher, I want to view a list of all students in my course, so that I can call on them by name.

If your practice has been raised on a steady diet of document-centered design processes, i.e. work that revolves around and culminates in the creation of documents, like specifications or use cases or whatever, you can be forgiven for looking at the above card and thinking that you are looking at a story.

The card is not the (whole) story
Yes, the above definitely is a story card, but the actual story is not on the card. This might be confusing, but bear with me here. The statement on the card is only what one can think of as the title portion of the story. The full story is the conversation triggered by the statement on the card. In other words, the complete story, i.e. all the excruciating details about the given feature, live in a self-maintaining, self-updating data store, namely the team’s collective memory. Therefore, in whatever moment when someone picks up a card and has a conversation with other team members, the statement on the card triggers the most current knowledge about the feature by those team members.

The idea of storing project information in collective team memory might sound funky, but not only does it make a lot of sense—information in a modern software project is too fast-moving and volatile for document storage to be able to keep up—but collective team memory is, by its nature, always up-to-date. All that is needed are the correct words that will trigger the appropriate memory, and resulting conversation. And that is what goes on a story card.

If you’re still skeptical about this concept, you should know that you probably use this technique yourself on a regular basis, such as when writing a todo list. When writing a todo list you don’t write down every last detail about the thing you need to do, but only just enough so that you won’t forget to do it and, when the times comes to complete the todo item, you’ll remember all the details about what needed to be done. Stories work the same way, except that in this case its a team-wide todo item, as well as a team-wide communication device.

Stories are a whole-team communication interface

Stories are a communication interface between team members

Each team members looks upon and uses the same story from the vantage point of their particular work

When you hand the same card to a different team member, each team member will look at it from a different perspective, and use it in a different way. In more pontificating terms, this is what is known as a boundary object. For a user, it describes a needed or desired feature. For a developer, it describes a feature that needs to be estimated and/or work that will need to be completed. For a UX designer, it describes a puzzle piece to be fit into a product offering (or not) to create a coherent and valuable experience. For a tester, it describes something for which a test likely needs to be written. And so on, for each team member. One story; multiple perspectives.

If you understand these various perspectives and the way in which a story gets kicked around between team members, then you’ll have a good mental model of how the Agile project game is played, and where you can best position yourself on the field to move the story to the finish line.

2. Make Personas the voice of the story

In contrast to old-school requirements, which are written from the perspective of computers, i.e. “The System shall…” do this or that, Stories are written from the human perspective, e.g. I want to be able to do this or that. This shift in perspective is a great example of how Agile is much more human-centered compared to waterfall. But when bringing UX practice to Agile, we have an opportunity to take this even further, as part of integrating Personas, by making the Persona the voice of the story.

In other words, if we do a Persona workshop in the early stages of the project, each story that is created should correspond to one or more Personas. Let’s say our substitute teacher persona is Becky. After putting in all that work into modeling Becky, we can now leverage that in how we create and talk about our stories. For example, we can add a Persona prefix to our story statements:

Becky says:
As a substitute teacher, I want to view a list of all students in my course, so that I can call on them by name.

With this short prefix, we’ve both made the user feel more real, and in conversations about this story, we can talk about what Becky would want or not want, rather than what some anonymous and disembodied substitute teacher would want.

3. Have users write the stories, not you

For an advanced Agile team, this is Agile 101, but if you’re new to Agile, you may be sitting there frantically trying to write story cards while users are telling you what they want. However, a key aspect of an Agile approach to engaging users or team members is active collaboration and creation of artifacts by the team rather than by individuals. In the case of stories, this means that you create contexts in which users write their own cards. There are numerous ways of doing that. One is the Paired Interviews technique I wrote about recently. That, in turn, is a type of cardstorming activity, which more commonly is done individually, with each team member creating as many cards as they can within a short (e.g. 5-minute) timebox, followed by self-organized group chunking and prioritizing. Additionally, the overall project infrastructure should be such that cards are available at arms-length virtually wherever you are working (e.g. place cards and markers at the center of every table, and scattered strategically throughout your team room), such that you can capture cards at the speed of conversation.

So why is it so important that the users write the stories? One main reason is that they will then phrase the card in their own domain-specific language, and in a way that is likely to most effectively trigger the appropriate memories when you ask them about the card down the road. And on that note, if the cards are written by hand, their handwriting can be used for card traceability, i.e. you’ll be able to know who wrote the card just by looking at it. And if you are gathering info from many users, well, then they will be able to produce far more cards as a group than you could on your own.

4. Be sure to get your “so thats”

As you may have noticed, the above cards are written in what has become a standard structure for writing stories:

As a [user role]…I want to [be able to do something]…so that [it will provide value in this way].

Now, while there is nothing that says you need to phrase your stories in this way (and when you are capturing new stories, you probably want to just jot down a couple keywords, and write the story in long form later), it is important to be aware of the relationship between the “so that…” part and UX. Looking at our earlier example with our substitute teacher Becky, the “so that” reveals the Why of the story. It reveals both the motivation behind the story and often also can reveal something about the context. However, when trying to get a lot of stories created in a short amount of time, this part is often skipped. And that’s understandable. However, it is important to then be sure to go back at a later point and get your “so thats.”

To understand why, let’s look at an example where the “so that” is missing.

As an auto mechanic, I wants to be able to search auto parts visually.

Hmm, why would searching visually be so important? In a later conversation with an auto mechanic, he explains: ”I want to be able to search visually, so that I can find and visually match the part in the search results to the physical part as well as see in the search where in the engine or vehicle the part should be located, to make sure I am ordering the right part.” Wow, the “so that” part suddenly revealed a desire for a completely custom visual search interface and a desire to be able to search while working on the car, meaning maybe searching with greasy hands and lying on your back. Seriously valuable intel. Make sure you get those “so that’s” people!

5. Don’t confuse Story Maps with User Interface

Team reviewing a story wall for story completeness

While a story wall provides a good overview of the product, it is much harder to evaluate for completeness compared to a user interface.

Story mapping is a powerful way for managing stories and offering a big-picture view of the product. But it is also a far more abstract view of the product compared to the corresponding user interface. It is virtually impossible for a Product Owner or other domain expert to look at a story map and say, yup, looks like we’ve got all the stories there. You have to actually flow through it in a user interface to see what is missing. In other words, after you’ve developed your story map and think you’ve got good story coverage, assume you’ll be uncovering a good chunk of new stories as part of designing the user interface.

Additionally, even though you may have organized your story cards into thoughtful silos that reflect the structure of your product or domain, that can easily be confused with an actual user flow, in which the reality is that users may be jumping around back and forth between your different silos, even if your silos have been organized in an order that generally matches your domain’s workflow.

Therefore, create story maps and use them for all the reasons that they are powerful, but quickly start to generate user interface concepts based on the cards in the story map to uncover aspects of the product that stories, by themselves, often are not very good at revealing.

To be continued…

This post got to be pretty long, so I decided to break it up into two parts. Read part 2, in which I talk about other key factors UX designers should consider when working with Stories, such as story context, story coverage, and story estimation.