Dustin Coates in Vux

Solving Voice UX Problems: What's an Alarm?

You’re laying down for a nap at noon, and want to wake up in thirty minutes. How do you let your smart device know?

Ten minutes in, you realize you’re not getting any sleep, and no longer want that sound going off at 12:30. How do you let your smart device know?

Is an Alarm a Timer?

You might use the exact same wording when setting and when cancelling, but you’re just as likely to use different formulations. When you start, you might say, “set a timer for thirty minutes.” When you cancel, you might instead say, “cancel my alarm.” This seems to me to be two valid, semi-equivalent concepts. Try this, though, on one of the major voice-first platforms. I won’t say which platform, because that’s not the point here. This kind of response could happen on any platform, or in any voice application.

“If you’re trying to cancel an alarm, it doesn’t seem like you have any set at the moment.”

Well, of course. An alarm is for a specific time of day, and a timer is for a set amount of time. This one seems like user error. Except that you can say, “set a timer for twelve thirty p.m.” Does this command refer to an alarm or a timer? How about “wake me up in thirty minutes?”

The outcome of this over-reliance on preciseness is user unhappiness, and disillusionment. Disillusionment with the specific voice app, and with voice overall.

Once more, this isn’t a problem just with alarms and timers. Or even voice, really. This can happen anytime conversational devs and designers don’t come to the users, and require users to change instead. That’s a shame, because this is solvable. Let me tell you how.

Paging Roget

The most comprehensive approach to add some flexibility to voice apps is through the use for entity synonyms. Whether you’re using a voice search solution or one of the voice-first platforms, you have synonyms available to you. Most often, you’ll have a canonical value and alternative values, but you can also have settings where all of the values are essentially “canonical” and are of equal weighting.

This would solve our problem because we would make timer and alarm equivalent. “Set an alarm” and “set a timer” would mean the same thing, as would “cancel my alarm” or “cancel my timer.”

You could solve many conversational problems creatively through the wise use of synonyms. A video game store will have games for PC and for consoles. Among the console games, the store will have games for the Switch, Xbox, and PS4. The store’s voice app, then, should have a synonym that points one way: a user asking for “console games” will get games from any of the three platforms, while users asking for “Switch games” won’t see Xbox or PS4 games.

Of course, this only works if you assume that alarms and timers are equivalent and should reside in the same “bucket.” If you disagree, that’s fine, you can avoid synonyms. But you still need to care about those users who use the terms interchangeably.
No, but…

If synonyms are the “yes, and…” approach, this approach instead is “no, but…” “No, you can’t do that, but you can do this other, related item.”

The way it works is to take what users want to do, and divert them to another option. For alarms and timers, we could look at whether the user has the requested “type” already set. If so, great! Proceed. If not, see if the other type is set, and use that one instead. Here’s how it looks like in psuedocode:

if (user.has(requestedType)) {
  // perform action
} else if (user.has(oppositeType)) {
  return `You don't have any ${requestedType}, but I found one ${oppositeType}. Is this what you want?`;
} else {
  return `You don't have any ${requestedType} or ${oppositeType}.`;
}

But, you know, create better and more actionable responses.

Your goal is to prevent a situation where users want to do something, but can’t because your application wants to hold all of the power. By offering up an alternative (“You don’t have any alarms, but I found one timer.”), you are telling your users that you care enough to spend the time to anticipate their needs.

Remember: build your applications to be servants, not commanders. Through the use of synonyms or “no, but…” formulations, your application can facilitate your users to quick and successful goal achievement.