I hear the phrase "So what's the use case?"' a lot these days. Maybe I just have my ears tuned into this software development practice but that's ok, Use Cases are a great tool for defining a product's functional requirements, something we are doing right now at ZURB.
Use Cases come in many forms and have been around awhile but they all have two basic components.
Actors and Scenarios
As design strategists, we do a lot to identify the Actors in our design process. We define Customer Segments and generate User Profiles to help us make sure we are focused on the right audience. These User Profiles are the same Actors we go on to use in the Use Cases we create. They have specific names like Susan or Michael and we refer to them by these names. In some cases the Actor could also be a machine (let's not forget our robot friends play a big role in many business interactions). An example of a non-human Actor can be seen in the following excerpt:
- Michael clicks "Send to Susan"
- The System places his message into the pending cue.
- The Moderator approves Michael's message.
It's when we put these Actors into a Scenario that things really start to get interesting. A Scenario is one path or work flow of an Actor through a part of your application or business process. Scenarios correspond to goals real users will set out to accomplish.
Get it down
Often we think we understand exactly how something will work but it's not until we sit down and actually *do it* that the details emerge and unforeseen problems arise. Writing a Use Case forces us to be honest about what we are asking of our users and the application. A Use Case spells out, step by step, what must take place for that Scenario to run to a successful completion. Unlike a Page Flow, or an ordered list of screens the user might expect to see when trying to achieve a goal, the Use Case lists out the steps required by the Actor and or other Actors to complete the necessary tasks in order to achieve the goal of the Scenario.
There are several types of Use Cases, some more formal and detailed than others but as long as they are presented clearly with details (ie. Michael clicks the capture button in his toolbar) and preceded with any necessary qualifiers (ie. Micheal is currently logged out). These steps can be translated with little confusion to the logic of the program that must be built to bring your pages to life.
Don't let em get you down
While it might sound like a daunting task, writing Use Cases can be quite painless. Here are some helpful tips:
- Keep it simple
Break your Scenario down into simple A-B, B-C, C-D steps rather than the grand A-D Goal Map. If you find yourself branching, separate that into another Scenario. - Start with the basics
You know there are some definite givens like "sign up" or maybe the primary function of your product. Start with these in the optimal scenario and then create those for the different conditions you will need to add to each. - Have a little fun
Work can be a drag if you don't infuse it with a little humor. I like to create Scenarios the push my Actors into tough spots, then I can really see how the application can be designed to help them interact smoothly to get them out of their fix.
Down the road
The use case should live on and be echoed throughout your organization well beyond your launch party. Marketing and Sales can benefit from the same Scenarios you create in your Use Cases by telling that story to customers as the script for presentations and demos. In fact if you listen closely, they will tell your product manager the next Use Case Scenario you'll need to write.
More on Use Cases:
Why I still use Use Cases
Use Cases - Ten Years Later
Example 1
Examples 2
Relationship to Functional Requirements