Summary

• Lead designer working with another designer, a PM, and an alerts working group with engineers from each product line.

• We redesigned alerts to be centralized across all products and configurable in bulk across multiple networks.

• We conducted research and ran an ideation workshop to build a more flexible, scalable vision for alerts and to align teams.

• This work laid the foundation for future alert projects and was later implemented as part of another initiative.

Background

The Meraki Dashboard is a web application that network administrators use to monitor and configure their networks. Admins can set up alerts to receive notifications for network critical events, like when devices go offline, security risks appear, VPN goes down, and more. However, alert adoption is low, with only 30-40% of networks enabling the various offline device alerts. Despite this low usage, alerts are one of the top 5 reasons customers call our support team. We want to understand what exactly is keeping people from using alerts more and where we can improve to have the most impact.

We conducted 9 qualitative research calls with customers to better understand current workflows and pain points. We spoke to MSPs (managed service providers) managing alerts for multiple clients, in-house IT teams managing established alerts, and people in early stage rollout getting started with alerts.

Dashboard provides an all-or-nothing approach to alerts. Setting them up feels inflexible and repetitive.
An admin can use network templates to send the same alert configuration across many networks, but slight differences between configurations and recipients means they have to scrap templates and do the work manually across tens or hundreds of networks.

Excessive alerts or alerts for expected maintenance drive users to take extreme measures, like turning off alerts or unsubscribing recipients.
If a customer is rolling out a new site or its undergoing site maintenance, devices might be going offline and online for awhile. To avoid this they might remove people from the recipient list because it's easier than unbinding their network from a template. Or, they might turn off the alert completely. These workarounds leave a lot of room for error.

Lack of confidence that the system is working
When customers find they are falsely alerted to a non-issue, they might completely turn that alert off because they’ve lost confidence in the system. There’s no way for users to give feedback on these false positives so that we can adjust and improve alerts once they are configured.

Goals and metrics

If we are successful, users will be able to quickly standardize alerts across multiple networks and also update alerts for one-off configurations. Recipients will get alerts that are more relevant to them because of increased granularity in recipient addressing and alert thresholds.

Success metrics

• Reduce time to set up alerts

• Increase alert configuration/adoption to 60% of users

• Reduce number of false positive alerts

Business goals

• Reduce opex related to alert support

• Decrease customers’ network downtime

Results

We tested our Invision click-through prototype with customers with an overwhelmingly positive response:

• Enthusiasm for centralized, org-wide alerts

• Configuration feels much more scalable

• The recipients tab makes it clearer which admins are responsible for which network’s alerts

We delivered a research report detailing our findings and insights along with our prototype to Dashboard stakeholders. This work was not developed at the time we completed designs because of business priorities changing and limited resources. However, our work became the foundation for two alerts project in late 2020, with Meraki products such as MR and MI adopting the structure, patterns, and intent seen here. The bulk of our prototype flows has been built and is now in production with positive feedback from users.