# User Stories It is easy to confuse User Stories with User Scenarios or Use Cases [but the three are different](https://medium.com/@smartgamma/user-scenarios-user-stories-use-cases-what-s-the-difference-75bf75d4bb60). User stories are concise, user-focused descriptions of desired functionality or features within a software development or product management context. They capture the needs, goals, and motivations of the end users in a simple and understandable format. User stories typically follow the template: "As a \[type of user], I want \[a particular action or capability] so that \[a specific benefit or outcome]." They also contain details about what should happen, driven by context and other situations: "If \[context] and \[additional context] when \[event] then \[outcome]." As a jogger I want to track the distance I jog every week so that I can have a good understanding of how much I have exercised. If I stop jogging and I stop for more than fifteen minutes, then the record of my jog should be saved as a new jog. These stories help prioritise and communicate user requirements in an accessible way, guiding the development team's understanding of what needs to be built. User stories provide a user-centric perspective, allowing teams to focus on delivering value to users and aligning product development efforts with user needs. They serve as a foundation for agile development, aiding in iterative development, and facilitating collaboration between stakeholders, designers, and developers. #### User Stories / Job Stories / Technical Stories Deciding which "story" to use depends entirely on whose problem you are trying to solve and how much context you already have about the user's motivation. Think of these not as competing formats, but as different lenses for looking at a product requirement. **User Stories** *As a \[type of user], I want \[action], so that \[value].* * When to use\ Use these when the persona is the most important variable. They are ideal for features where different types of users have distinct goals. * The Strength\ They keep the focus on "who" is doing the action. * The Pitfall\ They can become repetitive if every user wants the same thing, or if the "so that" clause is just a restatement of the "I want" clause. **Job Stories (Jobs-to-be-Done)** *When \[situation], I want to \[motivation], so I can \[expected outcome].* * When to use\ Use these when the trigger or context is more important than the persona. In many apps, a "First Time Parent" and a "Grandparent" might have the exact same motivation when a baby starts crying. * The Strength\ They focus on the *causality* of an action. They help designers understand the emotional or situational "why" rather than just a functional "what." * The Pitfall\ They can feel a bit abstract for very simple, administrative tasks where context doesn't vary much. **Technical Stories** *In order to \[achieve system goal], we need to \[technical implementation].* * When to use\ Use these for work that provides no direct, visible value to the end user but is necessary for the product to function. This includes refactoring code, setting up servers, or migrating databases. * The Strength\ They allow developers to track "under the hood" work that still consumes time and resources. * The Pitfall\ If your backlog is 80% technical stories, you are likely focusing too much on the "how" and losing sight of the user's needs. #### Further Reading {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} {% embed url="" %} --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://www.designreference.xyz/ux-methods/ideation/user-stories.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.