Design Guidelines For Better Notifications UX

Over the years, I’ve developed a habit to turn off all notifications once a year — both on mobile and on desktop. There are exceptions, of course, for the loved ones and friends, but most channels are put on the silent mode or mute mode until I eventually restore the ones that I really miss in the beginning of the year.

There is a good reason for it: high frequency of notifications. In usability testing, it’s the most common complaint, yet every app desperately tries to capture a glimpse of our attention, sending more and more notifications our way. Let’s see how we could make the experience around notifications slightly better.

This is an upcoming part of?Smart Interface Design Patterns ?? — a 10h-video course on UX design. With a live?UX training starting in November.?Use code LINKEDIN to save 15% ??.

1. The Many Faces of Notifications

Notifications are distractions by nature; they bring a user’s attention to a (potentially) significant event they aren’t aware of or might want to be reminded of. As such, they can be very helpful and relevant, providing assistance, and bringing structure and order to the daily routine. Until they are not.

Not every communication option is a notification. As Kim Flaherty rightfully noted, status communication often relies on validation, status indicators and notifications. While they are often considered to be similar, they are actually quite different:

• Indicators are passive and conditional. They don't require users to take action, but cue the user to something of note. Often as an icon, a flag, typographical variations, changed size or animation. They stand out to inform the user that there is something special that warrants their attention.
• Validations are error messages that prompt users to take action clear the error. They are directly related to user’s input and often come along with an icon.
• Notifications alert the user of a state of the process or a system. They are focused on external events but are not necessarily triggered by users’ immediate actions. They can be passive or require an action.

In general, notifications can be either informational (calendar reminders, delay notifications, election night results) or encourage action (approve payment, install an update, confirm a friend request). They can stream from various sources, and can have various impact:

• UI notifications appear as subtle cards in UIs as users interact with the web interface — as such, they are widely accepted and less invasive than some of their counterparts.
• In-browser push notifications are more difficult to dismiss, and draw attention to themselves even if the user isn’t accessing the UI.
• In-app notifications live within desktop and mobile apps, and can be as humble as UI notifications, but can take a more central role with messages pushed to the home screen or the notifications center.
• OS notifications such as software updates or mobile carrier changes also get in the mix, often appearing together with a wide variety of notes, calendar updates, and everything in between.
• Finally, notifications can find their way into email, SMS, and social messaging apps, coming from chatbots, recommendation systems, and actual humans.

You can see how notifications — given all their flavors and sources — could become overwhelming at some point. It’s not that we pay exactly the same amount of attention to every notification we receive, though. For the vast majority of users, it can take weeks until they eventually install a software update prompted by their OS notification, whereas it usually doesn’t take more than a few hours to confirm or decline a new LinkedIn or Facebook request.

2. Not Every Notification Is Equal

The level of attention users grant to notifications depends on their nature, or, more specifically, how and when notifications are triggered. People care more about new messages from close friends and relatives, bank transactions and important alerts, calendar notifications and any actionable and awaited confirmations or releases.

As Sara Vilas suggests, we can break down notification design across three levels of severity: high, medium, and low attention. And then, notification types need to be further defined by specific attributes on those three levels, whether they are alerts, warnings, confirmations, errors, success messages, or status indicators.

High-attention

• Alerts (immediate attention required)
• Errors (immediate action required)
• Exceptions (system anomalies, something didn’t work)
• Confirmations (potentially destructive actions that need user confirmation to proceed)

Medium-attention

• Warnings (no immediate action required)
• Acknowledgments (feedback on user actions)
• Success messages

Low-attention

• Informational messages (aka passive notifications, something is ready to view)
• Badges (typically on icons, signifying something new since last interaction)
• Status indicators (system feedback)

Taking it one step further, we can map the required attention against the type of messaging we are providing —?very similar to Zendesk's mapping tone below, which plots impact against the type of messaging, and shows how the tone should adjust — becoming more humblident, real, distilled or charming.

People care less about news updates, social feed updates, announcements, new features, crash reports, promotional and automated messages in general. Most importantly, a message from another human being is always valued much higher than any automated notification.

So notifications can be different, and different notifications are perceived differently; however, the more personal, relevant, and timely notifications are, the higher engagement we should expect.

3. Start Sending Notifications Slowly But Steadily

It’s not uncommon to sign up, only to realize a few moments later that the inbox is filling up with all kinds of irrelevant, and rarely actionable, messages. That’s exactly the wrong thing to do. A study by Facebook showed that sending fewer notifications improves user satisfaction and long-term usage of a product.

Initially, once the notification rate was reduced, there was indeed a loss of traffic, but it has “gradually recovered over time”, and after an extended period, it had fully recovered and even turned out to be a gain.

A good starting point is to set up a slow default notification frequency for different types of customers. As the customer keeps using the interface, we could ask them to decide on the kind of notifications they’d prefer and their frequency.

Send notifications slowly, and over time slowly increase and/or decrease the number of notifications per type of a customer. This might work much better for our retention rates.

4. Don’t Rely On Generic Defaults: Set Up Notification Modes

Typically users can opt in and opt out from every single type of notification in their settings. In general, it’s a good idea, but it can also be very overwhelming — and not necessarily clear as of how important each notification is. Alternatively, we could provide predefined recommended options, perhaps with a “calm mode” (low frequency), a “regular mode” (medium frequency), and a “power-user mode” (high frequency).

As time passes, the format of notifications might need adjustments as well. Rather than having notifications sent one by one as events occur, users could choose a “summary mode,” with all notifications grouped into a single standalone message delivered at a particular time each day or every week.

That’s one of the settings that Slack provides when it comes to notifications; in fact, the system adapts the frequency of notifications over time, too. Initially, as Slack channels can be quite silent, the system sends notifications for every posted message. As activities become more frequent, Slack recommends reducing the notification level so the user will be notified only when they are actually mentioned.

5. Make Notification Settings A Part Of Onboarding

We could also include frequency options in our onboarding design. A while back Basecamp, for example, has introduced “Always On” and “Work Can Wait” options as a part of their onboarding, so new customers can select if they wish to receive notifications as they occur (at any time), or choose specific time ranges and days when notifications can be sent.

Or, the other way around, we could ask users when they don’t want to be disturbed, and suspend notifications at that time. Not every customer wants to receive work-related notifications outside of business hours or on the weekend, even if their colleagues might be working extra hours on Friday night on the other side of the planet.

6. Allow Users To Snooze Or Pause Notifications

User’s context changes continuously. If you notice an unusual drop in engagement rate, or if you’re anticipating an unusually high volume of notifications coming up (a birthday, wedding anniversary, or election night, perhaps), consider providing an option to mute, snooze, or pause notifications, perhaps for the next 24 hours.

This might go very much against our intuition, as we might want to re-engage the customer if they’ve gone silent all of a sudden, or we might want to maximize their engagement when important events are happening. However, it’s easy to reach a point when a seemingly harmless notification will steer a customer away, long term.

Another option would be to suggest a change of medium used to consume notifications. Users tend to associate different levels of urgency with different channels of communication.

In-app notifications, push notifications, and text messages are considered to be much more intrusive than good ol’ email, so when frequency exceeds a certain threshold, you might want to nudge users towards a switch from push notifications to daily email summaries.

7. Track The Usage Of Notifications

Usually notifications aren’t sent for the sheer purpose of informing customers about an occurring or upcoming event. Good notifications are useful and actionable, helping both customers and businesses achieve their goals. For that, relevant metrics have first to be discovered and defined.

As a bare minimum, we might need to know if the notifications we send are relevant in the first place.

• Do the wording, format, and frequency of notifications drive the desired action that we aim to achieve (be it social shares, time spent on the site, or purchases)?
• What kind of notifications matter more than others?
• Do the notifications actually bring users back to the application?
• How much time passes between sending the notification and the user’s return to the site or app?
• How much time is spent on average between the clickthrough of a notification and the user leaving the site?

Experiment with wording, length, dispatch times, and grouping and frequency of notifications for different levels of user involvement — beginner, regular user, and power user. For example, users tend to be more receptive to conversational messages that feel more casual and less like system notifications. Mentioning the names of actual human beings whose actions triggered a notification might be useful as well.

It’s never a bad idea to start sending notifications slowly to track their potential negative impact as well — be it opt-outs or app uninstalls. By sending a group of notifications to a small group first, you still have a chance to “adjust or cancel any detrimental notification campaigns before it’s too late,” as Nick Babich remarks in “What Makes A Good Notification”.

All these efforts have the same goal in mind: avoiding significant disruption and preventing notifications fatigue for our customers, while informing them about what they want to know at about the time they need to know it. However, if cookie prompts are just annoying, and frequent notifications are merely a disturbance, when it comes to the security of personal data and how it’s managed, customers tend to have much more pressing concerns.

Wrapping Up

As always in design, timing matters, and so do timely notifications. Start slowly, and evolve your notification frequency depending on how exactly a user actually uses the product. For every type of user, set up notification profiles — frequent users, infrequent users, one-week-experience users, one-month-experience users etc.

Allow your users to snooze and mute notifications for a while, and eventually you might even want to suggest a change of medium used to consume notifications.

Notifications are here to help users be notified when it matters, but they shouldn’t be annoying and disruptive when it doesn’t. Finding that balance will require quite a bit of experimentation and testing, but sending fewer notifications is usually a pretty good idea.

Useful resources

• Designing Notifications For Apps, by Shashank Sahay
• A Comprehensive Guide to Notification Design, by Sara Vilas
• Privacy UX: Better Notifications And Permission Requests, by Vitaly Friedman
• Designing Smart Notifications, by Alex Potrivaev
• A taxonomy for alerts and notifications, by Steve Dennis
• The Ultimate Guide to Not F#!@ing Up Push Notifications, by Stéphanie Walter

Last Early Birds:?Live UX Training (Nov 1 – Dec 2, 2024)

It's an upcoming part of Smart Interface Design Patterns, a friendly 10h video library ?? and a live UX training — with live sessions, real-life UX challenges,?1:1?feedback?and?UX certification (starting November 1). Ah, use the coupon code ?? LINKEDIN to save 15 off.

Thank you so much for your support, everyone —?and happy designing! ????