What's the use of use cases? Oh, I can think of a few.
Say that you're creating a website for a client that sells pony dolls made from corn plastic. On the site, there are games for kids to play, and if the kids log in, they'll be able to save their high scores, post messages regarding their favorite dolls, create a public user profile, and other features that have yet to be dreamed up by your team. You've been tasked with designing the screens required for registering users for accounts on the site.
Sounds pretty simple, right? This is where designers usually can't restrain themselves from diving right into sketching and ideation and Photoshop and luxurious comps. Next thing you know, the client approves the designs, the project moves into development—and lo and behold, there are a few corner cases you hadn't acknowledged. A few whiteboard sessions later, a long discussion or two with the client, and those corner cases are starting to loom large over the entire design that is now been un-approved and is in the midst of rapid redo.
Even worse, the client is on the hook for making some major changes to their company's business process because those details weren't thought through in the design phase and implemented in a usable fashion.
Oops. Looks like you should have run some use cases, and right from the start.
Critical information always lies buried within the details of use cases. If that information isn't triaged and surfaced properly to the client and your developer, you can totally bollix a big project.
Use cases aren't just critical for describing—to quote Wikipedia—"the system from the user's point of view." (Their article on writing use cases is fairly good, I encourage everyone who's never written a use case to read it.) Use cases can serve as a baseline for what business activities, actions, or experiences need to unfold in tandem with the desired user interaction goals. They also serve as a method of validating how your ideal audience will perform critical activities and whether those activities will be even be worth participating in on the part of the user. After development is stable and you begin to test the system, you can then walk through your use cases and make sure that your use cases have been rendered properly.
So, it would be fair to say that sitting down and spending the time necessary to write up use cases for critical tasks across any large, complex web design project will reap you great reward.
And by the way, the example that I provided at the start of this post is more like a trojan horse than a stuffed pony. Here's why...
Before you write use cases, you need to know who your actors are. Even if you've been running your project without discrete descriptions of your imagined user segments, having even rough personas can really help clarify what needs to happen over the course of a critical activity on your website—and based on their age and geography, the legal requirements regarding their interaction with your website.
Hence, the challenge of allowing children to create user accounts on websites. There are very strict laws around how children can log into and use a website, and how that website can display said information.
Will parents be using the site with their children? Are the children below the age of 13? Probably a wide range of parents and children will be interested in your site, so based on your selected actors, you need to know (within the bounds of the COPPA laws) what the impact will be of presenting certain features as a part of your ideal website experience. Ideally, you're determining this before you write up the complete use case.
There's another missing ingredient before the use case can be made complete: the user goal. Why does this child want to create an account? What's their motivation beyond simply fulfilling the discrete task? If you think about this task in the process of a larger-order activity—such as accepting a reward or receiving an special benefit—those nuances can add context to your use case that creates better context for choke points in the process. (In this case, having to provide a parent's email and then find them to approve the creation of your account.)
When you write the use case, you need to express what's best for the user while also being mindful of what is sustained by your client's business process. This is when, in writing use cases, features fly out the window due to impossible constraints on the client for data management. In the example I'd noted above, when dealing in creating sites for children, the law may enforce certain business requirements for managing data. Any input provided by users may need to be scrubbed and reviewed by a client representative before it can be made public. (This is why many children's sites provide canned messaging that kids choose from a pre-approved list.)
Some designers prefer to create user scenarios instead of use cases. These kinds of deliverables tell the story of a user fulfilling an activity in storyboard fashion.
Scenarios are fantastic for sketching out a vision of how a website, app, or product will function in the hands of a user. But it is a weak substitute for exploring the craggy complexity of any substantive user task, and fairly useless as documentation for hardcore development. I've worked on sites and apps where legal necessities required ultra-long use cases to tease out the logic required for a primary task. And when things get that complicated, you're probably going to do a user flowchart of some form to clarify just what needs to happen across login states. (Ideally rewriting them a few times, a.k.a. applying kaizen per Robert J. Hoekman, Jr. in his lovely books.) Doing six or even ten frames of a storyboard just won't begin to cover it.
Comments