Team
4 eng · 1 PM
Timeline
7–8 months
Year
2025
Clients
Regulated enterprise
01 impact
Lower cognitive load in routine operations
fragmented
→
1 workflow
Related information and actions are organized into one consistent interface, so developers focus on managing services instead of remembering where things live.
Was: routine tasks required navigating between different interfaces, increasing mental effort.
Root-cause identification
baseline
→
~29% faster
The redesigned console surfaces the most relevant operational data where developers need it, enabling faster recovery from common service issues.
Was: diagnosing issues meant manually gathering information from different monitoring tools before acting.
02 target users
Cloud operator
Needs a unified platform to oversee the health of services and their capacity management.
Developer
Needs to identify problems faster and debug them efficiently, without leaving the flow.
03 my role
I was embedded with the engineering team, owned end-to-end product design.
Shadowing Sessions
To understand real workflows, I conducted:
analysis of support tickets, reviews of infrastructure documentation, interviews with developers and operators, shadowing of debugging sessions
Research Findings
- Logs were the main debugging tool, but hard to access: When something failed, developers immediately looked for logs. But logs lived outside the platform — in Kubernetes, in external terminals, in tools the platform didn't know about. The diagnostic process started by leaving the product.
- Fear of mistakes slowed decision-making: in regulated environments, a wrong action during an incident doesn't just slow things down — it triggers compliance consequences. Operators were hesitant to act because the system gave them status without context. They could see that something had failed. They couldn't see why, or whether their next action would make it worse.
Developer's Journey — Happy flow & Error flow
04 Problem Statement
This wasn't just a UX problem. It was a product positioning problem: a cloud platform that required external tools to debug wasn't a complete platform.
05 objective
Gap 1 — Debugging required switching tools
Surface context where issues occur
Fixed by Decision 1
Gap 2 — No central health view
Status-first dashboard unifies fleets of services for seamless and actionable monitoring
Fixed by Decision 2
06 design decisions
- Surfacing the operational data at the point of decision
Scenario
When services fail, developers need immediate visibility into root causes.
Problem identified
Users didn’t want “better logs.” They wanted faster cause-and-effect tracing, “why did this fail and what should I do next?”
Decision I advocated for
- Implemented contextual log surfacing:
- Expandable inline panel for quick glance.
- Dedicated modal viewer with pagination (“Cycle between error messages”) for deeper inspection.
- Metadata (timestamp, error type, source) surfaced for orientation.
Outcome observed
Minimize cognitive switching by co-locating diagnosis with the problem. Enabling flow-state debugging without leaving the operational interface.
- A central health view — status without hunting
Scenario
Once services are provisioned, developers monitor the fleet’s health (OK, Warning, Failed).
Problem identified
Engineers didn’t want prettier dashboards, they wanted contextual states: “Is it my service or infrastructure?” “Do I need to act now?”
Decision I advocated for
- A hierarchical service list view:
- Compact rows for overview.
- Color-coded health indicators (Online, Warning, Failed).
- Expandable detail rows for immediate context. By default expanded view if warning or error state.
- Inline “Documentation” and “Dashboard” links for direct jump to action.
- Push, attention demanding items above
Outcome observed
Deliver actionable visibility instead of passive monitoring. Visual hierarchy reduces visual noise while surfacing urgency through color and structure.
07 systems thinking
This reduced long-term maintenance cost.
08 reflection
The contextual log solution gave operators visibility — but visibility is still passive. What I'd explore now is an AI layer that surfaces a probable cause and suggested next action alongside the logs. The system has seen thousands of similar failures. It should use that. That's the difference between showing operators what happened and helping them decide what to do next — which is exactly where Avelios is heading with their AI diagnostics module.
