"One of the fastest ways to design the wrong system is to start thinking about classes before understanding what the system is actually supposed to do."
Imagine someone asks you to design an online food delivery platform.
Many developers immediately begin thinking about classes.
Customer
Restaurant
Order
Payment
DeliveryPartner
But here's the problem.
At this stage, you don't even know what the system is expected to do.
Can customers schedule orders?
Can restaurants reject orders?
Can delivery partners cancel deliveries?
Does the system support cash on delivery?
Before discussing implementation, we first need to understand the goals of the people using the system.
That's exactly what Use Case Diagrams help us do.
They shift our focus from how the software is built to what the software is expected to accomplish.
Why Do Use Case Diagrams Exist?
Every software project begins with requirements.
Before we discuss classes, APIs, databases, or services, someone has to answer a much simpler question.
"What should this system actually do?"
Surprisingly, many design mistakes happen because engineers jump directly into implementation without fully understanding the problem.
Use Case Diagrams solve this by helping everyone answer three simple questions:
- Who uses the system?
- What are they trying to accomplish?
- What responsibilities belong to the system?
Instead of thinking like programmers, they encourage us to think like product designers and users.
What Is a Use Case Diagram?
A Use Case Diagram is a high-level view of a system that focuses on user goals.
It doesn't explain algorithms.
It doesn't describe databases.
It doesn't model object relationships.
Instead, it captures the different ways users interact with the system.
Think of it as answering this question:
"If I were using this application, what would I expect it to help me do?"
The Three Building Blocks
Every Use Case Diagram is built from just three core ideas.
Actors
Actors are the entities that interact with the system.
They are usually:
- users
- administrators
- external systems
- third-party services
An actor is not necessarily a person.
It simply represents a role.
For example, the same individual could act as both:
- Customer
- Seller
depending on what they are doing.
Use Cases
A use case represents a goal.
Examples include:
- Search Product
- Place Order
- Cancel Booking
- Process Payment
- Track Delivery
Notice that use cases are always expressed as actions.
They describe what the user wants to achieve.
System Boundary
One of the most overlooked concepts in UML is the system boundary.
It defines where your system begins and ends.
Everything inside the boundary is your responsibility.
Everything outside belongs to another system.
Consider a food delivery platform.
Payment Gateway
│
Customer ─────┐ │
▼ ▼
-------------------------
| Food Delivery App |
|-------------------------|
| Search Restaurant |
| Place Order |
| Track Delivery |
| Cancel Order |
-------------------------
▲
│
Restaurant
This simple box answers an important question:
What exactly are we building?
Without a clear system boundary, software projects often grow beyond their intended scope.
Thinking in User Goals
One of the biggest mindset shifts in software design is learning to think in terms of goals instead of features.
Consider Amazon.
Instead of thinking:
Product
Cart
Inventory
Order
Ask yourself:
What is the customer actually trying to accomplish?
The answers look very different.
Search Products
Add Item to Cart
Checkout
Track Order
Cancel Order
These are use cases.
Notice that they're all meaningful business goals.
A Real-World Example: Ride Sharing
Let's identify the actors first.
Customer
Driver
Admin
Payment Gateway
Now let's think about their goals.
Customer:
- Request Ride
- Cancel Ride
- Track Driver
- Pay Fare
Driver:
- Accept Ride
- Start Trip
- Complete Trip
Admin:
- Suspend Driver
- Resolve Complaints
Payment Gateway:
- Process Payment
Immediately, we gain a much clearer understanding of what the platform actually needs to support.
Notice that we still haven't discussed implementation.
That's intentional.
One System, Many Perspectives
Different stakeholders care about different things.
A Product Manager asks:
"Can the customer cancel an order?"
A Customer Support representative asks:
"Can we refund cancelled bookings?"
A Designer asks:
"How does the booking flow work?"
A Backend Engineer asks:
"Which services should handle payment?"
Only one of these questions is about implementation.
The others are about understanding the business.
Use Case Diagrams help align everyone before technical design begins.
Include vs Extend
Not every user action is independent.
Some actions always happen together.
Others happen only under specific conditions.
This is where Include and Extend become useful.
Include
An included use case is mandatory.
Whenever the main use case executes, the included one also executes.
Example:
Place Order
│
▼
Process Payment
Every successful order must process payment.
Payment is therefore included.
Extend
An extended use case is optional.
It occurs only under certain conditions.
Example:
Cancel Order
│
▼
Refund Payment
A refund is not required for every cancellation.
It depends on business rules.
That's why it extends the cancellation flow instead of being mandatory.
Weak Thinking vs Strong Thinking
Weak Thinking
What classes should I create?
Strong Thinking
What goals are users trying to achieve?
Weak Thinking
Let's design the database first.
Strong Thinking
Let's first understand
what problem we're solving.
Weak Thinking
Every requirement is technical.
Strong Thinking
Every technical solution
starts with a business need.
Common Beginner Mistakes
Treating Use Cases as Classes
This is one of the most common mistakes.
Writing:
Customer
Order
Payment
is not a Use Case Diagram.
These are domain objects.
Use cases should represent actions.
Place Order
Make Payment
Track Delivery
Ignoring External Systems
Real systems rarely work in isolation.
Payment gateways.
SMS providers.
Email services.
Maps.
Identity providers.
These all interact with your application.
Good Use Case Diagrams acknowledge those interactions.
Making Use Cases Too Technical
A use case should never be:
Call Payment API
That's an implementation detail.
Instead:
Make Payment
The system can decide later how that payment is processed.
Forgetting the System Boundary
Without defining the system boundary, teams often argue about features that don't even belong in the current project.
A clear boundary keeps everyone focused.
Interview Perspective
One of the biggest differences between experienced candidates and beginners appears before any code is written.
Experienced candidates spend a few minutes understanding the problem.
They identify:
- the actors
- the business goals
- the scope
- external systems
Only then do they move toward Class Diagrams and implementation.
Interviewers appreciate this approach because it demonstrates disciplined engineering thinking rather than rushed coding.
The Most Important Insight
Use Case Diagrams are not about software.
They're about people.
Before designing databases, APIs, or classes, experienced engineers first understand what users are trying to accomplish.
When user goals are clear, technical decisions become significantly easier.
When user goals are misunderstood, even beautifully written code solves the wrong problem.
One-Line Takeaway
Good software begins with understanding user goals—not with writing classes.
Top comments (0)