UX Strategy Musings from Will Tschumy, Microsoft User Experience Advisor

UX Strategy header image 2

When products attack -or- How bad design makes your users loose sleep

June 3rd, 2011 by Will Tschumy

иконографияКартинимека мебел

I’ll admit it: I’m grumpy right now. 

Why, you might ask? This morning, as I was snoozing blissfully way at 3:30a or so, one of the smoke detectors in my house decided it was low on batteries. <CHIRP>.

Why is always seems to happen in the nether-hours of the evening is another topic, but through the frustration of this experience, it got me thinking about design principles.

Some key elements of the design failure:

  1. The only way that the smoke alarm shows it’s running low on batteries is by making a “chirp” sound
  2. The interval between the chirps in random, though it does seem to come in bunches
  3. The tone and duration of the chirp makes it difficult for me to locate it.  Locating the offending smoke detector is made substantially more difficult by 2
  4. You can check to make sure the smoke detector is working, but you can’t check the battery level

So what happens when the low-bat chirp goes off? You stumble around your house, in my case muttering ‘colorful metaphors.’  The muttering and stumbling is punctuated by standing silent and motionless, waiting for the next chirp, so you can run towards where you think it is.  Depending on how dark it is, you may also do this.

Because the interval between chirps is seemingly random, you give up looking.  Inevitably, just as you crawl back into bed, the next set of chirps starts. 

All in all a terrible situation.

The thing about it, however, is that’s it’s more than just severely annoying and sleep depriving: it’s dangerous and it’s as a result of the context of the user not being taken into account.

Why is it dangerous?  The current design drives users towards two likely outcomes:

  • Pulling down all the smoke detectors down and pulling the batteries
  • Never putting them up in the first place

Given that most people will prioritize a near-term, tangible pain over future potential catastrophe, the most likely outcome of this design decision is to pull all the smoke detectors you have.  Insert obvious irony comment.  The funniest thing about this: I’ve spoken with 5 separate people about my experience last night while writing this post – each as just taken down all their smoke detectors because of similar experiences.

So how could it be different?

First, the goal should be to allow the user to prevent being annoyed by a low-battery signal.  More than that, it’s better from a safety perspective to never be in a low-battery situation.  So how might this be accomplished?

  • First, give me a visual indicator a week before it’s going to start chirping.  Also, make the test button display the battery strength
  • Give me a visual indicator when the battery is critically low.  Is a flashing red LED too much to ask for?  This will make a huge difference when trying to find the damn thing
  • Make sure the chrip has a predictable interval, and make that interval less than a minute.  If this is the only way to find the smoke detector that’s failing, MAKE IT EASY TO FIND
  • Make the smoke detector respond / answer back when it’s in low battery mode – it chirps when you clap, or some such thing

Now I’m off to go buy more batteries and hopefully better designed smoke detectors!

Related Posts:
-  See Will Here: TiE Panel discussion on July 26th, 6-9pm Santa Clara, CA
-  Great Post from Cynergy, A RIA-focused UX agency
-  Intro to Metro, the design language of Windows Phone 7
-  Hear Will Here
-  Come to MIX08 – see the sights, follow the UX track, take in a panel

Tags:   · No Comments