User Stories: As a [UX Designer] I want to [embrace Agile] so that [I can make my projects user-centered]

User Stories: As a [UX Designer] I want to [embrace Agile] so that [I can make my projects user-centered]

by Muriel Garreta Domingo | | 11 min read

Let’s examine a tool so simple yet so powerful that once you’ve learned about it, you will apply it in all your projects. It is a great design method that enhances collaboration among all stakeholders.

Users’ Needs are a core part of Agile: the User Stories

There are so many articles about UX and Agile. Lots of them are rants about how Agile is so UX unfriendly, how these two approaches cannot work together, etc. Yes, it is difficult to work on software projects. Yes, it is challenging to work in collaboration with other disciplines. And, while we’re at it, we might say “yes” to so many cons, that we won’t address them all in a single article.

Our focus today is on this simple and quick design method called “user stories” that will help you address many of these challenges. Why?

  • A user story is short, specific and goal-oriented. It is a one-sentence statement that tends to have the following structure: “As a , I want so that ”.
  • User stories are collaborative design tools. All project stakeholders are expected to participate in the definition and sorting of user stories.
  • User stories focus the project on the perspective of those who will use it.

Doesn’t it sound like a user-centered philosophy and development process at its core? Yet, it is a tool that comes from Agile development. So, why not embrace them both?

User stories are – obviously – user-centered

Author/Copyright holder: CannedTuna. Copyright terms and licence: CC BY-NC-ND 2.0.

For sure, there are teams who do not do any user research and make up user stories from what they think. Although this isn’t the best option, it is much, much better than thinking about “me”. A little imagination can work wonders in keeping mindful of the point that users are not like us. Just to emphasize the relevance for this way of thinking, among all stakeholders, you can explain a little scenario like the one that follows.

“For instance, if you had to design a website that catered for musicians who could select styles and effects to help them compose songs, you’d need to think about many types of musicians. The client has asked for a menu with various effects. A song pops into your head—from the CD on your car stereo. Quick, lose that thought, because you’re thinking “me” there. Instead, think of this:

  • “Me” could be any musician who specializes in one or more instruments. If you thought “me” was a heavy-rock guitarist, go back and consider keyboardists, singers, bassists, and drummers…or, perhaps a classical composer is drafting an opera and wants to check out some ideas for the score.
  • “Me” is also a songwriter from any genre. That could easy-listening, electronic, or, yes, fine, heavy rock. Or, it could be a classicist who’s been commissioned to write the soundtrack for a movie you won’t see for a year.”

Great! Now we’ve managed to get the team to think “wide” to suit our users, we’re in a position to make a user story. The format of a user story forces us to think about others and keep them and their needs in focus, to work a little bit on our empathy and place ourselves in the users’ shoes. Maybe, sometimes, we do not do this based on real data, but it is a start. Maybe from this tiny empathy exercise, management and team members might understand the need for going out and finding out about the target users!

Ideally, as a user researcher, you should take the lead on the user stories’ definition. You can bring your personas (fictitious users we create) and user scenarios to the user stories session and build the right frame for all stakeholders. If there has not been a user research phase, just make sure to gather as much existing project information as possible. This can come from logs or analytics, from customer support, from desktop research, competitive analysis, etc. In our interactive music website scenario, we’re lucky in that our client told us that he deals mostly with keyboardists who compose instrumentals for the incidental music in TV programs.

As a user experience designer, you are the “voice” of the user during project development. Try to surround yourself with as much of their reality as possible and translate this “user voice” into the user stories so that everyone has it in mind.

User stories are simple and accessible

If you’re from the “old school”, you might still remember use cases. Maybe user stories remind you of them. Well, although there are some similarities, the differences make user stories much better.

Use cases have a specific grammar and structure. Therefore, not everyone participates in defining them. Only the team or person in charge of defining the requirements or functional specs would write them. Use cases are a bridge between the client and, sometimes, the user and the development team. Thus, facilitating the “tire swing” model, we see just what can happen…

Author/Copyright holder: Unknown. Copyright terms and licence: Unknown.

Something has gone horribly wrong in translation in that model! On the other hand, user stories, with their simplicity and focus, are a perfect way to avoid this type of situation. Anyone involved in the team can have a go at them. He/she just needs to understand the relevance of the specific grammar:

  • As a . The role refers to the one who makes the action and who benefits.
  • I want . It is the action executed.
  • So That . It is the added value that the user gets from the action.

With this brief statement, user stories make for a very short learning curve! If you come from a participatory design approach, you can also involve users in the write-up of user stories.

User stories are collaborative

As we said before, your aim as a user experience designer is to promote a concrete, realistic and shared vision of the end user. User stories are your best ally. Thanks to their accessibility and flexibility, you can use them to build a common language and a common mental model of what the project is about. Thus, you can have all stakeholders – client, management, team members – talking the same language and focusing on the user and what the project is trying to achieve.

User stories promote a shift in the way a project is discussed. We do not focus anymore on solutions and features. We focus on goals that “real” users will be able to work towards for a specific purpose. We do not have a list of abstract functionalities whose origin is dubious. We focus the end goals on concrete and tangible things that the project will let the user do.

User stories are about the present and the future

User stories are typically written on Post-its. At first, the number of Post-its might be overwhelming, but it is much more manageable than never-ending requirements documents!

A user story has just the right level of detail. At a more abstract level, we have epics. In Agile, “epics” are used for a high-level overview of the needed features. Therefore, they gather a group of user stories. If you’re building an affinity diagram, epics will be the name given to a set of common user stories. Epics enable everyone on board the project to see the design from many users’ perspectives, exhaustively enough so that any kinks can show up, should a user want to “try” something that hadn’t been planned for or planned through well enough.

User stories have to be specific enough so that the project team can pick them and work on them during a sprint. Before that, the team should drill down to the specifics and solve usability problems at the outset. As a user interface designer, you should be part of the project team and work with developers to make the user story real and usable.

The plain language of user stories helps everyone understand what is being built during each sprint, and all stakeholders can check to see how their concerns and needs are being addressed. Thus, user stories are perfect to set the stage and define the project scope. They are also ideal to define the next steps. Because they’re at the perfect level of granularity (i.e., the perfect detail level), it is very clear when the project is suffering from feature creep, for example.

The Take Away

User stories originated as part of the Agile and SCRUM development methodologies. As user experience designers, we need to embrace them and use this simple method for our own “benefits”; that is, for the user!

User stories give us designers everything we need to create a realistic, concrete and shared view of the user:

  • User stories are based on user goals; thus, they keep products user focused.
  • User stories are accessible and manageable; thus, they facilitate collaboration among stakeholders and team members.
  • User stories help create a “project mental model” from the beginning and onwards.

With a very simple and concrete structure, user stories help the project stay focused on many accounts: user-centered, goal-focused and what it is implementable at each stage and what should be left for afterwards.

Agile is a great aid in user-centered design, not least because it offers us a faster track by which to research and plan, particularly in that we can structure and fine-tune epics to help find every possible dimension of a project. User stories give us a firm grasp of the most important aspect in UX, the users and their wants.

Where to Learn More


Hero Image: Author/Copyright holder: Katie Lips. Copyright terms and licence: CC BY 2.0

Get Weekly UX Insights

Join 242,578 designers who get useful UX tips from our newsletter.
A valid email address is required.