What needs attention?
Limited visual hierarchy made it harder to distinguish a critical issue from routine operational information.
Less searching.
More certainty.
Helping engineering teams connect service health, dependencies, and recovery in one operational workspace.
The experience · Try itFrom signal
From signal
to next step.
Select a service, inspect its relationships, and preview a recovery action. This interactive walkthrough demonstrates the UX with sample data.
Services in scope24
Need attention02
Selected environmentProd
Services requiring attention
No matching services. Try “checkout” or “identity”.
Checkout API
CriticalSample services and simulated actions. No connection to production systems.
01 · The challengeThe data was there.
The data was there.
The context wasn’t.
The previous monitoring interface exposed technical information, but made engineers work to connect the signals. Important alerts competed with dense lists, navigation took effort, and service relationships were difficult to follow.
What else is affected?
Service details and dependencies needed to become part of a coherent investigation.
What can I do next?
Engineers needed a clearer connection between understanding an incident and finding the relevant controls.
The design goal
Help engineers recognize important changes, understand the affected service, and reach a useful next action while retaining context.
02 · Understanding the workDesign around
Design around
the investigation.
I combined stakeholder interviews, power user feedback, workflow observation, and competitive review to define the experience. The work focused on monitoring, dependency mapping, and recovery.
Align on the problem
Clarify operational needs and the goal of improving time to recovery.
Study real workflows
Understand the information engineers rely on and where navigation interrupts their work.
Explore and test
Move from early prototypes into detailed layouts, incorporating usability feedback.
Refine with engineering
Resolve interaction details and adapt the design to technical constraints during delivery.
03 · The shiftA clearer starting
A clearer starting
point for triage.
The redesign brings status, filters, alerts, and linked service context into the dashboard. The layout helps users narrow their focus before moving into detail.
04 · Design explorationDifferent views.
Different views.
One connected job.
I explored overview and table layouts for distinct operational tasks. Browse the original screens to see how context, density, and actions change with the work.
Exploration 01 / 04
Bring the signals together.
An alert list paired with microservice, application, system, and flow context. This direction emphasizes relationships during triage.
Click the screen to enlarge ↗
05 · Service detailKeep the service
Keep the service
in focus.
The redesigned service view pairs core information and operational controls with recent activity. Engineers can assess the current state and review what happened in the same context.
Know what you’re viewing.
Service information establishes the subject of the investigation before presenting actions.
Review what changed.
Recent activity and alert trends bring operational history into the detail view.
Keep controls nearby.
Relevant operations sit alongside the information needed to evaluate the next step.
06 · Outcome & reflectionClarity is an
Clarity is an
operational feature.
The redesign establishes a more connected experience through clearer status hierarchy, task focused navigation, contextual service details, and accessible controls.
My takeaway
An observability interface should help engineers move through a decision: notice the issue, understand the relationships, and act with context. The design succeeds when that sequence feels continuous.
The next validation step: measure time to identify an affected service, navigation effort during investigation, and completion of recovery tasks. Quantitative impact is not reported in this case study.