Advancing MongoDB's Cloud Platform
Product Designer II • 2019-2020
I helped modernize Atlas's platform to improve the end-user usability of events and pave an intuitive UI for users to create, view, & resolve alerts.
Background
I was one of two designers on the project over the course of 3 months and our responsibilities and stakeholders included:
Foundational Research & Synthesis
User Interviews
Golden Thread Exercise
UX Ideation & User Testing
Stakeholder Reviews
VP Design
VP of Cloud Engineering
VP of Product
Director of Product Design
Goals
At the time, there were four different pages where users can monitor alerts and events in our platform: Organization Alerts, Project Alerts, Organization Activity Feed, and Project Activity Feed.
Objective #1
Our first objective was to modernize the alerts & events platform—the team wanted to support the growth of Atlas platform in regards to both volume and also diversity of products by making the requisite infrastructure investments.
Our first objective was to modernize the alerts & events platform—the team wanted to support the growth of Atlas platform in regards to both volume and also diversity of products by making the requisite infrastructure investments.
Objective #2
The second objective was to improve the end-user usability of alerts and events to offer a simplified and intuitive way for users to create, view, and resolve alerts for all products & events on the MongoDB Cloud platform.
The second objective was to improve the end-user usability of alerts and events to offer a simplified and intuitive way for users to create, view, and resolve alerts for all products & events on the MongoDB Cloud platform.
Our ultimate goal was to modernize the cloud alerts platform to support growth for both volume and diversity of products by making the requisite infrastructure investments. Additionally, we wanted to offer an intuitive way for users to create, view, and resolve alerts for all products.
Personas
1. Database Admins: Individuals who were responsible for configuring non-default alerts & responsible for resolving them.
2. Full Stack Developers: Users who relied on default alerts and wanted a seamless alerts resolution workflow.
1. Database Admins: Individuals who were responsible for configuring non-default alerts & responsible for resolving them.
2. Full Stack Developers: Users who relied on default alerts and wanted a seamless alerts resolution workflow.
Foundational Research
To kick off the foundational research phase, we wanted to confirm our hypotheses regarding cross-platform unification as well as granularity within our alert creation and configuration controls. We asked questions surrounding multiple-conditioned alerts, cross-product adoption (Atlas, Realm, and Charts), centralized alerts, customizable alerts, and anomaly detection.
.png)
Competitive Analysis
I also explored the alert and event experiences on platforms such as Amazon AWS, Microsoft Azure, DataDog, Google Cloud Marketplace, Github, Gitlab, and DigitalOcean to gather inspiration and user interface ideas.
.png)
The pros we saw included sortable tables, upfront filters, customizable views, event details, smart groups, and an alert Timeline. Cons included lack of grouping, difficulty in engineering implementation, and confusing information architecture.
User Interviews
I conducted with our other designer to better learn how users currently use our alert pages. We wanted to uncover existing mental models and use cases of our alert and notification systems.
17 User Interviews
26 Survey Participants
Golden Thread Exercise
I along with my design colleague hosted a golden thread exercise where we identified questions users may have or intentions that could surface while using our alerts and events platform. Also, the outcomes helped map the ways our redesign can address or solve the various pain points and corresponding open questions that would arise for users if they were to interface with alerts and events designs.
.png)
User Interviews
This led our team to solidify design components for the new designs which included:
Search bar
Filterable view
Selection of multiple projects (all, few, or none)
Color coding
Iconography
Filterable view
Selection of multiple projects (all, few, or none)
Color coding
Iconography
Severity rating
Tagging & sorting
Chronological timeline of events
Share button
Documentation links
Tagging & sorting
Chronological timeline of events
Share button
Documentation links
Alerts Mapping Diagram Exercise
Following user interviews, I along with our other designer organized an alerts mapping diagram exercise which helped outlined corresponding personas and general scenario examples to existing alerts and events. The categories that arose included Access, Atlas Network and Security, Audit, Backup, Billing, Clusters, Data Lake, Maintenance, Projects, and Search.
.png)
UX Ideation
Sketches
Our design team divided our project into three major components:
1. Centralized Alerts and Events
2. Alert Creation
3. Alert Resolution
We discussed each sketch and highlighted ideas we liked the most to take with us into the next phase of the project.
Our design team divided our project into three major components:
1. Centralized Alerts and Events
2. Alert Creation
3. Alert Resolution
We discussed each sketch and highlighted ideas we liked the most to take with us into the next phase of the project.
.png)
UX Testing
Iteration #1
Our design team wanted to learn whether users prefer a combined feed or a separate alerts and events feed and also to evaluate the best way to create new alertsUnderstand how users approached alert resolution.
Our design team wanted to learn whether users prefer a combined feed or a separate alerts and events feed and also to evaluate the best way to create new alertsUnderstand how users approached alert resolution.
Iteration #2
In this second iteration, we wanted to better understand how the new designs would fit into users’ workflows. We wanted to capture any existing confusion regarding the new designs and suggestions for changes and improvements in the designs.
In this second iteration, we wanted to better understand how the new designs would fit into users’ workflows. We wanted to capture any existing confusion regarding the new designs and suggestions for changes and improvements in the designs.
In this second cycle of design iterations, it was crucial for us to test how users viewed and navigated these new designs and to observe and note any suggestions for changes and improvements moving forward.
Final Designs
.png)
Alerts Feed
Users expressed that they wanted to see alerts and events in separate views as they are entirely different pieces of information across separate workflows. This helps prevent any errors in interpreting data. Users will navigate to the feed to better understand issue(s).
The multi-select tab component that allows users to switch between open, acknowledged, and resolved alerts.Users can navigate to Alert Settings where they can monitor existing alert configurations, templates, and deleted alerts.
For our users within larger organizations, the filtering function will be useful due to the sheer amount of alerts that they have.
One user mentioned specifically that they have a hard time filtering through the current alerts experience as is.
Users expressed that they wanted to see alerts and events in separate views as they are entirely different pieces of information across separate workflows. This helps prevent any errors in interpreting data. Users will navigate to the feed to better understand issue(s).
The multi-select tab component that allows users to switch between open, acknowledged, and resolved alerts.Users can navigate to Alert Settings where they can monitor existing alert configurations, templates, and deleted alerts.
For our users within larger organizations, the filtering function will be useful due to the sheer amount of alerts that they have.
One user mentioned specifically that they have a hard time filtering through the current alerts experience as is.
.png)
Events Feed
Users expressed that when they are on the activity feed, it is typically in the case of diagnosing or investigating issues. This design reduces the amount of time and friction it takes for a user to examine relevant occurred events within various entities.
Users expressed that when they are on the activity feed, it is typically in the case of diagnosing or investigating issues. This design reduces the amount of time and friction it takes for a user to examine relevant occurred events within various entities.
.png)
Alert Templates
We learned users have scenarios where they create many similar alerts and by having templates, it would help them in cases where the task is monotonous and time-consuming.An example would be in cases of monitoring data usage where the user may need to adjust accordingly once the cluster has be active over a relevant time range. The tabs at the top allow the user to switch between configured alerts, alert templates, and deleted alerts. On default, configured alerts will be shown.
We learned users have scenarios where they create many similar alerts and by having templates, it would help them in cases where the task is monotonous and time-consuming.An example would be in cases of monitoring data usage where the user may need to adjust accordingly once the cluster has be active over a relevant time range. The tabs at the top allow the user to switch between configured alerts, alert templates, and deleted alerts. On default, configured alerts will be shown.
.png)
Quick View
The quick view allows users to see the most recent alerts within the organization by displaying 5 alerts and then adopting a scrolling behavior to allow users to observe other alerts. The CTA easily leads users into the Alerts feed and users have scenarios where they create many similar alerts. By having templates, it would help them in cases where the task is monotonous and time-consuming. An example would be in cases of monitoring data usage where the user may need to adjust accordingly once the cluster has be active over a relevant time range. The tabs at the top allow the user to switch between configured alerts, alert templates, and deleted alerts. On default, configured alerts will be shown.
The quick view allows users to see the most recent alerts within the organization by displaying 5 alerts and then adopting a scrolling behavior to allow users to observe other alerts. The CTA easily leads users into the Alerts feed and users have scenarios where they create many similar alerts. By having templates, it would help them in cases where the task is monotonous and time-consuming. An example would be in cases of monitoring data usage where the user may need to adjust accordingly once the cluster has be active over a relevant time range. The tabs at the top allow the user to switch between configured alerts, alert templates, and deleted alerts. On default, configured alerts will be shown.
Slide-out Alert Creation
Users expressed that they wanted a “quick” way to create alerts on the same page as the unified feed. During user research, a user mentioned that developers on his team usually create a test event (i.e. a database usage alert) and after an approval process, they will always go back to the alert to then update it.
Users expressed that they wanted a “quick” way to create alerts on the same page as the unified feed. During user research, a user mentioned that developers on his team usually create a test event (i.e. a database usage alert) and after an approval process, they will always go back to the alert to then update it.
.png)
Full-Page Alert Creation
Users expressed that they Users who favored this full-page experience because it was seen as more organized when creating a new alert by seeing all of the options at a first glance. These users wanted to be able to see the options and information upfront rather than digging into all of the dropdown options in the input fields.wanted a “quick” way to create alerts on the same page as the unified feed. During user research, a user mentioned that developers on his team usually create a test event (i.e. a database usage alert) and after an approval process, they will always go back to the alert to then update it.
Users expressed that they Users who favored this full-page experience because it was seen as more organized when creating a new alert by seeing all of the options at a first glance. These users wanted to be able to see the options and information upfront rather than digging into all of the dropdown options in the input fields.wanted a “quick” way to create alerts on the same page as the unified feed. During user research, a user mentioned that developers on his team usually create a test event (i.e. a database usage alert) and after an approval process, they will always go back to the alert to then update it.
.png)
Alert Resolution
At the top of every "Alert Details" page, there will be a card component that consists of high-level information on the alert. This information will give our users a general understanding of why this alert occurred and where. This card provides links to the project/cluster of where the Alert occurred, a full description of why this Alert was triggered, and information regarding of what time it was triggered.
With every "Alert Details page," we will provide our user with action steps on how to resolve the Alert. This will consist of content authored by MongoDB employees that provide information on how go about resolving a particular alert. This card will also provide links and documentation to provide more information in the case that the user wants to learn more or chat directly with MongoDB Support.
At the top of every "Alert Details" page, there will be a card component that consists of high-level information on the alert. This information will give our users a general understanding of why this alert occurred and where. This card provides links to the project/cluster of where the Alert occurred, a full description of why this Alert was triggered, and information regarding of what time it was triggered.
With every "Alert Details page," we will provide our user with action steps on how to resolve the Alert. This will consist of content authored by MongoDB employees that provide information on how go about resolving a particular alert. This card will also provide links and documentation to provide more information in the case that the user wants to learn more or chat directly with MongoDB Support.
Impact
We received approvals from our lead stakeholders across the Atlas cloud leadership team to build out the new alerts and events platform in upcoming quarters to aid users' processes in creating, viewing, resolving alerts and events.
READ NEXT: CRAFTING INSTAGRAM'S EOY PLAYBACK