A user story is a short narrative that describes what a user is trying to achieve and why it matters to them. In UX design, we use these stories to understand what users need, then design around that.
When you hear “user stories,” you might think of the product management side — Agile planning and backlog management. This article explores the design perspective instead.
Editor’s note: This post was extensively updated on August 3, 2026, by LogRocket author Chinwe Uzegbu, to explore user stories through a UX design lens. The article now focuses on how designers use user stories to translate research into design decisions, clarifies how UX user stories differ from Agile user stories, and includes new UX-focused examples and workflows.
In UX design, user stories help designers see a product through the user’s eyes. They’re typically written from the user’s perspective using the format:
“As a [type of user], I want to [accomplish a goal], so that [reason or benefit].”
The “so that” clause carries the most weight for designers because it pinpoints the underlying user need, providing the context to interpret the “I want.”
UX designers place the greatest emphasis on the “so that” part of a user story. Product managers, on the other hand, typically care more about the “I want” portion. While both care about the user and their motivation, they approach the template through different lenses.
Take this story, for example:
“As a frequent shopper, I want to quickly reorder items I buy regularly, so that I don’t have to rebuild my cart every time I shop.”
The PM starts thinking about how a quick reordering capability can be implemented. The designer, however, starts with the need: what’s the best way to spare the user from rebuilding their cart on every visit?
Here’s how they compare at a glance:
| UX user story | PM/Agile user story | |
| Primary purpose | Build empathy, inform design decisions | Scope and estimate development work |
| Key clause | “So that” (the underlying need) | “I want” (the deliverable) |
| Typical output | User flow, journey map, wireframe annotation | Backlog item, sprint task |
| Evaluated by | Does it reflect real user behavior/research? | Does it meet INVEST criteria? |
| Owned by | Designers/researchers | Product managers/scrum team |
| Lifespan | Lives in design artifacts, may never reach a backlog | Closed out within a sprint |
To learn more about how PMs evaluate story quality once it reaches the backlog, see our guide to the INVEST principle.
Every user story has three components, matching the three clauses of the template:
Putting them together, we have:
“As a one-time shopper, I want to check out without creating an account, so that I can complete my purchase quickly and move on.”
In Agile teams, stories also carry acceptance criteria, which define what a completed feature should do. To learn more, check out our article on user stories from a PM’s perspective.
Interviews and surveys reveal what users say they need, usability tests uncover where they struggle, and analytics and session replay data show what they actually do.
Behavioral data is especially useful for surfacing friction users don’t always articulate. If session recordings show repeated cart abandonment at the account-creation step, that’s raw material an interview might never give you.
Once you’ve identified a recurring need, translate it into a user story, written from the user’s perspective and, where possible, in their own words.
For example, if a research participant says, “I just want to pay for my items and leave, not make a lifetime commitment,” the “so that” clause should reflect that sentiment.
While drafting, avoid specifying solutions. “I want to check out without creating an account” names a goal; “I want a guest checkout button” names a solution. Keeping the story at the goal level leaves room for creativity.
After drafting, check the story against your findings. Ask yourself: *Do the findings support this need, or have assumptions crept in? *Revise the story until it reflects the user’s reality.
A validated story should feed your design artifacts directly. It can add detail to a persona, inform a user flow, highlight a friction point in a journey map, or even become a wireframe annotation explaining a design decision. This is what it means for a story to live in design artifacts rather than a backlog.
On the PM side, stories are typically developed collaboratively — our user story workshop guide shows how.
During a usability test, I discovered that users were unable to recover from a posting error. The “Failed to post” error message briefly instructed them to “create a wallet to proceed,” but it didn’t explain how to do that. It also appeared only briefly — short enough for some users to miss it entirely.
From this finding:
Good example: As a new user, I want to understand why my post couldn’t be published and how to resolve the issue, so that I can recover from the error and complete my task successfully.
Why it’s good: It captures the underlying need without offering a solution, and is also grounded in an observed issue. A designer reading this could explore clearer copy, error prevention mechanisms, or an entirely different solution.
Bad example: As a new user, I want a “Create a wallet” button in the error message, so that I can successfully publish my post.
Why it’s bad: It jumps to a specific UI solution, closing off alternative solutions. The research showed users couldn’t recover from the error — it didn’t show that a button was the answer.
Another common mistake is writing stories that aren’t backed by research.
Bad example: “As a new user, I want to post without needing a wallet at all, so that I can complete the process faster.”
Why it’s bad: It commits to a product direction that the research doesn’t support. The problem wasn’t that users objected to creating a wallet — it was that they didn’t know how to create one or recover from the error.
The job of a UX user story isn’t done until it’s translated into the design. No matter how polished the story, if it never touches a persona, a journey map, or a wireframe, it hasn’t done its job. A rough story that reshapes the design is worth more than a perfect one that sits in a document.
So: identify real user needs from research, keep the story at the goal level, and let it shape the design.
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Brand archetypes can define your personality, but they don’t tell you what to say. The imagined speaker technique turns an abstract archetype into a real voice you can write through.
Finding the right UX research participants is hard, and AI has made verifying them even harder. Here’s how to recruit real users, screen for quality, and use synthetic participants without compromising your research.
Not every enterprise product needs to be intuitive. Complex workflows often require complexity, and trying to eliminate it can make products less powerful for experienced users. Explore why enterprise UX should balance intuitiveness with learnability, efficiency, and long-term mastery.
Open-source Figma alternatives are becoming viable for teams seeking self-hosting, open file formats, offline access, flexible AI integrations, and greater control over their design workflows. Compare Penpot, OpenPencil, Quant UX, and Open Design to see where open-source tools stand against Figma.
Learn more →
