/dev/usability 16 Apr 2007 10:36 am
Learning to Prioritize Use Cases
iPods have this kind of neat feature where they will pause playback whenever headphones are unplugged if the iPod is not connected to a dock cable. Some possible use cases that brought us this feature are:
USE CASE: Jane accidentally drops her iPod and her headphones become disconnected; she is no longer listening to music.
USE CASE: Bob is driving and listening to his iPod, which is connected to his car stereo using an audio cable. When Bob arrives at the mall, he unplugs his audio cable so that he can take his iPod with him, but he doesn’t want to listen to music until he gets inside the mall.
Those are pretty common use cases, I’d guess. Pausing playback in both of those situations makes perfect sense. Here’s a use case where the feature doesn’t make sense:
USE CASE: Ben and the rest of his programming team are tired and are working on a Saturday. Ben, in a fit of either rage or insanity, starts listening to Jingle Cats on his iPod. He decides to share the Love, and unplugs his headphones so that he can plug in his speakers.
In this case, Ben still wanted to listen to music, so pausing didn’t make sense. But you know what? This is a low priority (uncommon) use case. The other two cases listed are high priority (extremely common), and it made sense for Apple to implement the feature. As for my broken use case? Apple COULD have solved the problem, but DIDN’T. Bad Apple? No, Very Good Apple. You see, they shipped on time, with a lot of features, and most users think the device suits their every need. You have to prioritize Use Cases when seeing what fits into your product’s schedule, otherwise you ship too many confusing features, late, over-budget, and you won’t even know that this is happening.





















on 18 Apr 2007 at 11:55 am 1.jack said …
I dropped my ipod the other day. Now the touch sensor doesn’t work.
on 18 Apr 2007 at 12:40 pm 2.bburbank said …
Common Use Case.