Using Interaction Design to Identify Alternate Scenarios

In his book Writing Effective Use Cases, Alistair Cockburn writes

Write down what the system detects, not just what happened. Don’t write “Customer forgets PIN.” The system can’t detect that they forgot their PIN. Perhaps they walked away, had a heart attack, or are busy quieting a crying baby. What does the system detect in this case? Inaction, which really means it detects that a time limit was exceeded. Write “Time limit exceeded waiting for PIN to be entered,” or “PIN entry time-out.” ^[6.]

This is absolutely correct for when we’re writing a “normal” software use case. But how do we identify that there needs to be a PIN entry time-out in the first place? This is a prime example of how interaction design can be used as a means of identifying use case scenarios and failure conditions.

We want to end up with a use case scenario that describes what the system detects (“PIN entry time-out”), not what’s happening externally (“user quieting a crying baby”). However, to get there, we can use personas, various UI diagrams, and interaction scenarios. The interaction scenarios absolutely would include things like “user quieting a crying baby,” because we’re interested in describing the user’s world (i.e., what’s going on around the user while he’s using the system). This gives us a useful perspective on how the user is really going to be interacting with our product. It’s also a good way of identifying alternate scenarios and failure modes we might otherwise have missed.

Recall the process shown in Figure 10-1. We start by writing lots of interaction scenarios for our target persona (possibly identifying new personas in the process). Once we have a decent set of scenarios, we can begin to extract the more abstract use cases from these scenarios. The purpose now is to lose all the “external” descriptions that have been so useful up until this moment for driving the UI design but that would only clutter the finished use case text.

This approach is the reverse of what you’d normally expect—that is, we’d usually start by identifying the use cases, and then break these down into more concrete scenarios. Instead, we’re starting by identifying the concrete (personas and scenarios) and using them to identify the abstract (actors and use cases).

In practice, it’s beneficial to combine these approaches. A brainstorming session in which the team identifies both scenarios and use cases (having first settled on one or two personas) can produce a thorough analysis of the application that we’re about to design. Product design at these early stages of development is an organic process, and you don’t strictly complete one activity before moving on to the next. Instead, one activity feeds incrementally into the other, and vice versa.

^[6.]Alistair Cockburn, Writing Effective Use Cases (New York: Addison-Wesley, 2000), (New York: Addison-Wesley, 2000).