Notifications framework for business apps
The majority of Microsoft products use or try to align to one UX framework - Fluent UI. This framework provides a solid foundation for a lot of use-cases, however, it does not cover all of them. Each of the product or product groups might have unique scenarios, but sometimes they intersect and the need for a new pattern emerges. One such example is notifications. The official version of Microsoft Fluent UI provides only three options for the notifications: a coach mark, message bar, and teaching bubble. It’s a good starting point but obviously is not an extensive list.
Overview
I worked on Microsoft business applications, and across products, we had a need to notify users about different events and in different contexts. It was one of the priority areas based on the frequency of application and importance. The designers from different teams decided to tackle this problem and started a “volunteer team.”
Key areas we were aiming to explore:
What are the different scenarios we currently have and how do we solve them across products?
How will the designer be able to choose one pattern vs the other?
How much control will the user have over the notifications?
What sound (if any) should the different types of notifications have?
Business goal
Create a consistent notification framework that can be used across business products.
Role and duration
Co-led a “volunteer team” with another designer, 10 UX designers, 2 sound designers, 1 researcher, 2 developers.
I was responsible for the direction and timeline of the whole effort, worked on the decision tree and accessibility of the components.
April 2020 - October 2020
Audit of the current state
We did audits across 20+ business applications. We found many inconsistencies not only in style but also in the placement on the surface, language and terminology, misuse of one type of notification vs the other.
A few reasons contributed to this state:
Different platform frameworks and framework limitations.
Different ages of the product.
Lack of solid guidance and components.
After auditing, we prioritized the most common scenarios. Since the component for the message bar already exists and covers the majority of the use-cases, we focused on aligning toasts, a notification center, component accessibility, sound, and a decision tree.
Toast
Atomic level
Toast types
Based on the audit, we tried to cover majority of the scenarios and provide flexibility. These are just a few examples.
Notification center
Accessibility
Every Fluent UI component should meet accessibility requirements defined be WCAG 2.1. This includes not only the tab order, roles, labels, but also recently introduced criterion for 400% zoom.
Toast
Notification center
400% zoom
Research on sound
Together with the sound designers, we grouped all notifications into 9 categories, each category had 3 sounds for research. We collaborated with the UX researcher to conduct the study and the design engineer to build a prototype for it.
Study details:
Users first saw a screen with 27 options and rated them for pleasantness, urgency, uniqueness, how much they liked the sound, and what type of sound it was (random order).
They also rank-ordered each of the sounds within the actual contexts for which they thought fit best in that category.
Key questions we had:
Which notification sounds do users prefer when compared both within a context and out of context?
Do users understand what a sound is trying to portray without outside information?
Which notifications are distinctive and useful without bordering on too urgent or annoying?
This study helped our team find the “winner” for a particular notification sound.
Decision tree
The decision tree guides the designers on selecting the right type of notifications in different contexts. It also helps achieve consistency across products and sets the expectations for the users.
Conclusion
This collaboration effort brought many designers together and was one of the many steps to align diverse and complex business applications. There were many design reviews with designers from across the organization who were not part of our volunteer team. Multiple discussions, iterations, and experimentations help us understand the area better and find a fine balance between user needs and technical limitations.