Scenarios Are More Than Use Cases

It’s not uncommon for a designer to join a project in which “the use cases are already written.” This documentation attempts to describe in words how a user will complete a particular task within the system.

Scenarios take this further and include the context around the action to form a complete story of a person in the real world using the product to create a positive outcome. In the example shown here (Square’s credit card reader), I’ve intentionally de-emphasized the steps around charging the card to highlight the surrounding context. Reviewing the full story helps the team identify additional functionality the product needs to serve this customer:

• The charge needs to be authorized in less than 5 seconds. (Count it out and imagine being the buyer, waiting and drumming your fingers.)

• The seller needs an easy way to cancel or refund the charge. (Someone will hit the wrong button in the chaos of the trade show floor.)

• A simple way to keep/decrement inventory would be a value-add for the seller.

Imagine if this team stopped at simply “meeting the requirement” that the seller swipe the card and the buyer signs with their finger. That notion is abstract beyond the point of helping the team know if they can serve this customer. Instead ask how your product will help a specific person get through a specific situation.

No More Cheesy Scenarios

Since anyone can understand a story, designers often use scenarios to explain how a user would complete a task or accomplish a goal in a given system. These short stories can be written in words, and are sometimes paired with quick sketches to make a storyboard.

I happened to be working through a lot of design scenarios recently, and these guidelines from Dan Saffer have proven extremely valuable:

• Remove all adverbs

• Remove all interior monologue

• Remove any adjectives that don’t relate to system feedback

Here’s what happens when you don’t do that:

Susan stayed up late working on her personal newsletter. My subscribers are counting on my insights and links! she fretted.

— Dan Saffer (@odannyboy) April 29, 2014

These elements make the story sound cheesy, which effectively makes it seem less truthful. Your audience will smell the B.S. and your credibility as the storyteller will be undermined. The perceived quality of the design idea also goes down.

Few of us are great writers; I’ve found it surprisingly easy to fall into that familiar rhythm. But unless you want to be lumped in with the ShamWow—which has “sham” right in the name—don’t write a pitch that sounds like a late-night infomercial.

I remember one story that felt dry when I first removed the cheese, but the audience didn’t notice. And even the driest story about a user accomplishing a task will serve you better than something reminiscent of Saved by the Bell.

Once the cheese is gone, run through your story a few times with a colleague to smoke out the “plot holes.” You’ve been focusing on the design idea itself, not the presentation, and there will probably be one or two places where the audience feels like you jumped from Point A to Point C. The practice run is a simple idea, but it has a great bang for your buck.

After you’ve mastered the basics, Dan suggests the following:

• Add problems and resolutions

• Remove anything that sounds like ad copy

• Vary user behavior

This is great advice, though instead of writing more/deeper scenarios, I usually put the time into storyboarding a rock-solid happy path scenario that I’m 100% sure my audience will understand. People can’t get on board with a plan they don’t understand, and you are presenting new ideas they may not “get” right away. Adding visuals is a great way to build understanding, and trading words for pictures makes it less likely you’ll write cheesy copy.

Thanks to Dan Saffer, Kevin Cheng and Dan Roam for improving my stories.

What Is a Requirement?

What is a requirement? How would you define it? Is it…

• a need that a customer has?

• something a key stakeholder wants?

• a raw idea from someone on the team?

• a detailed description of how something should be built?

• a specific solution someone has in mind?

It’s all of those, and none of those. Since a “requirement” can’t be defined in any useful way, we can’t point to something and say, “yep, that’s a requirement.” How many years has the technology industry been building things without a clear, shared definition of this word?

Let’s say you’ve “captured” a requirement or “gathered” it and you’re holding it in your hand, staring at it. What exactly are you looking at? It’s a bunch of words that fell out of someone’s mouth. That’s it.

What do you do with all these words? If you’ve got a big list full of them, how do you move forward? Well, I recommend you print them all out, bundle the pages together, and feed the pages to a goat. That way, at least the goat gets something out of it. Then, go figure out what would actually help your customers.

Credit: Jake Fleming

But I Already Know What It Needs To Do

Let’s say you’re not going into uncharted territory and you already have a good idea about what the product needs to do. OK, that’s cool. Gather your team together and tell them a story of a better tomorrow in which your customer is the hero and they’re succeeding at something using your product.

Kevin, who works the counter at the coffee shop, can take a credit card payment much faster using the new point of sale system. Finally he can focus on making the best espresso possible.

This is what we (and others) call a scenario. It’s a plausible story about a customer using your product in the future to create a positive outcome. Here’s another one:

Kevin moves quickly and sometimes makes a mistake with the register. Fortunately, it’s easy to void a charge and refund money to a patron’s credit card.

The two scenarios above could be grouped together under a capability called Accepting Credit Card Payments. After all, it’s not feasible for the coffee shop to advertise that they take credit cards unless they can both charge them and process refunds. Continue by listing all the scenarios you plan to enable in this release of the product.

Once you group your scenarios into capabilities, it’s usually pretty clear which capabilities need to ship first. The key is to not deliver a feature until your customer can walk through all the scenarios under the same capability. Put dates next to each of the capabilities and you’ve got yourself a release schedule. Congratulations! Your engineers can get started.

Epilogue

Tony Ulwick’s insightful book What Customers Want helped me realize requirements don’t exist. He advocates an even more rigorous method of determining a product’s feature set against a set of quantified outcomes (e.g. “Clerks can ring up patrons 50% faster with our new point of sale system”).

Check it out if you want to dive deeper.