Notification Center
Problem Statement: The creation of notifications within the Flagship Commercial Insights product at 84.51˚ is a very manual process as it exists today. It requires a lot of partnership and work between the Functional Support Team, Product Owners and the Product Support Team to create messages that appear to our end users when something is going wrong or they need to be informed.
Project Goal: Define a new notification center experience in the Admin Tool that allows for the creation and management of many different types of notifications within the flagship insights product by any Product Support Team member or Product Owner. Ultimately removing Functional Support from the process.
My Role: I was the Lead User Experience Designer for this project. I conducted research with the Functional Support Team, Product Support Team and Product Owners to better understand the problem space around notifications. Then I designed the new notification center experience that was then validated with the Product Support Team and Product Owners.
Client
84.51˚ LLC
Year
2021
Discovery Research
I kicked off the project by interview all 5 members of the Functional Support Team to better understand their pain points with the process today and opportunities for providing a better experience in the future that would ultimately remove them from the process.
Research Hypothesis
The Functional Support Team would benefit from others having the ability to create, manager and send notifications at any time to users.
UX Outcomes
Stratum Product Support lives will be improved by:
Save time by removing dependency on their team and giving internal Stratum Product Managers, SLED or Product Support team members the ability to create, manage and sent alerts and notifications.
Improve efficiencies in the standards for creating, managing and sending alerts and notifications across Stratum.
Findings
What’s Working Well
Getting the message into environments is quick and easy today. - Leveraging GitHub makes it easy to create a message in any environment
Team has a playbook of established patterns for how they respond to situations.
Team is experienced - Anywhere from 5 – 10+ years experience supporting current and legacy products
Recommendations
Allow internal roles to create and manage notifications and messages
This will remove the dependency on Technical Support.Capture internal notes with every notification or message
Automate the process of why notifications were created. (iService Tickets, Notes, etc)Track history and ability to download an audit report for a range of time period.
Automate the process of understanding underlying performance of 84.51° Stratum and Support team.
Understand why messages were created, what the message was, how long it was live, who made it, and what environment it was in.Reduce # of places for Communications across internal teams
Support, Product, Design and SLED define a strategy for how and where we communicate about issues in 84.51° Stratum.Communications Templates & Best Practices
Support, Product, Design and SLED define a playbook with standards for all message types and the language we use.
Make these examples available in UINotification on Expiration
Whoever creates the notification should be notified when it expires via email
Pain Points
Hard to know who the right people are to inform about any given issue
Each issue requires different people to inform and to solve itTakes too long to organize the right people to agree on a message and get it into environmentsBy the time they gather everyone a large amount of time has passed before they get a message up
The longer they take the more tickets are created for the same issue (compounding)Too many channels to broadcast communications
5+ ways they must communicate issues and gather the right people. (Email, Banner, WNS, Teams and side chats)Need better guidelines for each type of issue
They have a playbook but there needs to be better collaboration and curation of that playbook across Support, Product, Design and SLED.Manual process of keeping an audit trail
They track all the notifications they create and why in a spreadsheet todayManual process of taking down messages
They must go back into GitHub to remove messages manually, sometimes on weekends.
MVP Mockups & Prototype
After conducting the discovery research and understanding the problem space from our Functional Support Team and Product Owner I created mockups of the ideal future experience for creating notifications and a prototype to validate with our Product Support Team.
Usability Research
After creating the mockups and prototype of the new experience I was ready to validate and do a usability test to ensure users could create a new notification easily.
I conducted 1:1 interviews and usability tests with the 5 person Product Support Team to ensure they could accomplish the task.
Recommendations to the team
Allow internal roles to create and manage notifications and messages
This will remove the dependency on Technical Support.Capture internal notes with every notification or message
Automate the process of why notifications were created. (iService Tickets, Notes, etc)Track history and ability to download an audit report for a range of time period.
Automate the process of understanding underlying performance of 84.51° Stratum and Support team.
Understand why messages were created, what the message was, how long it was live, who made it, and what environment it was in.
Reduce # of places for Communications across internal teams
Support, Product, Design and SLED define a strategy for how and where we communicate about issues in 84.51° Stratum.Communications Templates & Best Practices
Support, Product, Design and SLED define a playbook with standards for all message types and the language we use.
Make these examples available in UINotification on Expiration
Whoever creates the notification should be notified when it expires via email
Design Iteration
After validating the MVP experience and that it would provide value to our Product Support Team I started to explore what a more robust Notifications creation experience could look like. I expanded the number of notifications from just banner messages to toast, modal and on-page messages.
