Unless your business is a true trailblazer, you’re probably doing something another business is doing. We’re sure you’re doing it better, of course. This practice places you on the map in an area labeled, “Here there be dragons.” Having automatic or un-thought-out practices — like those you borrow from an industry standard — is dangerous. You might fall prey to the Pot Roast Principle.
As the legend goes, a young bride was making an inaugural dinner for her husband. She made pot roast — his favorite. She chopped off one end of the roast and discarded it, placed the rest in a roomy pan with vegetables and seasoning, and slid it into the oven.
The new groom hesitantly asked why she threw away the end piece (it was his favorite part). “That’s how my mother always made it,” his wife explained. But her curiosity was piqued and she asked her mother about it the following week. “That’s how my mother always made it,” she replied.
Now intrigued, the pair telephoned Grandma, asking for an explanation. “I had to chop off the end,” she said. “I never had a pot big enough for the whole thing.”
Business is hard. It’s tempting to make some of your decisions via shortcut. “That’s how the competition does it,” you might think, or worse, “That’s how we’ve always done it.” But fear not: Use cases can be a mighty dragon slayer, and this article will show you how to use them.
Overview: What is a use case?
Use cases have their roots in software and systems engineering. In the ancient days of telecom development, an engineer at Ericsson recognized the Wild West approach to designing systems and software was expensive and inefficient. He proposed a blueprint-based method of looking before leaping, which developed into the use case model we recognize today.
Use cases blossomed with the advent of agile software development and its incursion into broader business management. While we now talk about systems use cases, business use cases, essential use cases, and even something called Use Case 2.0, all have the same core elements. It turns out a good way of developing software is also a good way of doing business.
4 benefits of use case modeling
You may wonder why you should add another task to your already voluminous to-do list. After all, use cases don’t write themselves. Use case modeling takes time, effort, and planning. But used properly, use cases can also save you time and effort — and lots of rework. Use cases have many benefits, including these.
1. Simplify complex projects
A use case outlines a single function. If you are planning a large project with multiple components, a use case brings an essential discipline that requires breaking down the project into discrete tasks. Not only can this make it easier to grasp the entire project, but it can also help identify aspects with no value for the user — functions you may not need at all.
2. See things from the user’s (or customer’s) point of view
While we all know we should be doing this in every aspect of our business, it’s easy to overlook what a customer needs or expects. Whether your customer is a buyer of your company’s goods or services or an internal customer — another department, perhaps — a use case will keep that person’s needs at the top of the priority list.
3. Streamline project tracking
Since each use case solves a customer issue, all the use cases in your bigger projects bring value to your customer. Breaking them out into discrete functions helps to define and clarify that value so you can focus on what the end user really wants and not be distracted by tasks that add more work than value.
4. Sidestep expensive errors
Part of developing a use case is to think carefully about how your end product, process, or service should work. Along the way, you’ll brainstorm about possible pitfalls. By considering what might go wrong before you begin, you’ll have a plan in place for even worst-case scenarios.
How to employ a use case
Writing a use case is simple, but it’s not easy. For an existing process, you have to be willing to break your system down into its smallest components and examine how each functions. For a new process or product, you have to be wildly creative and imagine every possible glitch, slowdown, or source of dissatisfaction. Make sure to rope in the relevant stakeholders and approach this as you would any project management process.
Your use case design will probably be unique to your business, but every use case will have at least three elements:
- A user, or actor: The individual whose viewpoint you’ll consider.
- A goal: What your user is hoping to achieve.
- A system: The process that will allow your user to achieve their goal.
The system is where you will spend most of your time, but it’s essential to precisely define and consider all three of these. And while your use case will help you in project planning, it’s a project in itself. You’ll want to use project management best practices as you work.
1. Define your user
You’re going to look at everything from the user’s point of view, so it’s essential you define your user. A website’s users are its visitors — simple enough. But who is the user for your new marketing software? Are you hoping it will make things easier for your sales team?
Will it integrate with invoicing, inventory, and accounting systems? You might have many kinds of users for a single product or process, and you’ll want to drill down and make sure your new initiative works for each type of user.
2. Determine your user’s goals
With a new website, what do your visitors want from your site? Are they looking for your physical address or a phone number? Do they want to know more about your products? Or is the site itself a product, such as a video streaming site or a social network? And, if so, what do those users want to accomplish when they visit?
Your product might serve many needs; in that case, you’ll need many use cases — one for each type of user and each goal. A Netflix user may want to watch movies, but he or she might also want to update their account settings or add a user profile. Your use case will ensure they’re able to accomplish all their goals easily.
3. Map out each step of the user’s journey
If your restaurant is adding a drive-through, drive through! Consider how a customer will access the ordering point and place your menu there, rather than deciding based on the current location of your deep fryer or landscaping.
Is the signage visible from tall SUVs and tiny subcompacts? Are your menu options clear? Is payment quick? Measure ticket times for all menu items and all traffic situations. Consider what impact weather might have (is there a roof over your order point and windows?), and imagine what your customers might need beyond menu items (utensils, napkins, condiments).
Do all this on paper first — this is the beauty of the use case. Sample other drive-throughs and see what works and what doesn’t. Brainstorm how your restaurant can satisfy your customers’ unmet, and even unspoken, needs. Erase the bad ideas and pencil in the good ones — it’s a lot easier to redraw a diagram than to cut a new window in your building.
It’s important at this step to consider both how the user will probably proceed, and also how the user might proceed — an alternate flow. In the drive-through case, what happens if your customer decides they want fries at the pay window? What will you do if someone walks into your drive-through? Each use case scenario can provide valuable insights into how your whole system should work.
4. Repeat for each user
As shown in the diagram above, a restaurant has many transactions and many users. The customer is always your primary user, but a system that doesn’t work for the kitchen or wait staff will soon fail the customers as well.
Consider what steps a server must take during the dining experience. Are resources (water, glasses, flatware) placed in the best spot, or must a server make several trips to several areas to collect what’s needed? Is your ordering system easy for servers to use — and does it provide clear directions to your kitchen staff?
Then walk through the chef’s process. Do the same for your bartender, bussers, maitre d’, valets, and managers.
5. Refine user relationships
Let’s stick with our restaurant example. You’ve considered each user’s goals and mapped out the process they’ll use to reach their goals. But you’ll see a lot of overlap, and you might also see conflict.
Examine any of these touchpoints, and try to find a solution that meets everyone’s needs. For example, the kitchen staff would probably find it easier to make just one dish all night, and your wait staff might be ready to jump on that train too, but your customers probably won’t bite. Your system refinement should allow for variety for your customers, clarity for your servers, and efficiency for the cooks.
6. Run a trial
Give your restaurant or hotel a soft launch to shake out any hitches, beta test that software, and test market your new product. Even the most creative team can misjudge how a new system fares in the real world.
Plan your trial run early in the process so you can fix any glitches at minimal cost and delay. If you use project management software, let it help you automate workflows and simplify team communication as you refine your product.
2 use case examples
Intro business classes will often illustrate the use case concept with an oversimplified example — making a peanut butter and jelly sandwich, for example, or filling a gas tank. These are useful because they show the granularity you need when developing a use case. Making a sandwich isn’t one step — it’s many, and you need to document each one.
Here are some real-world examples of when use cases saved the day — or when they could have, had they been implemented.
1. Do you really need that?
If you’re lucky enough to be starting from scratch, you can devise a use case for every process in your business. Sometimes, though, a use case comes into play with a system or product you’re already using. A use case can help at any point in your project life cycle. That’s as it should be — never stop looking critically at your systems just because they seem to be OK. If it ain’t broke, fix it anyway.
As an example, Elisha Otis’s 1850s safety elevator was a tech breakthrough, but elevators still needed some expertise to run smoothly. Uniformed elevator operators filled the bill, but they still continued in service well after automatic elevators had become the norm.
For decades, department store patrons and luxury high-rise residents had scads of awkward encounters directing attendants, often still full-time and liveried, to push a button. That’s a high price to pay for what had become a low-value service.
Does your business have no-value-added holdovers? A use case can help sniff them out and streamline your practices. If you’re familiar with lean business principles, you may already have a head start on identifying blockages in your value stream.
2. Speed up that horse!
A quote (probably inaccurately) attributed to Henry Ford states, “If I had asked people what they wanted, they would have asked for a faster horse.”
While the term use case hadn’t yet been coined, Ford was employing the same instinct when he went beyond what people said they wanted. The prevalence of horses blinded most people to the underlying need. People didn’t need horses; they needed transportation.
In the agile world, identifying the user’s raw need is called a “user story.” It’s not the same as a use case, but it can be an important first step in developing one. Make sure you know what your users want, and then build your use case to map out, step-by-step, how your new product or process will provide it. Your user story is the big picture; a use case is the road map that gets your user to their goal.
Make use of the use case
You wouldn’t head out on a cross-country road trip without a map, and you wouldn’t build a house without a blueprint. A use case helps you anticipate and prepare for problems so you can move your project forward with confidence.
View more information: https://www.fool.com/the-blueprint/use-case/