Need someone to lead product management at your software company? I create software for people that create software and I'm looking for my next opportunity. Check out my resume and get in touch.

Alarm usability

Freshness Warning
This blog post is over 20 years old. It's possible that the information you read below isn't current and the links no longer work.

I have a new alarm clock. The old one was fine, but a little ugly, so we bought a sleek black clock radio. Yesterday I turned the volume of the radio down to a whisper and didn’t turn it back up before going to bed that night. This morning I awoke to a faint beeping sound and realized that I’d overslept. After a moment of wondering how I slept through the alarm and what that quiet little beeping was, I realized the beeping was the alarm.

The volume knob not only controls the radio’s volume, but the alarm’s volume as well. I’d turned the alarm down so low I could barely hear it. That’s not something I’d expect, and it’s not how the alarms I’ve used in the past have worked. This is probably the result of some engineer or manager deciding that the alarm volume should be configurable and that the existing UI should be used to configure it.

When you are creating a UI, stop looking for things to add to it. Don’t try and find more things to let the user configure. Every single configurable option is a choice the user has to make. It’s something that can be misconfigured and cause user confusion.

Often the option you are letting the user configure has a setting that is clearly best. Other times there is little difference at all to the settings. In those cases, pick an option and hard code it. Reduce the number of choices your users must make and your application will be better for it.

July 17, 2003 10:18 PM

Our old alarm worked very well - the TV. Even if the volume was all the way down, the noise of the tube warming up and the raised brightness level in the room woke us. Now, of course, we have a different alarm system entirely - a baby. Oh how I long for some configuration options...

Torgny Bjers
July 19, 2003 3:45 PM

Aiee, Adam, I've never known a different alarm clock than those that have the radio and alarm volumes synchronized. I'm so used to it, and besides, I never use the radio in it anyway... :)

Matt Montag
June 8, 2006 2:25 PM

Your alarm clock issues seem arbitrary after reading Torgny's comment: he has illustrated you were merely trained by an alarm clock that worked the opposite way!

David Boland
November 8, 2006 10:11 AM

This was an old post but my wife recently went through a few alarm clocks. One that she liked at first (a Philips) was nice and sleek too, and had features such as wake to CD, and slow ramp up alarm volume. But all the buttons were identical looking, you had to use the reflection off the inprinted plastic words on the buttons to read them and they were all next to each other all around the CD lid. That clock was a nightmare! "Did I just hit snooze or alarm 24hr reset?" I offered to program her an alarm clock on for the notebook computer. I could reprogram features and functions infinitely as she had whims, sync to yahoo calendar or her Palm, automatic M-F, etc. I would've thought the notebook to be ideal but she didn't like that idea, she wanted a physical clock to push or hit in the morning. (Strangely her wish list included ability to play MP3's, change colors, change brightness, etc...). Anyway about the volume feature, I've always wondered why clocks that have the sleep function volume tied to the waking alarm volume? Doesn't make sense to me. The sleep volume should have quiet volumes as you lull off to slumber and the alarm volume should be fairly loud. The Philips (overly complex, hidden button) clock did have two volumes, one for sleep, one for alarm. I guess that was it's only good feature, but not enough to keep it around.

This discussion has been closed.

Recently Written

Mastery doesn’t come from perfect planning (Dec 21)
In a ceramics class, one group focused on a single perfect dish, while another made many with no quality focus. The result? A lesson in the value of practice over perfection.
The Dark Side of Input Metrics (Nov 27)
Using input metrics in the wrong way can cause unexpected behaviors, stifled creativity, and micromanagement.
Reframe How You Think About Users of your Internal Platform (Nov 13)
Changing from "Customers" to "Partners" will give you a better perspective on internal product development.
Measuring Feature success (Oct 17)
You're building features to solve problems. If you don't know what success looks like, how did you decide on that feature at all?
How I use OKRs (Oct 13)
A description of how I use OKRs to guide a team, written so I can send to future teams.
Build the whole product (Oct 6)
Your code is only part of the product
Input metrics lead to outcomes (Sep 1)
An easy to understand example of using input metrics to track progress toward an outcome.
Lagging Outcomes (Aug 22)
Long-term things often end up off a team's goals because they can't see how to define measurable outcomes for them. Here's how to solve that.


What I'm Reading


Adam Kalsey

+1 916 600 2497


Public Key

© 1999-2024 Adam Kalsey.