Writing Use Cases To Detail User InteractionsJuly 7th 2009
I’m currently reading Designing The Obvious: A Common Sense Approach To Web Application Design, by Robert Hoekman, Jr. It has been extremely useful for me so far, and contains loads of high quality information about designing web applications, everything from theory and philosophy of, to techniques and methods. One idea that Hoekman writes about is use cases.
I had never heard of a use case before reading this book, but it’s a method that seems to be great for detailing how exactly an interaction on your web app should happen. The advantage of creating use cases before you get into mock ups and prototypes is that first, nothing is cheaper or faster than writing something down, and second, this process allows you to see potential problems in an interaction, or areas that an interaction could be improved or streamlined.
An example use case (and the refining process) for a user recommending a product to a friend might look something like this:
Step 1. While viewing a product, the user clicks a button named “Recommend to a friend,” and a modal window pops up with the product title, image, small description, and a short form for the user to input their name and email, their friend’s name and email, and then a submit button.
Step 2. The user fills out the form with the necessary information and then clicks the submit button. The email is sent to their friend, and the modal window closes.
This is a good start in that the use case details exactly what is needed for the goal of sending a product recommendation to a user’s friend to be met. However their are a few areas that can still be improved. Since a user is already viewing the product, it is redundant to show them the product name, image, and description. This is wasted space and unnecessary information for them, so why show it? We can remove that to make it quicker and easier for a user to fill out the form to recommend the product (when the email is actually sent, however, we will obviously want to include the product name, picture, and description).
Thinking more about this interaction, a problem arises. We have not accounted for the possibility that the user may choose not to fill out the form. Currently, they are stuck, so we need to add a cancel button in Step 1 and an exception to Step 2, allowing the user to click cancel and return to the page without sending the email. It also might be nice for them to add a personal note, so let’s add a text field for that.
In addition, the user has no way of knowing if their recommendation has been sent: currently when they click submit, the modal window simply closes. We can add a simple confirmation notice before the modal window closes that lets them know their recommendation has been sent.
After taking out unnecessary elements and fixing several issues, the final use case for this interaction is as follows:
Step 1. While viewing a product, the user clicks a button named “Recommend to a friend,” and a modal window pops up with a short form for the user to input their name and email, their friend’s name and email, and write a short personal note in a text field if they wish, and then submit and cancel buttons.
Step 2. The user fills out the form with the necessary information and then clicks the submit button. The email is sent to their friend, a quick confirmation notice is shown, and the modal window closes.
Step 2a. The user decides not to fill out the form, clicks the cancel button, and the modal window then closes.
Perhaps this method seems pointless or obvious, but it makes perfect sense to plan and think about what exactly you want to happen before you start getting into design and code. The power of use cases is that you can write out every possible scenario for an interaction given the interface and note problems that you may not have thought of originally or areas that you can cut out unnecessary elements or features.
