Konrad Design Thinking Guide 2024User Stories, Maps
and Examples
Learn all about the powerful design tool that streamlines the development of engaging, user-centered solutions
User Story Basics
What is a User Story?
User stories are a powerful way to articulate a specific user goal. They are formatted as a single sentence that outlines: Who the user is, What their goal is, and Why they want it.
By brainstorming dozens or even hundreds of user stories for each user persona, teams scope out the complete solution experience and coordinate all competing interests.
This guide walks through important aspects and practical examples, including how to build comprehensive user story maps for defining UX features and functions.
What makes a good User Story?
Not all user stories are created equal. Common elements of good user stories include:
Specificity
They pertain to a single persona and goal
Clarity
The role, goal and gain are easy to identify
Realism
They are inspired by real observations of users
When brainstorming user stories as a team, consistency is another important factor to keep in mind. Make sure to provide plenty of examples of the specific user story format you want before brainstorming begins. Otherwise, you may find yourself struggling to compare user stories that are more pragmatic vs more poetic.
Stories aren’t the requirements; they’re discussions about solving problems.
How do I create a User Story?
You don’t need to be a copywriter to create a User Story: Just think about one of your user personas and start filling in the blanks. If you get stuck, refer back to your persona and user research for more inspiration. Writing your user stories on Post-Its or pre-formatted lists/spreadsheets can further simplify the sharing and comparing that follows.
Generating User Stories
- Review ONE user persona
- Set a timer for 10-15 minutes
- Write as many stories as possible
The more the merrier. As with all divergent brainstorming activities, quantity is important. Instead of trying to perfect a handful of favorites, exhaust every possible option in the given time. Only once you’re satisfied that all the goals have been captured should you begin to sort them into related groups.
While user stories are easy to write, writing them well does take practice. To learn more about best practices, continue to the user story format and user story examples sections.
How are User Stories organized?
User stories are used to define the requirements of an experience in a format that can be easily shared between strategy, design and technology teams.
In order to do this, User Stories need to be organized into groups according to their related goals. These groups are commonly called “Epics”, and multiple Epics are fall within a top-level “Theme”.
On the other end, each user story can also be split into specific tasks to outline the necessary steps.
Depending on the project, sometimes it’s easier to determine the Epics and Themes first, and brainstorm user stories after.
Use cases vs User Stories
User stories are an artifact of the Agile methodology, and as such are best suited for iterative, user-centered design. Use cases perform a similar role as user stories in Waterfall — i.e. articulating the needs of a specific interface — however, they are far more involved and aren’t as suitable for working through ambiguity. While user stories commonly fit into a single sentence, use cases are more robust documents that outline preconditions, steps in the typical use, alternative paths and more.
| User stories | Use cases |
|---|---|
| Describe a raw user need | Describe complete user interaction |
| Fits within a single sentence | Requires a diagram to visualize |
| Quick to create/compare | Involved to create/compare |
The User Story Format:
A closer look
One of the biggest benefits of user stories is the simplicity of their format: Just identify who the user is, describe what they want and why. Combine those three elements into a single sentence and you will arrive at a truly human-centered design requirement.
That said, there are several equally valid ways to approach the different elements. This section takes a closer look at The Role, The Goal and The Gain and outlines the important levers that design thinking teams have to work with.
- The Role
“As a Product Owner”
As a user-centered design artifact, user stories begin with “The Role”. The role identifies who the “user” actually is, helping build their perspective directly into the design process.
In practice, the Role takes of three forms: It can be the name of their persona, their position in an organization (such as “product owner), or a description of a defining behavior. Regardless of the form you use, they all serve the same purpose: To provide clear behavioral context to the design teams.
Types of Roles
- Job Titles: “product owner”, “front-end developer”
- Behaviors: “first-time buyer”, “iPhone user”
- Persona Names: ”Trading Tim”, “Moving Mary”
When working B2B or other enterprise solutions, it’s common to use Titles for the Role. For example: “As a project manager”, “as a senior strategist” or “as a CMO”. This works well because project managers often face similar demands, as do strategists and CMOs. In public-facing solutions, titles are often less suitable.
- The Goal
“I want to learn about User Stories”
User Goals are most important element of user stories. They are the reason you are designing a solution in the first place. Goals are also the most difficult aspect to get right: People want a lot of things, many of which they aren’t even aware of. Some goals are immediate, while others are long-term. Some goals are broad, while others are specific.
When writing user stories, the goals you choose should be a direct reflection of those identified in your user personas. This is one of the reasons why personas are so important. Without them, you’re forced to rely on dangerous assumptions about what your users really want.
Types of Goals
- Broad: “I want to sharpen my skills”
- Focused: “I want to learn how to write JS”
- Specific: “I want to know when to use let vs const”
Always be actionable: While it’s important to understand how your users think and see the world, user story goals should be achievable within the experience itself.
- The Gain
“So that I can build better experiences”
The Gain is also referred to as “the benefit” of the user story. It is the reason why the user is interested in reaching their goal, and it provides context about the desired end result.
The Gain is also difficult to write well, and often devolves into a reiteration of the Goal — “… I want X so that I can have X”. To avoid this trap, remember that the Gain is what users really want. And it’s important to include that because often there is a better way to attain it than the Goal — especially when designing innovative experiences.
Types of Gains
- Direct: “I can do something beneficial”
- Indirect: “I can avoid something detrimental”
Reference Empathy Maps: Empathy mapping is a Design Thinking activity used to articulate the “Pains and Gains” of real users — a valuable resource when writing user stories.
User Stories vs Job Stories
If you find yourself writing the same thing each time for the Role, it may be a sign that you should switch to “Job Stories”. Job stories are vey similar to User stories, except they assume the persona is already known, and describe a goal within the context of a specific action. Both user stories and job stories can be used within a single project to capture all the goals of the experience.
User Story Examples
This section provides a range of user story examples to demonstrate what “as a role, I want goal, so that gain” can be used to express.
Because user stories are intimately connected to the personas they voice, we’ve anchored each user story example to a skeleton persona (name, image, and defining goal/behavior). In the real world, user personas outline a range of relevant goals, patterns and behaviors. This makes brainstorming user stories much more effective, and is the primary reason for developing robust user personas.
User Story Examples for Banking
Designing a banking experience is a textbook example of a wicked problem. These are problems where even the problem itself is unclear, and they typically involve multiple competing interests, sophisticated technologies or serious consequences. When building banking experiences, often all three factors are present which amplifies the ambiguity.
The following two sets of user stories exemplify the challenges banking design teams face. They are based on two ends of the risk-tolerance spectrum, and demonstrate how user stories can
User Story Examples for Automotive
Buying or leasing a vehicle is a significant decision that can take months/years and involves countless interactions along the way. To deliver innovative experiences in this space, user stories need to describe not only what potential buyers want, but where they’re headed as well.
User Story Examples for Insurance
Insurance is another difficult industry to design experiences for thanks to the complex regulatory constraints and the significant amount of user input required. Plus, unlike buying a car, no one wants to use their insurance unless they are forced. That also means there are significant opportunities for differentiating the user experience — something newer entrants like Rocket and Lemonade have taken to heart.
User Story Mapping
What is a User Story Map?
User Story Maps provide a simple way to organize all the different user stories that a specific design must consider. In this sense, they are similar to user journey maps, marketing funnels, and other tools designed to help teams model a series of engagements over time. The difference is that user story maps are built up entirely of user stories nested into groups of increasing scope.
Since user story maps were pioneered by Jeff Patton in the early 2000s, they have become a ubiquitous tool in Agile software development, and a critical element for design thinking teams to consider — especially when developing digital experiences.
Figuring out how to nest your user stories into a 3-level hierarchy comprising is the goal of User Story Mapping.
Themes > Epics > Stories
How to create a User Story Map
There are two ways to create a User Story Map:
- Bottoms-Up: User Stories are generated first
- Top-Down: Epics and Themes are identified first
In this example, we walk through a Bottoms-Up approach — ideal for net-new solutions or those with multiple personas and competing interests. Top-Down is typically best for redesign projects, or instances where you can determine Epics based on well-defined expectations or technical constraints.
- Step 1
Compile all the user stories for the experience
The first step of user story mapping is compiling all of the user stories you generated during your design thinking workshop. This includes user stories for all your different personas. Even if your users will be focused to a specific interface within the experience, you want them all on the same playing field. This step is what differentiates user story mapping from user journey mapping, which examines a single user’s experience.
While user stories are small on their own, they have strength in numbers. - Step 2
Sort user stories by related goals (called “Epics”)
Sorting user stories into Epics (or any other name you prefer) is the most important step in user story mapping. Epics are the modular units — or “interfaces” — of your experience. In software parlance, they are thought of as “features”; in web design they are often your “pages”. Regardless of the terms, the goal of this step is to sort stories into functional groups.
Epics group several related stories. They can be written in story-format, or take a simple verb-noun construction like “compare prices”. - Step 3
Group epics into high-level Themes
Also referred to as “activities”, Themes are the highest-order structure in your user story map, and the “backbone” of your entire experience. They are often just a single verb or noun (action or object), such as “Learn”, “Purchase” or “Photos”. Note that unlike Epics which outline discrete features or pages, Themes provide more of a conceptual framework and are too broad to develop directly.
Themes (ex. “Purchasing”) provide the highest level of organization in a user story map. - Step 4
Rank user stories within Epics
Once you’ve identified your epics and sorted stories into an initial map, it’s time to prioritize. The ability to perform parallel-path prioritization is what makes user story mapping more efficient than traditional “flat backlogs”. By mapping out the multiple connected goals for every user across every interface, design thinking teams can easily rank stories according to their strategic needs and capabilities. In agile parlance, stories are prioritized into “sprints” which identify the functionality that will be developed in the MVP vs subsequent releases.
The final two-dimensional map makes it easy to sort stories by descending priority. - Step 5
Split stories into multiple tasks (optional)
As we are considering user story mapping in the context of design thinking, this last step can be considered optional. However, it’s important to know that the user stories generated in design thinking workshops are often split into “Tasks” that developers or UX designers can action on. These tasks end up as Jira tickets or similar, forming the universal “product backlog”.
Quick Tips for Writing User Stories
Start with a broad sweep
While user stories about long-term goals or psychosocial needs likely won’t end up in your final user story map, they can be a great jumping-off point for innovative ideas. When writing user stories, begin brainstorming with a broad sweep before shifting to more granular goals in subsequent rounds.
Fill in any gaps
Writing “top down” means picking a persona AND an epic/theme to brainstorm user stories with. For example, you may be brainstorming user stories for “Data Dan” within the “Graphing Functions” Epic.
Add real insights
What user behaviors did you observe? What words do they use? What are their favorite devices? User stories are the voice of your user personas, and should integrate as many UX research insights as possible. Try brainstorming a few ways to describe their “role” to get started.
Beware of “AND”
User stories function as the “atoms” of a user-centered design, and so must be kept to a singular persona and goal. If you see the word “AND” popping up in your stories, there’s a good chance they’re trying to say too much in one sentence.
Focus on goals
The most inspiring user stories describe a user goal without prescribing how to attain it. For example, you wouldn’t assume someone “wants to buy a textbook” just because you know they’re interested in a subject. By only writing user stories about the goals you are sure about, you can avoid spending resources on undesirable ideas.
Use adjectives sparingly
User stories are the universal language connecting everyone from business development to back-end developers. Because of this, clarity is KING, and adjectives leave a lot more room for interpretation than their pragmatic counterparts of nouns and verbs.
For example, writing “As a … I want a modern experience, so that …” may be true, but it isn’t obvious what modern really means. So when writing user stories, it’s best to view all adjectives with a healthy dose of skepticism.
Summary
So what is a User Story?
Since they were first described in the early 2000s, user stories have become an indispensable tools connecting strategy, design and technology teams. The benefit of user stories over artifacts like Use Cases is their simplicity — just remember: As a <role>, I want <goal>, so that <gain>. From there, you can group user stories into epics and themes, creating a universal roadmap and user-centered backlog in one place.
- Patton J, Economy P. User Story Mapping: Discover the Whole Story, Build the Right Product. “O’Reilly Media, Inc.”; 2014.