Use case diagrams are like blueprints for how people and external systems interact with your software or product. They help teams visualize functionality from the user’s perspective—what the system does, who uses it, and how everything connects.
At their core, these diagrams revolve around three main elements: actors, systems, and use cases. Let’s break them down in a way that’s practical, clear, and free of robotic textbook language.
1. Actors: Who’s Actually Using the System?
Actors aren’t just users—they can be anything outside the system that interacts with it. Think of them as the “who” in the equation:
- Human users (e.g., customers, employees)
- External software (e.g., payment processors, APIs)
- Hardware devices (e.g., sensors, IoT gadgets)
Primary vs. Secondary Actors
- Primary actors directly engage with the system to achieve something.
- Example: In a food delivery app, the customer placing an order is a primary actor.
- Secondary actors assist the system but don’t initiate actions.
- Example: The SMS notification service that alerts the customer about their order status.
Real-World Scenario:
Imagine a fitness app:
- Primary Actor: The user logging workouts.
- Secondary Actor: Google Fit syncing health data in the background.
Key Note: An actor can represent a role, not just a single person. “Admin” might cover multiple employees with the same access level.
2. Systems: Where Does Your Product Start and End?
The system boundary is like drawing a box around what your team is actually building—everything inside is your responsibility; everything outside interacts with your system but isn’t part of it.
Why Boundaries Matter
- Prevents scope creep: Stops stakeholders from assuming external tools (like Stripe for payments) are part of your system.
- Clarifies dependencies: Identifies what your system relies on (e.g., third-party APIs).
Example: Airbnb’s System Scope
- Inside the boundary: Booking a stay, host profile management, review system.
- Outside the boundary: Google Maps (for location), PayPal (for payouts).
3. Use Cases: What Can the System Actually Do?
A use case is a single, meaningful action the system performs for an actor. It’s not a step-by-step workflow—it’s the end goal (e.g., “Cancel subscription,” not “Click button → Confirm pop-up → Process refund”).
Spotting Good Use Cases
Ask:
- Does this represent a complete user goal?
- Is it high-level enough to avoid technical minutiae?
Example: E-Learning Platform
- Good use cases: “Enroll in course,” “Submit assignment,” “Generate certificate.”
- Too granular: “Click ‘Next’ button,” “Load quiz questions.”
Relationships: How Use Cases Connect
- Association: Straightforward interaction (e.g., Student ↔ “Take Exam”).
- Include: Mandatory sub-actions (e.g., “Checkout” must include “Process Payment”).
- Extend: Optional branching (e.g., “Upgrade Membership” can extend “View Profile” if the user chooses to).
Putting It All Together: A Real-World Diagram
Let’s model a co-working space booking system:
Actors
- Member (Primary): Books desks, pays invoices.
- Admin (Primary): Manages memberships, spaces.
- Stripe (Secondary): Handles payments.
Use Cases
- Book Hot Desk
- Cancel Reservation
- Generate Invoice (includes “Process Payment” via Stripe)
- View Occupancy Dashboard (extended by “Notify Waitlist” if full)
Visualizing the Flow
- Member connects to Book Hot Desk, Cancel Reservation.
- Admin connects to View Occupancy Dashboard.
- Generate Invoice links to Stripe.
Common Mistakes (And How to Avoid Them)
- Overcrowding the Diagram
- Focus on core functionalities—not every minor feature.
- Mislabeling Actors
- Your database isn’t an actor—it’s internal. Mailchimp is an actor if it sends emails.
- Vague Use Cases
- “Manage Profile” is better than “Edit Settings”—it covers all profile-related actions.
Why This Matters
Use case diagrams force you to think from the user’s perspective before diving into code. They’re a communication tool—aligning developers, designers, and stakeholders on what the system should (and shouldn’t) do.
Next time you sketch one, ask:
- Who’s involved?
- What are they trying to achieve?
- Where does our system’s responsibility end?
Keep it simple, and you’ll have a powerful visual that keeps everyone on the same page.