1. Research + Insights
  2. Design Thinking
  3. User Stories, Maps and Examples [2024 Guide]
Konrad-Icon-WhiteKonrad Design Thinking Guide 2024

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

User Stories are often written on sticky notes and outline three important pieces of information: Who the user is, What they want, and Why they want it.
Complete user stories combine three important pieces of information: WHO the user is (role), WHAT they want (goal), and WHY they want it (gain).

What makes a good User Story?

Not all user stories are created equal. Common elements of good user stories include:

They pertain to a single persona and goal

The role, goal and gain are easy to identify

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.
Jeff Patton, User Story Mapping

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

  1. Review ONE user persona
  2. Set a timer for 10-15 minutes
  3. 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.

User stories are shown as the midpoint in a taxonomy. User Epics and Themes help to cluster related User Stories into manageable groups. User Tasks help to further break down stories into actionable units for development.
User Stories are the center of the experience taxonomy: The are grouped into Epics and Themes, and split into Tasks as needed.

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 storiesUse cases
Describe a raw user needDescribe complete user interaction
Fits within a single sentenceRequires a diagram to visualize
Quick to create/compareInvolved to create/compare
User stories are just one way to communicate user requirements.

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”
    Related Guide
    How to Create a User Persona
    Go to Guide

    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.

The similarities and differences between user stories and job stories are demonstrated with examples from education.
By identifying the “Role”, user stories make it easy to compare the goals of multiple users. Job stories swap the role out for more context, helping teams get more granular.

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

A selection of fictitious user story examples for a potential financial experience user.
One of the biggest challenges in designing financial experiences is the disparity in domain knowledge between average and expert users. That’s why having research-based personas is so important.
A selection of fictitious user story examples for a potential financial experience user.
When writing User Stories, including multiple approaches to “The Role” can create a more complete picture of your persona. For example, not only is Tim an active trader, he’s also a developer and trades options on margin. Knowing those details provides a lot of context.

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.

A selection of fictitious user story examples for a potential automotive experience user.
Two people can decide to buy the same car for completely different reasons. That’s why it’s important to understand the defining behaviors of your potential buyers, and not just where they are in the marketing funnel.
A selection of fictitious user story examples for a potential automotive experience user.
While Will’s user stories are far too broad to specify an experience’s requirements, they are big enough to help inspire “blue ocean” ideas about what that experience could be.

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.

A selection of fictitious user story examples for a potential first-time home buyer
Insurance is typically a “set it and forget it” expense, so you only get one chance to provide a 5-star experience. That’s why having good personas for first-time buyers like Melanie is critical.
A selection of fictitious user story examples for an insurance user looking to downsize
The experience between buying your first home and downsizing from an empty present very different opportunities.

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.

    User stories are sorted into Epics that group related goals and behaviors, making them easier to work with.
    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 help group Epics into large features or functions, such as "Purchase Product".
    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.

    With the user story map skeleton in place, user stories can be ranked from the highest priority at the top.
    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”.

    Related Guide
    What is UX Design? Principles and Process
    Go to Guide

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

Related Guide
What is UX Research?
Go to Guide

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.


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.

  1. Patton J, Economy P. User Story Mapping: Discover the Whole Story, Build the Right Product. “O’Reilly Media, Inc.”; 2014.