Need user insights? Get the Playbook π
You're ready. Ready to drive some positive change in your product's user experience. Perhaps, you've run moderated interviews, user observations, or saw our top-10 advantages of running unmoderated user studies and chose that path to generate insight. You've figured out how to analyze user data / behavior. You've some great insight themes π‘ ready to go. Now, it's time to decide how to craft them for best reception.
Work smarter, not harder.
The Turbo UXR Playbook is your tactical reference π guide β free to download!
Get the Playbook
Learn More
So, how's best to relay what you heard / saw / understand about the users' needs? There's many ways to accomplish this. At Turbo UXR, we'll show you what's worked best for capturing and communicating user insights and themes from our experience. The framework we use, and recommend to fellow UX researchers, is the User Story in the format of user need statements. There's several reasons why this framework gets the job done, again and again.
Throughout this article we'll delve into the purpose of User Stories, four elements of an effective User Story, the best framework for writing User Stories, the immediate value / benefits of writing them, and the long-term opportunities unlocked through continued use. (If you happen to be revisiting this page after already creating your User Stories, see our next article on the 7 components of a compelling Insight Theme.)
You bring the user understanding, and we'll show you how to make it live on through User Stories π.
user needs statement UXR framework product development strategic UXR user-centered design story writing
User Stories are a key tool within the product design process. Their main purpose from a UX research standpoint is to highlight major opportunity areas for the business to solve. They don't have to explicitly state the answer or solution, but rather provide context as to what is needed, by whom, and why. User Stories provide a platform for solutioning. They give guardrails and direction for recommendations.
Work smarter, not harder.
The Turbo UXR Playbook is your tactical reference π guide β free to download!
Get the Playbook
Learn More
User Stories are used in the insight communication stage of a UX research project. You'll write them out during the process of synthesizing key insights into themes, as they are useful way of summarizing the insight from a user perspective. User Stories follow a standard structure ποΈ, which we'll describe further in the section below (4 main aspects).
Shown above is an example of a User Story in context of a UX research presentation document. Notice how the User Story is accompanied by several other supporting elements. An abbreviated title describes the User Story in <10 words, a highlight video gives a view into the user's behavior in action, a verbatim quote provides a written synopsis, and several recommendations give clear direction on how to solve. As you can see, User Stories don't exist in a vacuum. They are but one arrow in your insight communication quiver πΉ.
First, User Stories are to be detailed from the users' perspective. They're written in this way to keep the end-user (WHO) on center stage. This practice of user-centered design (UCD) is an important notion in product design. The basic idea of is to keep the users' interests / needs / mindset at the core of product decisions, designs, and direction. Because companies who care about the user, create vastly better user experiences (UX). And great UX has a high correlation with increasing revenue, growing market share, increasing life-time customer value, and more.
Second, User Stories exist to convey what's needed to be improved in the user experience. That's the crux of it. Tell me WHAT needs to happen. Because if there's no one telling product development teams what ought to be improved in the UX, don't expect much to change. As UX researchers, informing Product about what are the users' needs and desires is our job. This piece is crucial.
Third, User Stories outline the clear reasoning behind the user need. Articulating the reason WHY the user needs or desires something helps to justify action by stakeholders. It gets stakeholders on board with potential changes by giving them additional context. With this context, solutions can be targeted towards the root level of the problem. When well done, this statement allows for stakeholders to more easily come up with creative solutions to do so.
Fourth, User Stories are to be written in a succinct and consistent manner. This allows for easy digestion of content arranged in a manner that everyone can understand. By everyone, we mean internal stakeholders, such as designers, engineers, researchers, analysts, product managers, etc. Succinct is beneficial because no one has much time in a fast-paced company. Consistency matters because you'll be setting the process up for long-term application as well. Meaning, that all your user needs are now documented in a 'normalized' way, and can be easily sorted, prioritized, and themed, later on.
The first time we realized we needed to utilize a common framework for documenting user needs was while facilitating large workshops. We noticed that everyone had a unique way of writing their users' problems and opportunities. Many stakeholders would simply write one word on a sticky note π€¦. Others had longer, inconsistent ways of documenting the user needs.
Ultimately, we decided to implement a standard, concise, yet exhaustive way of capturing user needs. Ever since, we've been using this 'need statement' format of User Stories to increase ease of use, consistency, and understanding. This framework does a nice job of describing everything necessary in a small package.
The format forces stakeholders to write down the who, what, and why for each user insight. "As a user [X], I need / want [Y], so that / because [Z]".
The framework begins with a brief description of the user. Please don't just write 'As a user, ...' and leave it at that. It's best to provide a few more words of context. Give the reader 3β7 words about who the user is and what they're doing. For example, "As a first-time website visitor trying to enroll...", or "As an advertiser looking to understand my dashboard...". Specific details are especially useful later on when User Stories are examined side by side. Everything is there to explain, without having to guess π€.
Next, the User Story author will choose from either 'need' or 'want' in the statement, depending on the situation. Again, to-the-point details are mighty useful here. Tell the reader in 5β15 words what the user is asking of the experience with enough specifics to stand alone without you having to explain. We've reached the core of the User Story. This phrase conveys the major opportunity area to be solutioned against.
Edit: in recent years, we've started to incorporate terms 'value' and 'appreciate' as choices alongside 'need' or 'want'. The reason is the arc of insight theme storytelling relies on building positive momentum with stakeholders upfront. Often, users appreciate something in the experience already and desire more of it. Or they value a certain facets of the experience (if not the whole). These can be used to showcase that there's opportunity within what already exists. Sometimes, it can be easier to build on what's already working well.
In the final section, the author of the User Story will choose between using 'so that' or 'because'. Depending on context, you'll decide which phrase best aids the flow of the statement. Then detail the reasoning why in approximately 5β15 words. This helps to clarify why the user wants more from the experience. It also may give context to their end goal at a higher level. As mentioned before, this deeper understanding of the user perspective is useful when it comes to leveraging the User Story in brainstorming π§ or design sprints.
And there you have it! You're the proud owner of the User Story. Use it often. Promote its use by others. Drive clarity. Usually, a typical UXR project will output 4β8 User Stories as one part of the final deliverable. Here's a variety of recent User Story examples from our work:
User Stories have become the most widely adopted way of documenting opportunities for product design. As you've seen, they perform a variety of duties. Most importantly, they keep the user at the center.
By leveraging a consistent, standardized way of writing user needs, you're allowing partner stakeholders to know exactly what to expect from your UX research projects. Teams can easily pick up the User Stories and run with them, on their own. Especially, if you've gotten pulled onto other projects / directions (which happens a lot as a UX researcher). Therefore, User Stories makes sure your insights live on and get implemented against, without your immediate presence.
Furthermore, consistent documentation allows for long-term identification of opportunities beyond immediate products in focus. Part of your job as a UX researcher is to look across numerous product experiences to identify strategic gaps and unmet user needs. As a matrix partner, UX researchers get considerable exposure to other teams. So as you build an Insight Database of User Stories across all your product partnerships, you'll be creating a tremendous asset. Adjacent teams, such as marketing, sales, operations, leadership, engineering, and others will look to you as the source of truth for the user perspective.
You'll begin finding meaning across projects at a more strategic level because your User Stories are clear, standalone, and standardized.
This is exactly what a UX researcher should be doing π.
Work smarter, not harder.
The Turbo UXR Playbook is your tactical reference π guide β free to download!
Get the Playbook
Learn More