Thinking in frameworks: communicating system status | by Poulami Chakraborty | Aug, 2021

Quite a few articles have been written on notification design. But most of them has been in the context of consumer-facing products. The main focus as such has been on best practices to avoid overwhelming and annoying users with too many notifications.

Yet notifications are inherently powerful tools to keep users updated about the system status — visibility is one of the 10 usability heuristics for interface design.

This is especially important in information-heavy enterprise domains — with multiple background events — where users are continuously trying to sort out relevant information without missing major errors or failures. A well-designed notification system can add value and stay focused in light of all information fighting for the user’s attention. Notifications should help reach a goal rather than pestering them.

Three common approaches for status communication include validation, notifications, and status indicators.

  • Indicators: An indicator is a way of making a page element (be it content or part of the user interface) stand out to inform the user that there is something special about it that warrants the user’s attention. (ex: sale sign, usage/performance indicators)
  • Validations: Validation messages are error messages related to users’ inputs — they communicate whether the data just entered was incomplete or incorrect.
  • Notifications: Notifications are informational messages that alert the user of general occurrences within a system.

This NN Group article goes in-depth on picking the correct communication method. I won’t be getting into this differentiation here.

I will be using notifications as a umbrella term for push/in-app notifications, alerts, validations and indicators unless otherwise specified.

As products grow and features are added, the notification list would also increase. Case-by-case design means a inconsistent design language. A comprehensive policy and design framework is necessary ensure a consistent and good UX.

Thinking in systems helps to look at the bigger picture, account for scalability and be prepared for unforeseen use cases.

Moreover a consistent notification pattern and language increases the learnability and glancability of the design.

  • Information: This is the message we are trying to convey. This should provide users enough context to quickly identify the issue and decide if the information is important.
  • Source/ context: This is feature/data from which the notification originates. Based on how the notification is anchored, we may need to include this information in the message.
  • Action (optional): These are potential remediation steps that the user can/should take.
  • Anchor/ Mode: This is where the notification will surface (ex: notification centers, contextual badges, emails, webhook integrations, etc.)
  • Notification indicators or counters: This are the visual cues to make users aware of the fact that there is something that needs their attention. This can include the number of unread notifications.
    Consider the bubbling up of notifications in a category (ex: in whatsapp the messages tab shows the number of unread threads in addition to unread threads showing number of unread messages)
  • Meta-data: Time, reason they are seeing this notification, etc.
(Some) Components of a notification

There exists multiple criteria on which notifications can be classified:

  • Active vs Passive: whether user needs to take action
  • Urgency: how critical is it that the notification be seen immediately (critical, warning)
  • Type: alerts, validations, or indicators
  • Trigger: task-generated (ex: request successfully completed) vs system-generated (ex: upgrade available)
  • Persistence: whether user can dismiss the notification (ex: ongoing issue like system problems need to be persistent)
  • Validations (Inline) Validations are messages to alert users of errors in input fields. This is contextual, preferably inline and anchored to the input field.
  • Toast, Snackbars, In-app push notifications Toasts and snackbars are generally used for non-urgent (good-to-know) system feedback to a user action (ex: “Form submitted”). These are also be used after user has left the input screen.
    The information is concise as users are aware of the context.
    In-app notifications (which are similar to snackbars) are used to alert users of activity in different part of the product. Example: New message in slack).
    These messages are generally not critical and don’t require any or immediate action. In most cases, these automatically disappear after some time.
    The elements are displayed non-intrusively so that user’s current activity remains visible and interactive. A possible side-affect is that these could go unnoticed. So, don’t use (only) toasts to communicate critical information.
  • Notification Center
    Notification center is an exclusive place for notifications. It’s generally a flyout but can also be a dedicated page.
    The anchor is this UI component, no matter the origin of the notification. Existence of a notification center may set the expectation of user to be able to find all critical alerts at a place.
    Don’t push all notifications to notification center to avoid overwhelming users.
  • Modals
    Modals are the most disruptive to the user experience and hence should be sparingly used. They are useful when we need to block tasks to gain user’s focus. For instance: to alert an user that their progress will be lost if they navigate away from a flow.

Begin by listing all existing notifications or, in case of new products, major notifications. Next is prioritizing and categorizing them to use as a baseline for creating the policies.


The first step is determining the criteria for showing a particular notification. Ask if the notification is deserving of user’s attention or is it unnecessary noise. Don’t use alerts for unimportant information (ex: ‘You have logged in’). It can lead to desensitization of users.

“If everything is important, then nothing is.” ― Patrick M. Lencioni


Not every notification is equal. With multiple notifications vying for the user’s attention, there has to be a logical way of prioritizing information.

One factor would be the UI pattern used — for example, user’s attention would more naturally turn towards a larger alert banner than an indicator.

The second prioritizing would be the severity of the message — info/ warning/ error/critical.

Generally, standard color, icons and conventions are used to differentiate.

The same notification ‘ can have different severity based on a value (Ex: ‘You have used 60% of storage’ and ‘You have used 95% of storage’)

Put urgent and important notifications front and center. Otherwise put it out of the way — a consistent design pattern will let users to find them if they really want to see it.


Trigger for the notification — when would this notification surface? Under what condition should/will it be resurfaced as reminder?


Are there associated actions that would help remediate the issue? Or any documentation to link users to? How do they understand exactly what is going on and how to get themselves out of the snag? What happens if user doesn’t take any action? What’s the escalation policy? (Ex: unresponded alerts to be transformed to global beanners or sent as email)

Here is a checklist based on the above points:

[ ] Why are we showing the notification?

[ ] Trigger

[ ] Anchor/Mode (can be more than 1)

[ ] Severity (Critical/Urgent/Warning)

[ ] Associated actions

[ ] Persistence (can’t be dismissed/can be dismissed/auto-dismiss)

[ ] Permanence (can be retrieved in log)

[ ] Escalation criteria

Your design system would lay out the rules for when each of this components can or should be used. For reference:

Carbon Design System

Clarity Design System

Source link

Latest articles

Related articles

Leave a reply

Please enter your comment!
Please enter your name here