The Use Case of Use Cases
Helping your customers by looking at your product from their perspective
How are you going to use this article? Let’s walk through a USE CASE. First you are going to read it, nod at parts and shake your head at others, then skim over a paragraph or two, and at the end you are likely going to make a note of the headings and main takeaway. If this article piques your interest, then it is likely you are reminded of a specific instance where you could have used a USE CASE in your last project.
Or maybe you are in the middle of a product project, and are continually uncovering gaps that are forcing you to go back to the beginning.
The USE CASE has different names in different industries, with various levels of formalities. Storyboard, Usage Scenarios, Brain-storming or Mind Mapping. USE CASE in software of systems development are sometimes highly structured, with its own language. Not to be burdened by the terms or industry jargon, for our purposes, we will define USE CASE’s as flexible thought-experiment structured thinking around your product.
What you really want to know is how can use a USE CASE to make your product better and deliver value to your customers. The way we have successfully used USE CASES is in the communication of the product, defining actors involved, scenarios, environments, and user interactions and special functions, like troubleshooting and service. USE CASES’s help you do this by creating a baseline customer user experience, and monitoring for actual usage differences from this expected baseline, and uncovering hidden requirements.
CREATING A BASELINE USER EXPERIENCE
To create a baseline user experience, think through and document the entire life cycle of your product. This includes not only the periods of time when your customer is using the product, but also when it is in transit, before first use, or is in storage. The desire is to cover the entire life of your product and think about issues before your customer experiences them.
Once you have this baseline, you can then drill down on specific functionality or areas of usage.
How does your product navigate the factory, and hold up during shipment to the customer? When the user first opens the product package, what has to happen before the product can be used as intended? When the product has been in storage for a while, are there special actions that the user needs to perform before the product can be used? Filling out a USE CASE for each of these scenarios can help you clearly define your product.
To create the USE CASE, it helps to have a specific person in mind, or multiple different actors. Go through the mental exercise of how this particular user will interact with the product. You can go as far as giving them a name and personality. When they open the package, what is the first thing they see, and do they know how to turn your product on and off? What are the steps they need to take to actually use the product?
Defining your product in this manner also helps your team. Explaining how the product work allows them to implement the functionality as it is described, and not make wrong and incorrect assumptions about the product. When characteristics of your product are not described, product developers will fill in the gaps with the assumptions they make about your customers. The USE CASE helps them get this right, or point to gaps that need filling.
If your product needs to be installed, then a USE CASE could go through the installation of the device, and what technicians will need to do. Realize that when your product ships, if you do not want constant calls, it has to work or be understood how to work.
The use case serves to inform of the expected usage of the device. Having an expected user experience allows for differences to be detected and assumptions confirmed. Even if the customers use the product differently, checking against these assumptions can provide valuable customer information.
MONITOR ACTUAL USER EXPERIENCE AND LOOK FOR DIFFERENCES
It is not easy to uncover all possible USE CASE scenarios by imagining your customers using your product. Customers will surprise you and use your product in unintended ways. But if there is no baseline, then no differences can be detected, and assumptions are harder to uncover and question.
If someone is not using your product like you intended, maybe this is an idea for a new product! If the product was designed for one task and used for a different one, it may speak to the versatility of your product and uncover another market need. There may be options to increase the usefulness of how the customers are using it in the unintended way.
Your own familiarity with your product gets in the way of seeing how an inexperienced user would use it. It is like a little child at an old desktop computer — He touches the screen and then picks up the mouse and starts talking into it, then when nothing happens, starts holding it to his ear! One of the most commonly cited causes of product error is “user error” which may be because the user just doesn’t understand the proper use of the device.
Don’t let smart customers sabotage your product because they just don’t understand how to use it. You have spent a lot of time and thought, and maybe use your product yourself. However, your customers may not have the experience that you do. Don’t beat them up, but try to guide them through the proper use of your by monitoring their usage.
UNCOVERING HIDDEN REQUIREMENTS
Ultimately, by using USE CASES, you will uncover requirements that may not have been initially captured in the functional requirements or product description document. These documents are created with the perception that you know what product the end customer needs.
When one of our clients describes how a product is going to work, we ask lots of questions. We have to know this information to create the product. These questions and methodically walking through a USE CASE will pull out product details that may not have been completely thought through.
While walking through a USE CASE we will ask “How will the user know to press that button? When will the user know it is working? Not-working?” And our favorite “And then what?”
One example is a sensitive device that would be used to make measurements during a construction project. We covered the usage case, but then during the questioning about how the user would store the device, found that it needed to be well protected. It could not just be put in the back of a work truck, and would need to ride in a protective case, most likely in the truck cab. The harshest environment was not the one that the device was used in, but in the transportation to and from the worksite.
The assumptions about how customers are using the product are important for not just design, but also testing and validation. As a group that validates products, one example that sticks in our mind is when the first robotic vacuum was released. The product designers initially assumed that people would vacuum as much as they did manually before, typically weekly. The test and validation program covered this level of expected usage. What they found were worn out components, and they realized that if people did not have to be present and push the vacuum, they would run the robots daily! Components that were designed to operate 52 times a year were operating over 7 times that rate.
CONCLUSION
A USE CASE is simply answering, “How are the users going to in your product?” You are trying to foresee problems that your customer may encounter to preemptively fix the problems that they might see. Go through the customer product experience before they experience it, to remove un-necessary steps or make product use easier, more consistent and more robust. After it is developed, observe customer confusion and pain points. Use these learning’s to update the requirements and change your product.
Hope you found it USE-ful.
Wade Cunningham is the Program Manager at Glassboard, a hardware focused product development company.
