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—and they're brought to life using User Stories.
There are many blogs and websites about UX and Agile. Sadly, many of them are rants about how Agile is so unfriendly to UX and how the two cannot work together. Yes, it is difficult to work on software projects.
Yes, it is challenging to work in collaboration with other disciplines, and integrating UX with Agile has a way of bringing these into particular focus. But today, we're not going to focus on the negatives. We're going to discover a simple and quick method called “user stories” that will help you address many of the challenges of collaborating in an Agile team. 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.
User stories are – obviously – user-centered
Author/Copyright holder: CannedTuna. Copyright terms and licence: CC BY-NC-ND 2.0.
In reality, 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 solely about “me”. A little imagination can work wonders in being mindful that users are not like us. Here's an example of how this could work:
If you had to design a website that catered to musicians who could select styles and effects to help them compose songs, you’d need to think about many types of musicians. Assuming your client has asked for a menu with various effects, what would happen? Perhaps, a song pops into your head—something that just played on the radio during your drive. Quick, lose that thought, because you’re thinking only of “me”. 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 who is drafting an opera and wants to explore fresh ideas for the score.
“Me” could also be a songwriter from any genre. That could easy-listening, electronic, or 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 you've shifted your focus from "me" to thinking “wide” to suit your users, and you’re in a position to create a user story.
The format of a user story forces you to think about others and keep them and their needs in focus, to work a little bit on your empathy and place yourself in the users’ shoes. From this tiny exercise in empathy, management and team members can understand the need for going out there and researching target users!
Ideally, as a UX specialist in an Agile team, you should take the lead on the user stories’ definition. You can bring your personas and user scenarios to the user stories session and build the right framework for all stakeholders.
If the project did not include 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 and more.
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 in the project has them in mind.
User stories are simple and accessible
If you’re from a traditional background in UX, 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 are involved in any form of 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 here. 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 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 origins may be 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 in 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 level of detail), it becomes very clear when the project risks suffering from feature creep or other potential problems
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's benefit!
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, what 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. When the two come together, the effect is powerful.
Where to Learn More
Learn more about how you can work and succeed in an agile team in the course: Agile Methods for UX Design
Course: Interaction Design for Usability
Brinton, T. (2015). “User Stories: A Foundation for UI Design”. UX Booth.
Pichler, R. (2014). “From Personas to User Stories”. Pichler Consulting.
Holland, J. (2009). “User Stories: a strategic design tool”. Johnny Holland.
Loranger, H. (2014). “Doing UX in an Agile World: Case Study Findings”. NN/g – Nielsen Norman Group.
Grosjean, J.C. (2009). “Use cases – User Stories: so precious but not the same!”. QualityStreet.
Reference
Hero Image: Author/Copyright holder: Katie Lips. Copyright terms and licence: CC BY 2.0
