The financial planning site/application Wesabe failed because they didn’t understand how to use scenarios effectively. You can avoid that mistake by realizing that UX scenarios are about life, not about optimizing the human/computer interface.
Wesabe was a financial management website/application that didn’t succeed. Instead, it lost out to Mint (which, by the way, was eventually bought by Intuit for $170 million). Wesabe’s founder, Marc Hedlund wrote in a blog post that there were really two reasons Wesabe failed and one was “I was focused on trying to make the usability of editing data as easy and functional as it could be; Mint was focused on making it so you never had to do that at all.”
Notice the critical issue here: It didn’t matter how good Wesabe got at usability — the company was fundamentally working on the wrong thing. Wesabe didn’t understand how to use its user’s scenarios and, as a result, they started on the wrong path before they wrote their first line of code. (If you’re interested, the other problem was failing either to partner up with a specific data provider or to have a strategy in place if one of their competitors did…and Mint did).
A scenario (also called user stories or user journeys) is a description of your users’ real life, created after you decide who your users are. A scenario allows you to understand your user’s experience in the real world. A scenario is not the description of the button clicks or the interactions a user has with your application (that’s called an “interaction script” and is created much later in the UX design process). In fact, a scenario is only distantly concerned with the user’s interactions with the application. Instead, a scenario is primarily interested in everything going on in the user’s life while working with your application. A scenario is a story, a “slice of life” that describes the real world where a user interacts with your application. Focusing on button clicks and mouse movements will lead you, inevitably, to trying to optimize those activities when that may be exactly the wrong thing to do.
If you think about a scenario as an expression of your user’s life then there are two major takeaways for you. First: There are things in your life that you want to get rid off. As in the Wesabe/Mint story, you want to eliminate those activities (and only if you can’t eliminate them should you try to optimize them). Second: There are also things in your life that you want to do more of. Those are are things you want to enhance in your UX, rather than optimize or eliminate.
Here’s a scenario we use in Learning Tree’s User Experience Design course as part of one of the course’s case studies:
If you’re focused on making this scenario more efficient then you’re missing the point. If you look at the scenario, planning the vacation is not a burden for Martha. Instead it’s something she:
Most importantly, this task is not something that Martha has to spend time on — as the last line indicates, it’s something she can spend time on. For this user, rather than making the UX more efficient, you want to enrich the UX and make it more immersive.
Here’s another vacation planning scenario, this time for a busy, upwardly-mobile business executive:
This user is not doing something he enjoys. Instead, he’s trying to shoehorn a required (and, perhaps, unpleasant) activity in between his work activities. In the first scenario, vacation planning for was an enjoyable activity all by itself. For this user, vacation planning is a necessary evil and a means to the real end – going on vacation. This scenario does call for optimization or — even better — the elimination of tasks.
In UX design, there’s a reason that scenario analysis/design occurs early in the process. While scenarios have much to tell you about how you should craft your user experience they have something more important to tell you about your users – how your application should fit into your users’ lives. You should listen to them carefully.