Using Scenario-Based Design to Stay User-Centered

Be forewarned. I wrote this newsletter feeling a bit snarky after the event I’m about to describe.

Flame on.

Developers produce use cases. Use cases are “a list of actions or event steps, typically defining the interactions between a role (known in the Unified Modeling Language as an actor) and a system, to achieve a goal” (Wikipedia). Designers produce scenarios. Scenarios describe the goal of the user independent of a specific solution or implementation. These seem to be similar but have a fundamental difference. The focus of use cases is on the system and the focus of a scenario is on the user. When we lose the user focus, odd things can happen to our designs.

I’m going to make a bold claim: few people seem to be doing scenario-based design. I make that claim without direct evidence, but I do have plenty of circumstantial evidence to support my claim. Here is just one example. And I’m sorry but, in this case, I’m going to go ahead and use the name of the company to emphasize that this is not Fred’s Flower Shop and Tire Center. This is a large company with, we can only hope, sufficient resources to do design properly.

My wife and I were headed to Target the other day. We have one of their Red Cards that allows us a discount if we use it in the store. In preparing for the trip, my wife looked for her Red Card and discovered that she couldn’t find it. She used it a few days earlier but couldn’t find it now. We looked everywhere for it and finally decided she must have lost it. It is protected by a passcode, so that was not the concern, but it is still a problem and we wanted to report it as lost. We called Target’s toll-free number to report the lost card — a common feature provided by (I hope) every company that issues credit, debit, or store cards.

Sure enough, Target’s interactive voice response system (IVR) gave us the option of reporting a card as “lost or stolen.” However, to get into the IVR to report the card lost or stolen, it asked us to enter a Red card number. This posed something of a problem since we lost the card. There was no option to bypass the IVR system and speak to an operator to give them other information to identify us and our card. Waiting for the system to timeout didn’t direct us to an operator either. Luckily for us, we have two cards (Target uses different numbers for each card), so we decided to use the second card to get into the system and report that the first card was lost.

We hung up, located the second card, and used it to access the IVR system. When we got in, the IVR system told us that the second card, the one we had just used to access the system, had now been canceled. Yes, the card we had in our hands was now canceled and the card that we lost was still active. However, we now had the option to speak to an operator.

We explained the situation to the operator — that their IVR system wouldn’t let us in unless we gave it a card number, even though we told the system we were calling to report a lost or stolen card. Then, rather than detecting that we had two cards and asking us which one to cancel, it canceled the card we used to get into the system and left the lost card still open. She said she would be happy to cancel the lost card. However, she told us the system had automatically canceled the card in our hands and there was no way to reactivate it. At this point, we were in the position of having no active cards to use on the current trip to Target.

Was this some sort of built-in IT system penalty for being so irresponsible for losing one of their store cards?

Was this some sneaky way of making sure we didn’t get our five percent discount for some period of time?

Was this a purposeful penalty for not writing down our card number and keeping it handy?

Or was this yet another case of a project team failing to do scenario-based design to avoid putting its customers in this kind of situation?

This design does not make sense from the user’s perspective. However, this design might make sense if you are trying to automate everything and lose sight of the user’s perspective.

I think it is inexcusable for a company of this size to fail to properly support the two conditions described above — losing a card or losing one of two or more cards and not having the lost card number handy to access their system. Granted it is difficult to come up with the proper set of scenarios for a good scenario-based design, but developing software use cases is not the equivalent of scenario-based design. In a proper user-centered design process, design and development are separate activities; scenarios are developed first, and use cases are added to support the scenarios. A scenario, focused on the user, would have been unlikely to lead to the design that has an IVR system require the user to know their card number to report a card as lost or stolen.

Flame off.