Write Use Cases

When you're ready to start creating something tangible, a use case is an excellent way to capture the workflow that you will eventually build into an application. A use case is a set of step-by-step instructions for how an interaction or a task might be accomplished. You may have heard the term use-case thrown around in your office a few times, and may even understand what it means. If you're a programmer, you probably know better than most, as use cases are often written to explain a procedure before writing the code, to bring it to life.

A use case can be kept at a high-level, describing general situations in which the application will be used (for example, Mary goes to Target.com to create a list of furniture items needed for her new home office), or it can include more detailed descriptions of what actually happens on the screen when each operation is performed and how the user interacts with the user-interface controls along the way.

Faster than code and capable of producing real results

Writing use cases is, perhaps strangely, one of my favorite things to do. In five to 30 minutes, typically, I can list out the exact process for how an interaction will work once it is built. This exercise invariably exposes potential problems and brings to light any assumptions I was making about a task prior to writing it. It also provides a common ground for the developers and myself. When we communicate through use cases, we're speaking the same language, and that's a good thing.

Just yesterday, in fact, I wrote a use case for a task that enables users to submit personal recommendations for products. To do this, I wrote out several steps that looked like this:

Write a Recommendation

Step 1.	User clicks the Write a Recommendation text link, and a short form is displayed immediately beneath the button. Tech note: This form resides in a hidden DIV and loads with the rest of the page.
Step 2.	User completes the form.
Step 3.	User clicks OK to submit the recommendation, and the form disappears.

Then I thought to myself, that doesn't sound right. If the form just disappears as soon as you click OK, the user would have no idea whether or not the recommendation was successfully submitted. So I revised Step 3, opting to keep the form visible after clicking OK, and displaying a message above the form to tell the user the submission was successful. Then I realized that there would have to be a way to close the form once the user was done with it. So I added a fourth step, in which the user clicks a Close button. But I had to decide where to put the button. I asked myself, Should I make a new button and display it as part of the form? Nah, I think I'd rather make the Write a Recommendation link toggle based on context. This link can't be used once the form is displayed, for obvious reasons, so instead of disabling it and displaying another button for the Close action, why not reuse Write a Recommendation in a new context? Once you click that button, its label and function could change to a Close button. If I combine the two buttons, I enable the user to open and close the form without moving the mouse (should the user decide not to complete the form, that is).

So, great, now I have a four-step use case that says the user will click the button, complete the form, click OK to submit the form, and click Close to make the form go away (optional). I now have a single button that has two purposes, the user has access to the form right in the page instead of being sent to another page in a round-trip process, and the whole interaction is "as simple as possible, but not simpler" (Albert Einstein). Perfect. That's my use case.

Wait. What happens if the user decides not to complete the form?

Writing exceptions

Exceptions are subuse cases that detail what happens when the main use case cannot be followed from end to end. This is very common in Web applications, and it's extremely important to address the alternative workflows because no oneand I mean no oneuses an application exactly the same way you do, or how you might have intended them to use it.

(Quick story: I once spent several days using and testing an application to see how it held up against the latest changes. I didn't come across any major problems, so I set up an account for my wife to let her try it out. The very first thing she did was break it. It didn't even take two minutes. The lesson to learn? No two people will use a Web application the same way, so you can't test only the ideal way of completing a task. You have to test all the ways it can be completed.)

In Step 3 of the use case above, a user could decide not to complete the form. To explain how to deal with this, I added a simple exception to the use case.

The final version looked like this:

Submit a Recommendation

Step 1.	User clicks the Write a Recommendation link, and a short form displays immediately beneath the button. Tech note: This form resides in a hidden DIV and loads with the rest of the page. The button toggles to read Close instead of Write a Recommendation.
Step 2.	User completes the form.
Step 3.	User clicks OK to submit the recommendation, and a success message displays above the form.
Step 4.	User clicks the Close button to close the form.

Exceptions

Step 3a.

User clicks the Close button without completing the form. Tech note: This resembles a "cancel" action, in which input data would be stripped from the form and the form is hidden, but since the DIV is simply toggled between hide and show states, the data is retained by default and can be displayed again if the user clicks Write a Recommendation a second time.

"3a" indicates that the exception applies to Step 3 in the use case. It means that if the user decides not to complete the form, another workflow begins, which is detailed in Step 3a. Simple as that. Use cases can get rather lengthy, of course, when detailing complicated or large sets of interactions, but each use case often ends up very similar to this example.

Typical use cases don't go into the details of what buttons appear where or anything else that specific, but I find it incredibly useful to add these details, because it gives graphic designers and developers a more exact idea of how the interaction should look and work. It also forces me to think through whether the interaction is technically possible, and how simple or complex it will really be when it's up and running. In this use case, I was able to find a way to consolidate two buttons into a single button with two purposes. (In the real version, I also included information about the form itselfhow the fields were labeled, how big they were, and all that jazzbut such details aren't important for this example.)

As you can see from the initial use case, I was making a big assumption about the interaction. I was assuming I could just throw up a simple form that would drop into place on demand and call it a day. And the developer who would eventually build the thing would have made other assumptionsfor example, that the form should have two buttons: one that opens the form and one that submits the data. He would have built exactly what I said to build, as he understood it, and the interaction would have turned out pretty badly.

Then, I would have written up a review of the interaction, explaining to the developer that it was all wrong, and he would have had to rework his code, rather substantially, to correct the interaction. And in my review, I might have left out another detail, and thus the process could have gone on for days, adding to the developer's growing frustration, increasing my stress level, and wasting many hours of expensive and valuable programming time.

By taking 20 minutes to write an effective use case at the start, I avoided most of the pitfalls.

The rather obvious secret is this: It's far easier to change a sentence in a Word document than it is to rewrite code that runs conditional logic to perform a specific operation in an interactive system (what a mouthful!).

It takes much less time to write a use case than it does to create an interaction in HTML, with the JavaScript and CSS needed to make it all work. And more often than not, a use case is all you need to explain to another personlike a developerhow a task will be completed in an application.

Get the picture? Use cases rock.

Applying kaizen to use cases

Before we discuss the arguments against use cases, I'd like to share some quick, practical advice about how to make them as effective as possible:

Programmers often enjoy the task of "refactoring" their code to make it cleaner, run better, and contain less bugs. I'm a former programmer myself, so I may be a bit biased, but I enjoy making similar improvements to use cases (as in the example above).

Whenever I write use cases, I like to apply a little kaizen to the process. Kaizen is Japanese for "change for the better," or, more simply, "improvement." It was originally used as a management technique (it is credited as the reason Toyota consistently builds high-quality, long-lasting vehicles and can justify higher costs as a result), but I find kaizen can be applied to just about anything.

For every interaction I spell out with a use case, I go back over it several times, each time trying to find a way to make it smoother, faster, easiermore obvious. It doesn't matter whether the use case ends up changing at all. What matters is that time is spent trying to improve it. Any little detail that can be modified to improve the intuitiveness of the interaction is fantastic, but not every "improvement" is really an improvement.

For example, in the use case about submitting product recommendations, one thing I could do to make the activity easier to complete is to simply show the form by default instead of hiding it away until the user clicks the Write a Recommendation link. This translates to at least one less click for every user who decides to submit a product recommendation. Easier, no?

The downside is that the form would be displayed all the time, cluttering up the page for the 98 percent of people who will never use it. This translates to a more cluttered page every single time it's viewed. No, not easier.

However, one improvement I could make is to have the form "remember" (via a JavaScript cookie) the user's name and email address the next time she writes a recommendation, so she only has to enter the information once. This feature wouldn't be apparent the first time she used the form, but repeat submissions would enable her to complete the form more quickly.

Another improvement would be to auto-focus the first empty input field. If the user's name and email address are retained from previous visits, those fields will already be filled out when the user accesses the form again, so the first empty field would be the one in which she would write the actual product recommendation. If I created the form so that the cursor went immediately to that field, she could click Write a Recommendation and begin typing without having to click in the field first.

This would be a definite improvement. I wish I'd thought of it before I sent the use case to the developer.

Kaizen is a simple concept that can produce great results. Remembering the user's name and email address is a tiny detail, but it makes completing the form a breeze. Users may not even realize the form works this way, but as they see how easy it is to write a recommendation, they will be prone to do it more often.

Funny. That's exactly what you want users to do. See how well that works?

In case you missed the point: Improving usability means improving the chances users will do what you want them to do. A little kaizen can take you a long way.

The argument against use cases

Some people dispute the merits of doing anything that doesn't directly contribute to the final product. They say it's bad to spend your time on anything but code. Instead of learning about your users, design products for which you are the target audience. Instead of creating wireframes (which I'll talk about in Chapter 4), create a sketch and go straight to HTML.

This approach has its merits, but many of us work in environments that simply don't fit with this style of development. My job, for example, is to design interfaces for and perform heuristic evaluations on several major applications, none of which are targeted at someone like me. Different development teams are in charge of building and maintaining each one. There are far too many interfaces, interactions, task flows, and applications to deal with to go straight to code, and it would be difficult to maintain a sense of consistency between the applications without the support of a large design team.

Again, use whatever design and development process you like, but give use cases a whirl before writing them off. You'll likely find they're a fast, cheap, and easy way to get all those fuzzy ideas on paper and start seeing the possibilities and problems.

My advice

My advice is this: Learn as much as you can about users in generalnot necessarily the user base specific to your applicationsso you know how they use Web-based products, but then focus on the activity your application is meant to support and design for that.

To design anything well for the Web, you have to know how people work with it, but as long as you have an ongoing, general understanding of users, designing for the activity enables you to develop and maintain a vision for your product and avoid bending to the whims of users. (More about this in the next chapter.)

If understanding the activity your application supports means talking to people about the activity and how they perform it, the approaches outlined in this chapter will help you do that. So, in addition to gaining a general understanding of Web users, you can gain an understanding of any activity that can be supported by a well-designed Web application. Armed with this knowledge, you're well on your way to designing the obvious. The rest of the work is figuring out how you implement interfaces that support the qualities of great Web-based software, and I'll spend the rest of this book talking about how to bring those details to life.