Notification Design Guidelines

Get Design Feedback | Design Articles

In digital products, peripheral messages, collectively known as notifications, should never harm the user experience. Instead, they need to contribute to an experience that helps people achieve a goal. Addressing the notification design early in the design process will produce better results.

Imagine a group of architects designing a three-storey house, working over the blueprints for months. It’s awesome! It’s beautiful! But just as they get closer to finishing the diagram, one of them exclaims, “Wait! How are people coming from the first to the third floor? “They forgot about the stairs!

Similarly, product designers tend to think last of small but critical UX enhancements. As with empty states, designers are prone to leave notifications — warnings, error messages, confirmations, announcements, and acknowledgements — to the very end. The problem can suddenly come to light when the developer asks, “How do we deal with the bugs? “Because it’s an afterthought, this tacking approach often produces sloppy” frankendesigns “that hurt the UX.

To prevent such a situation, it is possible to use an integrated notification design approach to improve user experience. Although designers may not have all the information at their fingertips, the design of a comprehensive notification framework during the product design lifecycle will help to prepare the product for unforeseen use cases.

The essential design principle to keep in mind when embarking on the design of notifications is that they must assist (not impede) people in performing tasks. It is imperative that product prototypes be tested early and that use cases be mapped out where peripheral messaging would be of value to assist interactions. The best way to communicate with users however will vary , depending on several key factors:

The type of information it discloses
The quality of the details – whether it should be presented immediately
Whether the information requires action by the user

Aside from what the styling and behavior of the notifications will be, UX copy needs to set their tone. All copies must be simple, succinct and useful on notifications. Also developed with usability in mind is a well-designed notification framework which has the versatility to accommodate different languages.

The notification terminology used tends to be similar, but will vary slightly from team to team, and from project to project. The designer is responsible for determining the terminology of the notification framework — what is called what — as well as synchronizing everyone on the rationale for using it: what, where, and how.

Better usability By better design of notifications

Notifications play an important role in the usability of goods. “System visibility status” is number one on the Nielsen Norman Group ‘s list of “10 Usability Heuristics for User Interface Design.” The rule notes that “the system should always keep users informed about what’s going on within a reasonable time, through appropriate feedback.”

A notification system is so much an integral part of the UX of a digital product that without it, the product would feel like something is left out. If there is no “system status visibility” and input, running a car without a dashboard is analogous to running.

The dashboard of a car is full of gages, icons and lights designed to provide visibility into the operating system of the car and to ensure safe and stable operability. When we drive, we are kept informed by a cluster of readings and notifications about engine temperature, battery health, oil pressure, lights, brakes, airbags etc. There is a blinking light for the turn signal when we want to make a turn, along with a clicking sound, both of which provide us with feedback. We also have a tank gauge indicating when the fuel tank is low.

Similarly it works with a digital product. Visibility of system status and feedback is essential when it comes to usability, and usability is the foundation stone of great user experience.

Establishing a helpful Framework for Notification

It may be helpful to think about notifications in terms of “signal strength” in order to design a notification framework well. Which peripheral messages need more or less attention? For example, interactions potentially destructive require “louder” notifications, and non-destructive interactions need “quieter” notifications.

Sending people the right amount of notifications is a balancing act, and overdoing them is fraught with danger; the product can get a lot of negative feedback, or, at worst, alienate people to the extent that they abandon it. Therefore designers need to consider the UX carefully and send only messages with a well-defined purpose. Giving users the option to toggle off all, or at least some, of the alerts is also a smart idea.

The initial notification design approach needs to be classified on three levels: high, medium, and low-attention, i.e., “gravity levels.” Therefore, 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.

Once the attributes of the notification have been identified, it is time to create a taxonomy of the various notifications that will form the framework. The following is by no means an exhaustive list — the types of alerts can differ depending on the product, the use cases and other variables. (Please note: different teams use a variety of terminologies as mentioned above. For example, we call a “confirmation” a notification requiring user approval to proceed with a destructive interaction. Some teams may use “confirmation” as a term for a success message).

Attention: Top Priority

Alerts (which need immediate attention)
Errors (which require immediate action)
Exceptions (anomalies in program, something was not working)
Confirmations (potentially destructive actions which require user confirmation to continue)

Attention: Medium Priority

Warnings (needless immediate action)
Acceptances (feedback on user actions)
Successful Messages

Attention: Low Priority

Information messages (aka passive notifications, ready to view something)
Badges (typically on icons, meaning something new since interaction last time)
Status indicators (Input from the system)

Designing Effective Notifications

In order to build a product with great UX, designers need to list all use cases in which alerts can be helpful. It is recommended that this method be performed in conjunction with a developer, because they may be unbiased in most cases and may not have been approached by the designer to help troubleshoot the edge cases.

During user testing, designers should also take note of all experiences where alerts can provide value to improve the UX.

Once armed with the list, the next step is to categorize the notifications based on the level and attributes of attention desired. Again, as notifications should not be intrusive, care must be taken to do so. Some of the questions that should be asked during the review are:

What would trigger the notification?
What type of feedback is received?
Where and how does the Notification appear?
What notification would necessitate immediate interaction?
Is this notice persistent or non-persistent?

Next, it is necessary to determine color coding and icons, and put them into a design system (or style guide). When going through this process, designers need to consider every instance where a notification would appear and make sure that all backgrounds are rendered correctly.

Notification placement is also key. At the risk of stating the obvious, notifications should appear at the top or bottom, or near the corners of the UI to avoid obscuring the interface. What’s more, designers need to test the appearance of notifications with different viewpoints when the design is responsive. It’s especially important where error messages can be shown for mobile responsive types.

It isn’t easy to design a notification framework. It is necessary to consider many small details which occur under different scenarios. Future localisation needs to be kept in mind beyond accessibility and legibility. When used on a German or Japanese platform, a notification system that looks perfect in English can fall apart altogether.

Additional questions to ask when defining notification behaviors:

If an alert or warning is supposed to be permanent, how can designers ensure that after moving away from the initial screen, people still have access to these?
Does the need to add an warning icon with a badge where a notification archive can be viewed?
If a notification is non-persistent, how long before it vanishes, and should there be an option to dismiss it before it fades away?

With mobile apps it is also important to carefully design not only in-app alerts but push notifications (system-level, outside of the app). Often they are interruptions, so it’s important to look at the copy of the message and how and when to ask permission to submit it. We can deter people from using the app if they’re used too often. Too many non-essential notifications can frustrate users who can then silence notifications, or completely stop using the app.

Also, designers should consider actionable notifications which allow people to be productive without opening an app. Enabling users to perform small tasks without going into an app can be a powerful tool to improve UX.

The UX best practice for mobile push notifications is to delay alerts of some type (asking for access to a person’s location, sending push notifications, and so on) until people have had the chance to test the device a little bit.

Get Expert Design Feedback: Improve UX!