Context

Bronte is an authoring platform for higher-ed educators and administrators.

It allows them to work collaboratively to build customized textbooks and course materials for their curriculums.

The problem: notifications

The current notification center had 2 key problems:

1. All notifications for all projects went into one bucket. This became overwhelming and made notifications borderline useless as the project grew and more contributors got involved. 

2. There was no consistency in the messages themselves. Over the years, devs had spun up notifications ad-hoc as tickets called for them without much thought for how they worked together.

My role

When I joined this project, the pm and ux designer had already done some competitive research to get a feel for how others were solving this problem. They were circling one visual solution in particular: a divided or tabbed panel.

This is common pattern that our users should be familiar with–outlook, for instance, uses this in their inbox. However, the team had mostly stalled here.

Content governance

Earlier in my time at Pearson, I had created a set of rules and patterns around notifications. 

These were prescriptive guidelines, but only in the loosest possible sense–they had to apply to a range of products, and I didn’t have the time or buy-in to fully implement them in all products or even into our design system. Mainly, their purpose was to govern my own work and provide structure for conversations with stakeholders.

I saw this this project as perfect opportunity to:

1. Codify those guidelines

2. Put them to work
   

The urgency framework

I’m not going to go through every part of my doc, but I will highlight one that proved crucial to solving both of our key problems problems: this urgency framework. 

Basically, the idea is that a notification about a critical error =/= a notification that your coworker has liked your comment. In fact, placing those two notifications in the same bucket risks user trust by making it harder for them to find messages that need immediate action.

On top of that, once we know the urgency of a notification, it can tell us:

• when a notification should be delivered

• how a notification should be delivered

• how the content of the notification should be structured

Applying the framework

I brought this concept to the team and showed them how I thought we should apply it. More specifically:

Once they were on board, I worked through our list of known notifications and sorted them by urgency, which then allowed me to assign a delivery style, which THEN let me adjust the content patterns and copy to match. 

In a rough state, that work looked like this:

I took care to structure this is a way that should be scalable, no matter what notifications get added in the future. 

Fixing that notification panel

With all of these pieces in place, it was now very clear how we should be structuring the notification center—a primary tab for medium/high urgency notifications, and a secondary tab for less important activity. I brainstormed some options for labels, and them took them to the rest of the team for input.

Next steps

In a perfect world, this work would make a strong case for starting to integrate content into our design system, so that we can start applying it at scale. While I moved on from this project before getting access to the release data, I’m confident that this notification system is set up in a way that will let it grow and evolve as the teams requires it.