Digibee · 2023 — 2024
Alerts
From “we need proactive monitoring” to a released feature: threshold-based alerts for single pipelines and whole realms.
- Role
- Discovery, benchmarking, UX design, handoff
- Company
- Digibee — iPaaS · Integration platform
- Focus
- Discovery, Feature design, Released
The need for alerts first came up while interviewing users and stakeholders about their relationship with Monitor. One client described a need for proactive monitoring — the same need several other clients had: being active instead of reactive about issues inside their integrations.
Phase 1 — Discovery
First we wanted to understand how users actually used Monitor and where alerting could fit. We had many conversations with users and stakeholders, and everything we found went into Marvin.
With a clearer, if still broad, understanding, we narrowed the scope: a user journey built collaboratively with users, then an affinity map to converge the findings.
Given our short schedule, and after discussing it with the development team, the best bet was the first topic: use the five most common errors as parameters to set up alerts.
Phase 2 — Exploration
We still had to understand how those parameters could be configured while meeting user expectations, so we ran an extensive benchmark of PagerDuty, Dynatrace and Datadog.
Understanding how other systems set up alerts told us which structure we could afford within our context and deadline. That produced the concept of a static threshold: a configuration that lets users set parameters against a specific threshold — in our case performance metrics — triggering the alert when the conditions are met.
Phase 3 — Tests and validation
From the static threshold concept we sketched, and after a few versions arrived at the MVP.
3 — The user names the alert and configures the threshold: a number is set and attributed to a metric, creating the parameter. Next they establish whether the condition triggers above or below it, and how long the condition must persist before firing. Finally they pick one or more channels to be notified on.
Phase 4 — Handoff
Development didn't take long — the team had started a few sprints before the usability tests, and three weeks after validation the feature was in beta.
Once we tested the feature with Intercom and FullStory we started on realm configuration, and by then another piece of feedback had arrived: users didn't want to be forced to fill in every field — they wanted to open and collapse only what they needed. We tested and validated accordions for exactly that.
Phase 5 — Release
A few sprints later, after testing the accordion proposal, the new Alerts shipped covering both single-pipeline and realm configuration.
Feature walkthrough