Monitor: root cause analysis

Monitor is a powerful tool, but it was originally built by software engineers and the experience of using it was never really considered.

It went through several tweaks to improve usability and performance, yet despite plenty of feedback about usability issues we only recently managed to “sell” the need to work on its overall experience. The project started as “Monitor experience redesign”, but that name didn't reflect what we were actually doing — so it became “Root cause analysis”.

Phase 1 — Discovery

We started with stakeholders, to get an overview of Digibee's current moment and understand how to align the initiative with company strategy. Everything was then documented in Marvin so we could build the insights needed to set a direction.

Below is a short clip of the stakeholder who helped us most — Matt Durhan. He opened our eyes to the concept of layers and how we could centralise the analysis in a single place. In other words: could we surface the exact point where the error occurred and start the study from there?

Phase 2 — Exploration

The second phase began with an extensive competitive analysis, which we then condensed into something more tangible.

1. 01Provide data autonomy around logs.
2. 02Isolate the error — root cause analysis.
3. 03Provide a clear path to resolution.
4. 04Keep time spent inside Monitor as short as possible.

Phase 3 — Validation and testing

We first tested the observability proposal, but it proved too expensive in time and development effort, so we took a more conservative route: root cause analysis became the MVP and observability was pushed to a later phase.