Use Case

Understand This First

• User – the primary actor is a specific user type.
• Problem – the use case describes how the user solves a specific problem.

Context

At the strategic level, a use case is a more concrete description of a User goal and the interaction required to achieve it. Where a User Story is a brief statement of intent (“As a manager, I want to approve expense reports, so that employees get reimbursed quickly”), a use case expands that into a step-by-step account of what happens: the preconditions, the main flow, the alternative flows, and the postconditions.

Use cases sit between user stories and technical specifications. They’re detailed enough to guide implementation but written in user-facing language rather than technical terms. They’re particularly useful when the interaction involves multiple steps, branching paths, or coordination between the User and the system.

Problem

User stories tell you what the user wants and why, but not how the interaction unfolds. For simple features, the story is enough. For complex interactions (multi-step workflows, error recovery, interactions involving multiple actors) the team needs more detail. Without it, developers and AI agents make assumptions about the flow that may not match the user’s expectations or the product manager’s intent.

Forces

• Stories are too brief for complex interactions; developers fill gaps with assumptions.
• Full specifications are too heavy for most features and become outdated quickly.
• Use cases must balance completeness and readability. Exhaustive cases are rarely read.
• Alternative flows (errors, edge cases, cancellations) are where most bugs and UX problems hide.
• Multiple actors (user, system, third-party service, AI agent) make interaction flows harder to describe.

Solution

Write use cases with the following structure:

• Title: A verb phrase describing the goal (“Submit an Expense Report”).
• Primary Actor: Who initiates the interaction (the User type).
• Preconditions: What must be true before the interaction begins.
• Main Success Scenario: The numbered steps of the happy path, alternating between user actions and system responses.
• Alternative Flows: Branches from the main scenario: error conditions, cancellations, and edge cases. Reference the main scenario step where the branch occurs.
• Postconditions: What is true after the interaction completes successfully.

Keep the language non-technical. “The system displays a confirmation message” rather than “the API returns a 200 response and the frontend renders the ConfirmationModal component.” The use case describes behavior visible to the user, not implementation details.

For agentic coding, use cases are excellent prompts. An AI agent given a complete use case, including alternative flows, will produce more resilient code than one given only the happy path. The alternative flows force the agent to handle errors and edge cases that a story alone might not surface.

How It Plays Out

A product manager writes a use case for “Generate a Monthly Report”:

1. The team lead selects a project from the dashboard.
2. The system displays a date range selector defaulting to the previous month.
3. The team lead confirms the date range or adjusts it.
4. The system generates the report, showing progress.
5. The system displays the completed report with a download option.

Alternative flow 3a: The team lead selects a date range with no data. The system displays a message explaining that no activity was found and suggests broadening the range.

Alternative flow 4a: Report generation takes longer than ten seconds. The system offers to send the report by email when ready and returns the user to the dashboard.

This use case gives a developer (or an AI agent) enough information to build the feature correctly on the first attempt, including the edge cases that would otherwise surface as bugs in testing.

A developer pastes the use case into an AI agent’s context along with the relevant codebase. The agent generates the report generation logic, the UI components, the error handling for empty date ranges, and the asynchronous email fallback, all from the use case description. The alternative flows, which took three minutes to write, save hours of back-and-forth during implementation.

Consequences

Use cases reduce ambiguity for complex features and surface edge cases early, before they become bugs. They create a shared understanding of behavior that product managers, designers, developers, and AI agents can all reference.

The cost is time. Writing detailed use cases for every feature isn’t practical or necessary. Reserve them for interactions that are multi-step, involve error handling, or have multiple actors. For simple features, a User Story with acceptance criteria is sufficient.

Use cases also tend to become stale if they aren’t updated as the product evolves. They’re most valuable during initial design and implementation. After the feature ships, automated tests and documentation take over as the authoritative description of behavior.

Related Patterns

• Refines: User Story — a use case expands a story into detailed interaction steps.
• Depends on: User — the primary actor is a specific user type.
• Depends on: Problem — the use case describes how the user solves a specific problem.
• Uses: Roadmap — use cases flesh out roadmap items in the “Now” horizon.
• Enables: Build-vs-Don’t-Build Judgment — writing the use case sometimes reveals that the feature isn’t worth the complexity.