homeblogdesigning systems not just ui alerts notifications

Designing systems, not just UI: alerts & notifications

We’ve recently worked on the design of alerts and notifications for a new application here at Puppet.

With an array of messages to deliver to the user while using the application — some critical, some not — as good UX citizens, we wanted to design not just a notification UI, but a system. One that would scale with the application while maintaining consistent patterns that users could easily learn and process.

Additionally, we wanted to empower engineers to make confident decisions about the nature of new alerts and notifications as they arose, even when designers weren't in the room.

On the shoulders of giants

I am something of an aficionado of thinking frameworks. The Merrill Covey Matrix has always appealed to me as a simple but powerful tool. Using it as a central reference, we created a similar, quadrant-based model. The axes selected for the model were:

  • Urgent vs. non-urgent (whether effective use of the application will be affected, or not)
  • Active vs. Passive (whether the user needs to take an action, or not)
alerts notifications

Trial by content

We trialled the model initially by testing real examples of feedback to the user for ‘fit’ in each of the quadrants. Examples might be:

  • a timeout
  • a license warning
  • new data loaded in the application
  • etc.

The test was to find a matching quadrant for each example of feedback.

When we were satisfied that the model accommodated a suitably broad spectrum of content, we set about defining what each type of notification represented. We gave each a descriptive name, making them easier to reference than simply ’Type 1’ or ‘Alert 2’.

A loose definition of each was added, in plain language, describing the purpose of each notification type.

Intervention: Critical events requiring action from the user in order to use the application effectively/or at all.

Warning: Non-critical events that the user may want to attend to. Not time-sensitive, no specific requirement for action.

Caution: Events which may affect the performance of the application.

Indicator: Non-urgent information for the user, with no requirement for action.

alerts notifications

Reverting to type

Finally, we built out a simple table of features applicable to each of the four notification types, as seen below. This was notional, but it reflected what we needed from each at the time. These characteristics could be expressed in the UI design for the components.

alerts notifications

At this point, we revisited the sample notifications we had previously categorized to check if they still aligned with the behaviors we had identified. We were gratified to find that the vast majority of events we needed to handle fitted consistently with the other notifications in their category.

There were some exceptions to the model: form errors, login errors, empty states, and HTTP status errors (such as 404s). These we felt to be solved problems with their own well-established patterns.

Satisfied the categories were as watertight as they could be, the system progressed into implementation in UI design.

It’s important to note that the quadrant model does not dictate on-screen placement. It is used purely for categorization.

Room to grow

The notification category definitions remain flexible, meaning this model can continue to be a useful reference point for future scaling and feature enhancement. As an example: Where might notifications external to the application, such as emails or text messages, fit? The model helps frame discussions around these kinds of questions.

Why 4 categories of notifications? Primarily, that’s what the matrix delivers as default. Any more than that would have been leading us into the kind of territory that we wanted to stay away from — a wild west of pop-ups and modals on the user’s screen.

Could this be distilled into a lesser number? Possibly. And that may very well end up being the case as we implement the system in practice. For now, the model appears robust, based on the exercises we conducted.

While this is not a one-size-fits-all answer to all applications’ needs, we hope the thinking behind it offers some guidance on how to approach similar challenges. And if you do get some value from it, please let us know!

Rick Monro is a principal UX designer at Puppet.

Learn more