The challenge
Rethink our notification components to fit the needs of our users and designers while simplifying their use cases and code structure.
Scoping the challenge
When scoping out the challenges, the first step was to identify and address the fragmented experiences stemming from the coexistence of legacy notification components used in production. This meant auditing the diverse use cases of our notifications, which revealed misaligned usage patterns, constrained handling of critical messages, and overlapping functionality. A thorough review of localization requirements was essential to ensure global accessibility and clarity across languages. To maintain consistency, I collaborated closely with the branding team to align the visual language of our notifications with the refreshed 3.0 design principles. I also partnered with our engineers to evaluate technical feasibility and scope, ensuring that the new approach could be seamlessly implemented without introducing unnecessary complexity.
Auditing internal and competitor use cases
Conducted a comprehensive review of all existing notification components and their use cases.
Identified misaligned usage patterns and overlap in functionality.
Analyzed competitor usage patterns and guidelines.
Reviewed how critical messages were communicated and pinpointed areas where our notification components fell short.
Reviewing localization requirements
Assessed how notifications were adapted for different languages and regions.
Identified inconsistencies in content presentation across localized versions.
Reviewed existing character limits and potential pitfalls with lengthier languages.
Cross-functional alignment and prioritization
Established clear objectives: simplify use cases, improve usability, and align visually.
Scoped out development efforts to ensure the implementation was efficient and scalable.
Prioritized tasks based on user impact, engineering effort, and alignment with product goals.
Finding opportunities
Addressing the fragmented notification experience presented several opportunities to enhance usability, visual alignment, and technical efficiency. By adopting a consistent design language, I could ensure uniformity across all components while creating a system that is easy for designers and developers to use. Simplifying the use cases and improving the DOs and DONTs between notification types was a way to remove redundancy, ensuring each type has a clear, distinct purpose. Analyzing our competitors and established systems allowed me to review best practices and patterns. When a technical solution is well established, it give our engineers the confidence and additional resources to review and compare. Additionally, this opened the door to improve our overall affordance and usability. Our colors used for notifications up to this point were lacking consistency in their use of color, with some relying heavily on pure iconography, which could increase cognitive load, and therefore hinder the experience given the state of mind a user may be in when a given warning or error occurs.
Using a consistent design language
A consistent design language offered a clear way to unify the visual style of all notification components, creating a cohesive experience for users. This approach also streamlined collaboration across teams by standardizing the design tokens, atoms, and interaction patterns, improving handoffs between product designers, content designers, and engineers. This, coupled with removing excess customizations, allowed us to streamline our documentation and reduce confusion for our design partners.
Adopting industry-established practices
Adopting industry-established practices further grounded our approach in proven methodologies. By incorporating recognized patterns for notification hierarchy, placement, and interactions, we were able to create a system that felt more intuitive not only to our design partners, but one that would trickle down and feel the same to our end users. This update also made it easier to improve our accessibility, by improving our color contrast and tap target sizing across the board for our notifications.
Improving affordance
By establishing a color system that signaled severity and urgency—such as red for critical errors and yellow for warnings— our notifications became more scannable and actionable. This, in addition to improve text and button sizing, not only enhanced visual hierarchy, but also provided users with quick cues to understand the purpose and importance of each message.
Streamlining the UI structure
Streamlining our developer workflows became an integral part of the solution. By creating our notifications with a mindset to be reusable and modular, we reduced implementation time and effort for engineers. These components were designed to be scalable and cohesive by reusing core tokens and atoms, ensuring that they could adapt to future needs and changes while maintaining consistency.
Planning and executing
The planning phase focused on translating the identified opportunities into actionable strategies that aligned with our overall systems goals. I started by defining clear objectives: creating a cohesive design language, simplifying notification use cases, and improving our visual affordance. I collaborated with cross-functional teams, including product and content designers, brand designers, and our engineers to review overall design, existing pain points, and prioritize the solutions.
Execution relied on an iterative and collaborative workflow. I began by comparing industry best practices and our current components to identify any usability outliers. From there, I created wireframes to review our hierarchy and test out the approach to segmenting the various types. It was paramount that I established clear use cases to help remove the overlap between notifications. Outside of simplifying our use cases for our designers and engineers, each type in itself could act as an additional affordance and create a feeling of familiarity for our users. This in part relied on a modular approach, ensuring they all adhered to our established patterns and visual guidelines while sharing key visual aspects to maintain consistency and scalability.
Establishing edge cases
It was important to establish guidelines for our designers and engineers around edge cases, especially when some components changed in their use cases or placement. Stacking, for example, had to be thought of with all 4 of our notification types.
This meant mapping out severity, timelines, hierarchy, and interplay between notification types, as specific notifications like system alerts and snackbars, don’t have a traditional stacking structure.
Market-specific fixes
Certain markets have to have permanent warnings affixed to the top of the screen. This posed a challenge for our new system alerts, since they are meant to stay fixed at the top of the screen until resolved or acted upon. This was taken into consideration when building, and I collaborated with the local market legal and compliance team to find a solution that still met their needs while giving our system alert the proper hierarchy and affordance.
Reviewing the work
Post-snackbar launch, our objective was to test its reception from users by comparing CS tickets related to errors that were previously handled by our toast, in addition to user testing for direct feedback. Any feedback that results in changes will be made across the board when needed to maintain consistency. After our testing and color updates, we would phase in the rest of the notification components.
Long-term vision
Post-snackbar launch, our objective was to test its reception from users by comparing CS tickets related to errors that were previously handled by our toast, in addition to user testing for direct feedback. Any feedback that results in changes will be made across the board when needed to maintain consistency. After our testing and color updates, we would phase in the rest of the notification components.
