A practical guide to navigating the differences between the three and the best time to use each
Sometimes it can be hard to breach the gap between the research and design stages of product design. Try out these UX tools to ground your designs in research and to help your team make design decisions that satisfy both user goals and business needs.
Use Cases
Use cases are used to describe a user's low-level action or task using your product and how the system responds to that action. Each use case outlines the steps that users take to complete a task, including basic flows where the system functions as it should and nothing goes wrong, and alternative flows that demonstrate other paths a user can take to complete the task.
With origins in software engineering, use cases typically provide a catalog of user tasks for different types of users, with descriptions of the system's functional requirements. However, according to the authors of About Face, traditional use cases are often not reviewed based on likeliness or importance. Instead, they are often treated equally, making it difficult to prioritize tasks based on user research and personas. They also don't describe how tasks should behave, look, or feel to the user.
When to Use
Uses cases are helpful in identifying any edge cases, thinking through what might go wrong during a user interaction, and how to prevent this. They also provide a list of goals that can be used to determine the cost and timeline of a project, which is useful during any negotiations about design tradeoffs based on viability, feasibility, and desirability. Because use cases can determine guidelines for when a product is functionally complete, they are often used to validate designs in later stages of the design process.
User Stories
User stories are often used in agile design processes to provide a high-level understanding of a product's features and the value that users' gain from them. They do not describe the tasks associated with user interactions. Written from a user's point of view, user stories are short, simple sentences that describe what a particular user needs or wants to do. Here's the typical structure of a user story, which should be written based on a specific persona:
When to Use
User stories are great for describing the what of a product feature, but not how that feature will be implemented or presented to the user. They also do not provide insight into the user's end goal or the user's entire, high-level flow. However, due to their simple nature, user stories can be quickly created with little effort, which is incredibly useful when design or technical requirements change frequently (like in agile environments) or when you need to be able to make quick adjustments in a highly competitive market. If you use them to capture ideas from a team brainstorming session, George Krasadakis suggests keeping all of the user stories in a backlog and prioritizing them based on viability, feasibility, and desirability. If you keep them in the backlog, rather than removing them altogether, you'll be able to return to the de-prioritized user stories in the event that they become relevant and useful to a changing product scope.
User stories are also helpful in starting discussions about the scope of a product. Their non-technical, straightforward nature make it easy for non-technical stakeholders to join the conversation and gain a high-level view of a product's features.
Context Scenarios
Context scenarios describe a product's behaviors and features from the viewpoint of a specific user or persona. At a high level, they explore how a product can satisfy the needs of users in a specific context and describe a future, ideal version of how a specific persona would use the product. Context scenarios consider a user's perspective and environment, and showcase the main touch points that they would have with the product and sometimes other personas.
Context scenarios are written from the user's perspective, taking into account their end goals rather than tasks, and the motivations behind those goals. In fact, the scenario should try to eliminate as many tasks as possible. Keeping it broad, context scenarios also explore how a product's functions might look and feel to the user at a high level, rather than in detail. Because they are used to describe an ideal version of the product, it's okay to take a "blue sky" approach to describing features in the scenario. Just be sure that the out-of-the-box features are technically feasible.
When to Use
If you have more than one primary persona, or even if a persona would use the product in a few different contexts, it may be necessary to use more than one context scenario to capture the various ways that a product might be used to solve for a user's needs. In About Face, the authors suggest that the right time to use context scenarios is prior to sketching, because having a scenario that describes an optimal experience based on your user's goals can help kickstart creative brainstorming sessions.
Context scenarios also help to determine design requirements, as they pull out the data, functional, and contextual requirements for the design. After considering any additional priorities or limitations, including those related to technical, business, branding, or customer requirements, you may need to iterate on your context scenarios to make sure you have a firm idea of the project scope and a vision that is viable, feasible, and desirable.
Final Thoughts Having a solid foundation of research and user modeling (ex: personas) ensures that use cases, user stories, and context scenarios are based on the goals, motivations, and needs of real users. Utilize these three design tools to tell a story about your users to stakeholders and your team to make your research more engaging and relatable. They will also help you align your design with the overall product vision, goals, and requirements.
Comments