🧰 Design Methods Toolbox

# Use Cases

# Phase: 🔎 Problem seeking
Focus: Empathize

IN BRIEF

Time commitment: 5-15 minutes per story
Difficulty: Easy
Materials needed: Meeting space (physical or virtual), whiteboard and stickies (physical or virtual)
Who should participate: Users, user experience designers, product/project owners
Best for: Breaking larger needs or issues down into smaller, more discrete ones in order to sort/prioritize by user type, user goal, or other parameters

# About this tool

Use cases (and their cousins such as user stories and "hills") are valuable tools at any point of the design process for more precisely noting how broader needs or issues manifest themselves in specific examples relative to the user. However, they're particularly valuable in the early stages as a means for articulating wide or vague needs as more specific instances that can potentially be boiled down into ideas for solutions.

Use cases can vary widely in specificity or detail depending on the needs of an individual exercise, but a good use case of any scope will include an explanation of who the user is, what they want to do, and the step or steps they take in order to achieve their goal. Use cases do not go into the specifics of how those steps are implemented, or the details of the interface they use to carry out those steps. For example, a simple use case for grocery shopping might be "As a person with a full-time job, Josh goes to the grocery store every Monday after work so he has supplies to make his lunches for the rest of the week. He drives to the store on his way home, gathers his groceries from a list that he has assembled ahead of time, impulse-buys a few unnecessary items, and checks out from the automated kiosk before bagging his groceries himself and taking them back to his car."

If you've come from the world of Agile user stories, this may sound familiar to the prompt of "as an x, I want to do y so that I can z." In that sense, a user story is essentially just a tiny use case, and can be useful for breaking up larger stories into smaller chunks:

  • As a person with a full-time job, Josh wants to buy his groceries conveniently so he can get on with his life
  • As an introvert, Josh wants to be able to buy and bag his groceries on his own so he doesn't have to make small talk with a cashier
  • As a person who loves chocolate, Josh wants the opportunity to get unexpected goodies when he buys his lunch ingredients so he doesn't feel deprived

However, it's important to remember that simplicity also introduces limitations; for example, taking any of those user stories on its own without the larger grocery use case lacks a great deal of context.

Other variations on use cases may also be helpful:

  • Express the use case as a two-column table (opens new window) in which each action gets its own row and is categorized in one of two columns: the actor, or the rest of the world
  • Break the use case into three boxes (opens new window), each containing part of the statement: One box for the user, one box for his need, and one box for any insights gained by looking deeper into that need (this is similar to an Agile user story, but with a deeper level of insight and context)
  • Use a "hill" (opens new window), an IBM-created framework for use cases that frames the outcome of an action (rather than the action itself) as "who" (who the users are), "what" (what the need is that they're trying to meet) and "wow" (how you'll measure success, or how the outcome is better than your competitors)

← Brainstorming →