User Stories User Experience (UX) topic overview/definition

What are User Stories?

User stories are representations of small instances in peoples’ lives. They are a type of scenario used in design processes to enable a designer to empathize with a user and, from there, generate ideas that fit into the user’s life. Rich in trivial details, such as activities, thoughts, and emotions, user stories can be presented through different media.

In order to create user stories, a rich fund of information is needed on the users’ lives. A designer or design team can only obtain this by conducting qualitative research. Observations, contextual interviews, and other ethnographic methods are typically used in the research process. Users can also be asked to create their own personal stories actively—doing so after being provided with a probes kit. Such kits hold a variety of materials and assignments that the users can complete over the course of a week so as to capture their experiences from their own perspectives—and in context—for the designer. When all information from multiple users is gathered, the designer selects the most relevant insights for the design problem, and then merges these into cohesive user stories. They can be represented as written stories, visualized storyboards, or short movies.

In a design process, stories are what designers use to help them empathize with the target groups. These also serve as inspiration when designers are creating solutions that fit into their users’ daily activities. They can be used alongside personas or integrated with them. Understanding just how much closer user stories bring the users’ world to the drawing board is key for any designer whose aim is to fine-tune a product that will consistently latch with the users’ needs on a daily basis.

Literature on User Stories

Here’s the entire UX literature on User Stories by the Interaction Design Foundation, collated in one place:

Featured article

User Stories - Capturing the User’s Perspective Quickly and Simply

User Stories - Capturing the User’s Perspective Quickly and Simply

User stories are a simple tool for articulating the user’s perspective. They are not long, wordy stories to be told around a camp fire but rather short (often only a single sentence) descriptions of what a user will do with a part of a system. They are written in plain English or in the language of the business in which they will be used and require no special literary gifts or linguistic talents to compose.

They are particularly important in Agile environments where they facilitate the functionality of a system but can be used in any environment to ensure that design and development are focused on user needs. They deliver the “who”, “what” and “why” of user requirements in a format that can be easily understood by anyone who needs to use them.

The Background to User Stories

The user story was first described in Extreme Programming back in 1998. It was mentioned that user stories could be used to define scope of a development project in a similar way to use cases. (Use cases are visual descriptions of actions taken by a user which are usually recorded in UML – Universal Markup Language).

Author/Copyright holder: Slashme. Copyright terms and licence: CC BY-SA 4.0

UML use cases are visual diagrams that capture requirements and actors – they are very different from user stories.

However, it is commonly agreed today that a use case and a user story serve different functions. Use cases address how a requirement will be handled whereas a user story simply captures the requirement.

Author/Copyright holder: Paul Downey. Copyright terms and licence: CC BY 2.0

Always capture user stories in a way that feels useful and doesn’t interfere too much with the user/client conversation – you can always revise them later.

Writing User Stories

In many cases user stories are not created by the design or development team – they’re provided by a customer or a business user to try and explain what they’d like the finished product to look like. However, that doesn’t mean that in the absence of customer/user provided stories that the team cannot create their own. In larger organizations, this responsibility may be covered by product managers in other organizations it may fall within the remit of the UX team.

While, in the main, a user story is going to capture a requirement of the product functionally they may also be used to describe non-functional capacities of products too (for example privacy or security requirements).

As Steve Rogers, the well-known designer said; “Designing a product is designing a relationship.”

To form that relationship, user stories are always best when created with the input of users or the end client and can easily be facilitated by a designer or developer working in conjunction with a representative of the user/client base.

The idea is to use a simple question and answer format to develop the story. Then the designer or developer records each story on a single card. This story may then be revised for clarity after the requirements capture exercise is complete.

The generally accepted format for user stories is:

“As a , I want , for this

This format was proposed in 2001 by a team working for Connextra in a story related to AgileCoach at Typepad.

There are many variants on this theme but all of them capture a similar set of information.

Author/Copyright holder: Copyright terms and licence: CC BY-SA 2.0

As you can see here – user stories, captured one per card, can then be easily presented back to the development and design teams as necessary.

User Stories and Agile Development

User stories are used in agile to define all functionality of the final product. They are not set in stone and it is completely accepted that requirements can (and often will) change throughout the lifecycle of a project.

The scrum master (the agile team leader) then prioritizes the stories for development in each sprint. Developers are often given carte blanche to discuss user stories with the end user or customer in order to fully understand what is required of them.

Agile also requires that each story have a corresponding test case or test cases attached to it for UAT (User Acceptance Testing). This way the development process ensures that the story is implemented in a manner that is satisfactory to the user. It also provides a basis for negotiation if a user story is implemented correctly but does not satisfy the end user.

Benefits of Using User Stories in Design and Development

There are several benefits of using user stories in design and development cycles:

  • They are simple and quick to understand.
  • They allow programmers to quickly (using agile) implement customer/user value
  • They don’t need very much maintenance
  • They can be discounted except when they are being used in development
  • They allow a project to be chunked into smaller milestones
  • They make it easier to estimate costs on a project for development
  • They facilitate cooperative working with clients and users

The Drawbacks of Using User Stories in Design and Development

There are possible drawbacks of using user stories and in particular of becoming overly-reliant on them at the expense of other tools:

  • They are difficult to work into large scale projects (where thousands of stories might be required)
  • They may be too vague to be useful and require a lot of back and forth between developers and clients
  • They fail to capture performance measurements and sometimes non-functional aspects of the system – e.g. they are too simple

Author/Copyright holder: Wiggy! Copyright terms and licence: CC BY-SA 3.0

A user story’s simplicity can be its greatest strength and its greatest weakness. Don’t forget you have to capture enough information to deliver on the intangible requirements as well as the tangible ones.

The Take Away

User stories can be very useful to articulate the user’s or client’s requirements for a system in simple one line (or very short) stories for each requirement. They fit neatly into the Agile development method and ensure clear understanding of what’s needed from each sprint. However, it’s important to remember that user stories also have limitations and their use should be carefully considered to ensure that all requirements and performance measures are understood before design turns into development.


The Connextra user story approach is found here -

Some simple examples of user stories can be found here -

Agile Modelling offers its take on user stories here -

Some tips for writing better user stories can be found here -

Hero Image: Author/Copyright holder: Copyright terms and licence: CC BY-SA 2.0

Show full article Show collapsed article

Learn more about User Stories

Take a deep dive into User Stories with our course User Research — Methods and Best Practices.

User experience design requires you to understand your users. If you don't know what your users want, you can only deliver what they want by accident. User research is how we come to understand what our users want—it's the largest part of user experience design. This course will give you insights into all the major UX research techniques and how to put them into practice on your projects.

User research is often the first step of a UX design process, because you cannot begin designing a product or service without first understanding what the users want. By gaining skills, and learning about the best practices in user research, you will be able to get first-hand knowledge of your users in order to design the optimal product—one that sells better than your competitors’.

Through this course, you will be introduced to the various aspects of user research, getting exposed to qualitative and quantitative user research methods. On top of that, you will also learn how to analyze the results of your research and confidently present your findings to your clients and stakeholders. User researchers play an instrumental and valuable role in any organization and, as such, receive a healthy remuneration, from an average of $81,000 to as high as more than $120,0001.

All literature


Ch 30: Personas

The persona method has developed from being a method for IT system development to being used in many other contexts, including development of products, marketing, planning of communication, and service design. Despite the fact that the method has existed since the late 1990s, there is still no clear definition of what the method encompasses. Com...

Book chapter
Contextual Design

Ch 8: Contextual Design

Contextual Design is a structured, well-defined user-centered design process that provides methods to collect data about users in the field, interpret and consolidate that data in a structured way, use the data to create and prototype product and service concepts, and iteratively test and refine those concepts with users. This is ...

Book chapter
Design for All

Ch 42: Design for All

42.1 What is Design for All?Contemporary interactive technologies and environments are used by a multitude of users with diverse characteristics, needs and requirements, including able-bodied and disabled people, people of all ages, people with different skills and levels of expertise, people from all over the world with different languages, cul...

Book chapter