Who is the ideal user of your product?
Better yet, what do you want users to do with your product?
And…what *exactly* does that look like? Which buttons do they push? Which actions do they take? What’s the result?
These are all the things that you must take into account when creating a use case.
So what is a use case?
Simply put, it’s how a user or set of users will use your product. Think about why they need to use it and how to make it work for them.
Here at ClickUp, teams of all kinds use ClickUp for different reasons. Some teams are part of digital ad agencies; others are on university conference planning teams. Others are creative designers, or running their own ecommerce shop.
And even within our own walls, our marketing, customer service, engineering, and operations teams build ClickUp using own software. Yes, we eat our own dog food.
Sometimes the use case can be unexpected. You build the product to adapt, but you’re not sure what people will do with it.
In this post, we’ll give a high-level overview of how we think through use cases inside of ClickUp, how you can use this to write short user stories, and how to diagram/think about your user flows.
What is a use case?
Use cases explore the different routes teams take through your software. It covers everything from onboarding new users to organizing themselves. If you’re setting up a marketing department, it’d be nice to find an example of how someone before you structured their marketing projects before diving in.
Exploring use cases for your products also helps you define product specs and requirements before you take the time building out the features. If you have a use case in mind, you want your users to do one thing but not the other.
You want users to do this, but not that.
You want a goal. Writing use cases will help you define that goal and keep it top of mind for your product and development teams.
In other words, use cases will describe the expected behavior in your product, but will not tell you how to build or construct it. That’s what project plans are for.
At ClickUp, we have several use cases in mind when adding new features or specs. For example, Agile teams can use syntax highlighting and code blocks to help them develop more efficiently. The use case is “agile teams” and in our sprints, we developed use cases to think about the end result that we wanted for those types of teams.
What’s a user story?
A user story, on the other hand, is the exact steps and actions that could be taken within the use case. Oftentimes a user story and a use case start out the same way, but a user story becomes more specific.
What parts need to be in a user story?
- How the user (or actor) will provide information
- What does the user decide to do?
- The product responds in a certain way (as impacted by the user’s choice)
- The product asks for more information
- The product creates an output
As you can see, a few of those above steps may be repeated a few times in different scenarios.
Let’s explore some examples:
Example: Self-Service Credit Card Reader.
Here’s how the use case for this would work.
- The user will provide information. The consumer will be prompted to pay for their items. In this use case, the user decides to provide information (i.e. payment) via their credit card or debit card.
- What does the user decide to do? The user decides to use their credit card or debit card to provide the information.
- The product responds in a certain way (as impacted by the user’s choice). The credit card reader determines if what was swiped or entered is a credit or debit card. It verifies within its system.
- The product asks for more information. The credit card reader asks you to sign or enter a pin number, depending on what was chosen.
- The product creates an output. The credit card reader’s back end services determines if the user has enough money to pay for the purchase and if it is approved.
In case you haven’t guessed, I’m not a product manager for a credit card reader, nor have I worked with credit card readers in a professional manner. So yeah, I probably missed a few steps in there.
I would say this is a more of an example of a user story. That is: what are the specific steps that need to be accounted for in the card reader.
The use case would be a grocery store retailer versus a pharmacy versus a restaurant. All of those would be different use cases and may have different needs. For instance, one type of credit card reader may be better suited for a restaurant over a grocery store, because in a restaurant the wait staff may be the only ones using the card reader, and not the customer.
But that’s not true at fast food restaurants, so there is a different use case there too.
See how it’s different?
Use Cases at ClickUp
At ClickUp, one large use case for us are digital marketing and ad agencies. These are clients of ours who also interact with clients on their own. To help manage their projects, we’ve set up specific spaces and granular permissions to help them manage their interactions–and to only allow certain users to see certain things. We did not start out having all of these capabilities until the use case demanded it.
We also recognized the need for multiple spaces, projects and lists to help them with their work. Native time tracking and time tracking integrations also helped with this, especially if they are billing hours to a client.
We also realized that digital agencies often do similar tasks for many of their clients, such as creating a blog post or creating a new landing page. To help, we created checklist templates to facilitate and improve that process.
Don’t Confuse Market with Use Case
Other use cases at ClickUp include personal task management, education teams, game developers and more. We realize in this process that we don’t want to confuse our audiences with use cases. Oftentimes, you can have similar use cases across different audiences.
For instance, will the operations team at a real estate firm be similar to the operations at a dental office? Potentially. They both have invoices, appointments and scheduling needs. And even though the use case may be similar, we may market and talk about ClickUp differently to those teams.
Similarly, a conference planning team at a university may be similar to other large scale event planners–we may just market to them differently.
The Use Case Needs a Bunch Of…Uses
Use cases could also drive your product development and roadmap.
The use case also takes the perspective of the business…how will our product be used multiple times over? If you only have one type of customer using your product, then you wouldn’t necessarily plan new features for that one customer (unless it’s massive). But if you have multiple companies doing similar functions, and you’reIt’s also not one particular interaction (one grocery store using the card reader) but several interactions (multiple grocery stores allowing all of their customers to use the card reader).
Success with Use Cases
To create successful use cases, you’ll have to think through several different scenarios. These three are the main buckets:
The Basic Flow: This is the “main way” you expect your product to operate with no errors. This is also known as the “happy scenario”. You could diagram this with each step, logically following the next. Diagramming this helps you see the path and ensures that no steps are missed.
Error Flows: This is the flow when a user reaches a dead-end of sorts and there’s no way out. Yes, this would be a bug and not a happy scenario.
Alternative Flows: Oh boy. This is the more complicated products where several options are presented. Like in a game for instance. At ClickUp for instance, we have a few different flows for creating a task–such as creating one from any screen, creating one from a list or even creating a task from our Chrome extension. All of these alternative flows can get quite complicated which is why bugs sometimes happen (Uh oh).
Conclusion: Why Are Use Cases Important?
Hopefully, this gives you a helpful overview of use case and user stories. Use cases are important because they 1) help you develop your product and product features 2) help you see trends within your product 3) help you know what to prioritize for features. Understanding how your core users interact with your product on a regular basis could drive a lot of your decisions and gives you insight on how a product will be received.