« Something Unusual I Noticed | Main | Servers by the Yard »
February 14, 2006
The Scenario-ator's Dilemma
The book The Innovator's Dilemma is about a problem that can affect companies that take what is normally a good approach to product design: listening to their customers. The issue is that the customers will tend to ask for more bells and whistles on existing products--leading them "upmarket" in the terminology of the book--and this can lead to a more expensive, more feature-laden product that is prone to be replaced by something simple (or "downmarket") that is "good enough".End intro, begin main topic: I'm wondering if Microsoft may be leading itself into a different, but related trap. The current best practices for product design at Microsoft lean heavily on scenarios. Instead of designing features as such, we try to identify a customer scenario, and then figure out what features are needed to meet it. The idea is to avoid a) important customer scenarios that a product doesn't address and b) spending time on features that nobody will use.
Those are worthy goals, and scenarios certainly help. In fact part of the reason for focusing on scenarios is to prevent the Innovator's Dilemma. Customers, when asked what they want in products, will often spout out features that they think will address a problem that they have, without thinking about whether it is the best way to address it. Forcing the customer to state the problem--the scenario--produces a more objective response and allows you to synthesize the scenarios into the set of features needed.
So what is wrong? Well, consider the following imagined exchange between a Cool Idea Person (CIP) and a Scenario Enforcer (SE) in, say, early 2000.
CIP: Hey, I think we should do a portable media player.
SE: OK, tell me about it.
CIP: Well, I think it should have some extras like a contact list.
SE: Hmm, the scenario is playing music, right? Why would they need contacts?
CIP: I don't know, it just might be useful for someone and it's just some extra software.
SE: Well, we don't want features that are hunting for a scenario. Cut the contact list.
CIP: Fine. Next, I think it should have just four buttons and a wheel for scrolling.
SE: Only four buttons? What if the user wants to skip a song vs. fast-forwarding within a song? Those are separate scenarios.
CIP: I see, but the four-button design looks kinda cool, and we can use the same button for two things.
SE: Cool is nice, but we have our scenarios to hit. We need at least 10 buttons.
CIP: Well, I suppose. Anyway, the last proposal is that we make the edges round.
SE: Make the edges round? What's the scenario for that?
CIP: There's no scenario for that! But it looks really great in the mockups we did. In our focus groups the round edges really got people jazzed about the unit.
SE: Listen up ace, the music sounds the same, right? I don't care about the edges being round...round like an O...which is the last letter in scenario...which you don't have one of.
CIP: <sighs>
So this is the problem with basing it all on scenarios. You try to design a portable music player using scenarios and you get...well you get something more like a Windows player than an iPod (discounting the Windows players that just imitate an iPod). Designing things around scenarios gets you a soulless, workmanlike product that does what it needs to do. But it doesn't get you something that delights a customer. And that's what were supposed to be doing, per SteveB: delighting our customers. Hit their scenarios, but then do that one extra thing, or do it in a more elegant way, or something, so they sit up and say, "Wow, this is great."
Remember at one of the iMac launches where Steve Jobs looked at one and said, "Don't you just want to lick it?" In fact I talked about this in one of my very first blog posts, talking about "preciously seducing" technology (and even used the same Steve Jobs quote, although searching around he may have said it about Mac OS X, not the iMac, or not said it at all). Designing by scenarios doesn't get you the products that people want to lick, because there's no scenario for someone licking them.
Posted by AdamBa at February 14, 2006 09:15 PM
Trackback Pings
TrackBack URL for this entry:
http://proudlyserving.com/cgi-bin/mt-tb.cgi/400
Comments
It strikes me that scenario-driven development expects the purchaser to be entirely rational and logical. In practice, _especially_ for impulsive or lifestyle purchases, the purchaser is anything but rational or logical. Or, at least, not entirely so.
For very expensive business products like Exchange or SQL Server, the scenario approach is perfectly appropriate. Windows is in a tricky position given that it caters to both business and home users.
Posted by: Mike Dimmick at February 15, 2006 01:13 PM
Actually, I agree with SE on the first point in the above scenario. Why do you need or want a contacts list on an MP3 player?
Posted by: Steve at February 16, 2006 04:43 AM
Would be cool if people on our design teams all read stuff like Don Norman...perhaps that would help a bit?
Posted by: anonymous at February 16, 2006 11:16 AM
Steve: for most users you don't need it. But the few who do will be "delighted" by finding it there, and so they'll get a warm fuzzy feeling about your company. This is what Apple manages to do repeatedly.
- adam
Posted by: Adam Barr at February 16, 2006 02:04 PM
