Inconvenient UX that Solves User Problems

A paradoxical UX that seems inconvenient at first glance, but actually isn't

This post is about Alarmy's "Sleep Mode."

Modifiers commonly placed before the term UI/UX are things like "easy to use" and "seamless"—adjectives that, if we had to categorize them, skew towards positive rather than negative. Conversely, when terms like "inconvenient to use" or "disjointed" are attached, it's easy to assume it's bad UI/UX. However, "inconvenience" or "friction" intentionally designed to solve a specific problem that users can't solve on their own can paradoxically be good UI/UX. This means that good UI/UX isn't ultimately about being easy and smooth, but must start from whether it solves the user's problem. Even if it seems inconvenient at first glance, it's not actually inconvenient at all.

Running apps don't stop immediately when you press the "stop" button mid-run. Instead, they pop up a dialog asking, "How about running just a little more?" and you have to press "stop" one more time for it to finally end. From the perspective of a breathless user in that moment, it's a seemingly annoying UX, but looking at the bigger picture, it's a thankful UX that helps them run a bit further and gradually improve their records.

The same goes for Alarmy. Users who can't wake up in the morning expect us to somehow get them out of bed. That's why Alarmy's alarms don't turn off easily. You have to get out of bed and walk or do squats, or go to the bathroom and take a picture of the sink. In fact, one of our most frequent user requests is "Please make it impossible to turn off the phone while the alarm is ringing," or "Please make it impossible to delete the app while the alarm is ringing." This too is a UX that looks very strange at first glance (Wait, the power won't turn off?), but it's a thankful UX that solves users' wake-up problems.

The Good Intentions of Sleep Mode

The purpose of the Sleep feature in Alarmy is to solve users' issues with falling asleep, ultimately leading to "sleeping well and waking up refreshed." Through user interviews and surveys, we initially narrowed down the problems to solve: "insomnia caused by anxiety and worry" and "insomnia caused by bad sleep onset habits." Then, to tackle "insomnia caused by anxiety and worry," which accounted for the largest portion, we launched sleep-inducing music (hereafter referred to as sleep sounds). The direction of the solution wasn't "let's eliminate anxiety and worry so they can sleep well," but rather "let's distract them from anxiety and worry for a moment so they can fall asleep easily."

At this point, we added a feature called "Sleep Mode" following the playback of sleep sounds. Unlike general music playback, the purpose of sleep sounds is "falling asleep," so this was to create an environment conducive to sleep immediately after hitting play. When you turn on Sleep Mode, the sound plays softly, the screen brightness dims, and the current time is displayed. This sets the context of focusing quietly on sleep itself, rather than getting distracted by other things. Sleep Mode wasn't mandatory for users; it was implemented so they could choose to use it based on their own needs.

Although we launched it with good intentions, the number of users using Sleep Mode was minuscule compared to those playing sleep sounds. Were the users experiencing trouble falling asleep actually sleeping fine without the Sleep Mode feature? Since there was no way to track actual sleep onset, it was hard to judge. So, we conservatively assumed they were still failing to solve their problem, and figured it might be a good idea to enforce the solution to some extent. We decided to be flexible: try it out, and if user pushback due to inconvenience was severe, we could just revert to the old version. Thus, the existing playback flow was changed to only allow a 60-second preview, and to listen to the whole track beyond 60 seconds, we changed the flow so that users had to turn on Sleep Mode no matter what.

The Results of Enforcing Sleep Mode's Good Intentions

Fortunately, the results were good.

Actually, it felt like we were finally solving their problems for real.

1) DAU Increased Around 7-8x (900 -> 7,000) !!

• The daily number of Sleep Mode users increased significantly. You might think, "Isn't that obvious since you forced it?" but a 7-8x jump is still a massive margin. Plus, the fact that it wasn't a flash in the pan but maintained over a month while slowly trending upward means the feature's reuse rate is meaningfully high.

2) Feature Retention (Reuse Rate) Also Increased..!

• As for feature retention, it wasn't bad to begin with at around 33%, but that might have been because only users who really wanted to use it were doing so at the time. After the flow was changed, feature retention even went up to 50% (a 1.5x increase). This means that despite forcing it, the number of users who tried it today and wanted to try it again tomorrow grew by 1.5 times, signaling a rise in overall user satisfaction.

3) VoC Didn't Spike..

• Generally, when a specific feature changes, related user tickets jump significantly for a while. It spikes even harder if the change fails to solve a problem. On the other hand, changes that actually solve problems tend to see an initial influx of tickets that quickly tapers off.

• Tickets did come in regarding this change, but not many. (Only 6 complaints)

In short, Alarmy's "Sleep Mode" started as something that optionally created a sleep environment, but due to poor usage rates, we judged it wasn't properly solving the problem. When we added friction by making it mandatory to use if a user wanted to listen to sleep sounds, both the usage rate and retention increased. As a result, we got closer to solving the user's problem than before.

To create a more concrete sleep environment in the future, flows that make exiting Sleep Mode itself difficult or periodically sending push messages when someone leaves Sleep Mode (a.k.a. "distraction prevention") are currently being planned. Similar to our past product specs, it might be a bit annoying for users in the moment, but we expect it to help solve their sleep onset issues, leading to good usage rates and feature retention.

Sometimes when planning a feature, the voices of existing users can be so intimidating that we hesitate to move forward with the product spec at all. This is especially true if the spec introduces a specific inconvenience. In those times, it's good to reflect on whether that product spec ultimately helps the user. Of course, I can't guarantee that reflecting will give you crystal-clear confidence in the spec, but it can at least clear away unnecessary levels of hesitation.