Use case

A use case describes how a user (or actor) interacts with a system to accomplish a specific goal. It documents the sequence of steps, the system's responses, and what can go wrong along the way. Unlike user stories that capture what users want at a high level, use cases detail exactly how users and systems interact - making them valuable for complex functionality where precision matters.

Why it matters

Use cases bridge the gap between business requirements and technical implementation. They force teams to think through the complete interaction, not just the happy path where everything works perfectly. What happens when the user enters invalid data? When the network fails? When they try to do something unexpected? Use cases capture these scenarios before they become bugs in production.

For product managers, use cases help communicate requirements with enough precision that engineers understand the expected behavior. They reduce the "I thought it was supposed to..." conversations that waste time and create frustration. Well-written use cases also serve as a foundation for test cases, ensuring nothing is missed during quality assurance.

Anatomy of a use case

A complete use case typically includes:

Title - A brief, action-oriented name that describes the goal. "Register New Account" or "Submit Expense Report" clearly convey what the use case covers.

Actor - The user or system that initiates the interaction. Could be a specific user type (Customer, Admin) or an external system (Payment Gateway, Email Service).

Preconditions - What must be true before the use case can begin. "User is logged in" or "Item is in stock" sets the starting context.

Trigger - What initiates the use case. "User clicks 'Add to Cart'" or "Daily scheduled job runs at midnight."

Main Flow - The sequence of steps in the normal, successful scenario. This is the "happy path" where everything works as expected.

Alternative Flows - Variations from the main flow that still lead to successful completion. Different valid paths through the interaction.

Exception Flows - What happens when things go wrong. Error conditions, edge cases, and recovery paths.

Postconditions - What is true after the use case completes successfully. "Order is created" or "User receives confirmation email."

Use case example

Title: Process Customer Refund

Actor: Customer Support Representative

Preconditions:

Trigger: Representative selects "Process Refund" for a customer order

Main Flow:

Alternative Flows:

Exception Flows:

Postconditions:

Use cases vs user stories

Use cases and user stories serve different purposes and work well together:

Many teams use user stories for backlog prioritization and sprint planning, then elaborate complex stories into use cases when detailed specification is needed.

Writing effective use cases

Several principles improve use case quality:

Focus on goals, not features - Use cases describe what users want to accomplish, not system capabilities. "Generate Monthly Report" is a goal. "Click Report Button" is an interface detail.

Use consistent actors - Define actor types clearly and use them consistently. Mixing "User," "Customer," and "Account Holder" for the same actor creates confusion.

Keep steps at the right level - Each step should represent one meaningful interaction. Too granular ("User moves mouse to button") wastes time. Too abstract ("User completes process") hides important details.

Handle exceptions explicitly - Don't assume the happy path. Document what happens when things go wrong - it's often where the most important design decisions lie.

Avoid implementation details - Use cases describe what happens, not how the system does it internally. "System validates credentials" is appropriate. "System queries users table with SHA-256 hashed password" is implementation.

When to use use cases

Use cases add the most value in certain situations:

Complex interactions with multiple steps, decision points, or error conditions benefit from detailed documentation.

Regulatory environments where requirements traceability matters. Use cases provide clear documentation of expected behavior.

Handoffs between teams - When requirements move from product to engineering, or when multiple teams collaborate, use cases reduce misunderstandings.

Safety-critical systems where edge cases and error handling must be thoroughly considered upfront.

For simpler features, user stories with acceptance criteria often suffice. The overhead of full use case documentation isn't always justified.

Use cases in modern development

In agile environments, traditional use case documents can feel heavy. Many teams adapt the concept:

Lightweight use cases capture the essential information without extensive documentation overhead.

Acceptance criteria on user stories often incorporate use case thinking - specifying steps and variations without formal use case format.

Behavior-driven development expresses scenarios in "Given-When-Then" format, capturing similar information in a test-friendly way.

The underlying discipline - thinking through complete interactions including edge cases and errors - remains valuable regardless of documentation format.

Tools like Klero help connect use cases to real user behavior by showing how customers actually interact with features. When use case assumptions conflict with observed behavior, that's a signal to revisit the design or documentation.