Designing the Obvious, Part 4: Use Cases, Screenflows, and Wireframes
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Part 3 of this series talked about why and how to perform research on the people who will use your web products, in order to understand how they use the interfaces you produce. Once the preliminary research is done, it’s time for the really fun part. (Of course, user research can also be a lot of fun if you’re one of those rare geeks who enjoys talking to other people.) It’s time to come up with some designs. Part of this phase involves some writing, though, so don’t get your pencil out just yet.
Writing Use Cases
You may have heard the term use case thrown around in your office; if you’re a programmer, you probably even understand what it means. If you’re on the design side of things, you may be more familiar with the term scenario, used to refer to a description of an actual usage scenario for a piece of an application. Both use case and scenario really mean the same thing. Use cases can vary in detail from a vague description of a task to a step-by-step explanation of every last detail of the behavior of your new scratch-and-sniff greeting card tool. Whatever the case, it’s important to know why writing down these blurbs is so valuable.
This may sound a bit sick, but writing use cases is one of my favorite things to do. In somewhere between 5 and 30 minutes, typically, I can list the exact process for how an interaction will work once it’s built. This exercise invariably surfaces potential problems and really brings to light the assumptions I was making about a task prior to writing it out.
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:
Submit a Recommendation
- User clicks "Write a recommendation" and a short form displays beneath the button.
- User completes the form.
- 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, that could look kind of awkward, and the user would have no idea whether the recommendation was submitted successfully." 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 that the submission was successful.
At that point, I realized that there would have to be a way to "close" the form once it the user was done with it. So now the use case has a fourth step, in which the user clicks a Close button. But where does the Close button go? Should I make a new button and display it as part of the form? Nah—I’d rather make the "Write a recommendation" button a toggle. The "Write a recommendation" button can’t be used once the form is displayed, however, because it has nothing to display, so instead of disabling it and displaying another button for Close, 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.
Fitts’ Law tells me that this is a good thing to do, because the easiest thing to click on your whole computer screen is the pixel where your mouse pointer currently rests. If I combine the two buttons, I’ve enabled the user to open and close the form without moving the mouse (should the user decide not to complete the form, that is).
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). But what happens if the user doesn’t want to complete the form? Do I need a Cancel button? Not really, because the Close button would handle that functionality. So now I have a single button that has three purposes without any additional clutter, the form appears right in the page instead of sending the user to another page in a roundtrip process, and the whole interaction is "as simple as possible, but not simpler" (from a quote attributed to Albert Einstein).
Perfect. That’s my use case.
Wait.
The developer will want to know what happens if the user decides not to complete the form. To handle this issue, I added a quick exception to the use case. The final version looked like this:
Submit a Recommendation
- User clicks "Write a recommendation," and a short form displays beneath the button. The button toggles to say Close instead of "Write a recommendation."
- User completes the form.
- User clicks OK to submit the recommendation, and a success message appears above the form.
- User clicks Close to close the form.
Exceptions
3a User clicks Close, without completing the form.
The designation 3a indicates that the exception applies to step 3 in the use case. It means that if the user decides not to complete/submit the form, another workflow would take place, which is detailed in step 1 of exception 3a. Simple as that.
Use cases can get rather lengthy, of course, when detailing complicated interactions or a large set of interactions, but each use case will end up similar to this example.
Typical use cases don’t go into the details of which buttons appear where or anything that specific, but I find it incredibly useful to add these details—usually resulting in a perfectly acceptable spec, discussed later in this article—because the details give graphic designers and developers a more exact idea of how the interaction should look and work.
Adding details also forces me to think out 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, it enabled me to find a way to consolidate three possible buttons into a single button with three purposes. (In the real version, I included information on the form itself, such as how the fields were labeled, how big they were, and all that jazz, but such details weren’t important for this example.)
My initial use case was making a big assumption about the interaction: that I could just display a simple form that drops into place, and call it a day. The developer who eventually built the thing would have made other assumptions, such as the assumption that the form should have two buttons: one that opens the form and one that submits the data. Ty from the web team would have built exactly what I said to build, as he understood it, and the interaction would have been all wrong.
Once Ty was done, I would have written a review of the interaction, explaining to Ty that it was all wrong, and Ty would have had to rework his code (rather substantially) to make the interaction right. And I might have left out another detail in the review. This process could have gone on for days, adding to Ty’s already frustrating existence as a programmer, increasing my stress level, and wasting many hours of expensive and valuable programming time.
By writing an effective use case at the start, I’ve avoided most of the pitfalls, and I did it in twenty minutes. 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 performs a specific operation in an interactive system.
Get the picture? Write use cases before you write code. It’s the Law.