The Hub Console

Helping enterprise operators resolve cloud failures 29% faster by bringing the diagnostic loop inside the product

29%

Time-to-Debug Reduced

Less

Errors & Support Calls

Less

Steps and Tools

Discovery: Miro, Figjam, User Journeys
Design: Figma
Product/Backlog: Atlassian

The Problem Area

The business problem:

anynines sells a cloud platform to regulated enterprises, banks, public sector organisations, and companies where system downtime has a direct financial and compliance cost. Every failed deployment or unresolved service failure triggered a support escalation and risked SLA penalties. The business needed MTTR to be low. It wasn't.

The product operators used to diagnose failures was working against them. Navigating the console meant switching between the platform and external Kubernetes log tools a broken loop that doubled resolution time and increased operational cost with every incident.

The Opportunity:

If we could bring the entire diagnostic loop inside the product status visibility, log access, and error investigation in one continuous flow we could significantly reduce MTTR, lower support costs, and increase operator confidence in a high-stakes environment. 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.

Discovery

To understand real workflows, I conducted:

Analysis of support tickets
Reviews of infrastructure documentation
Interviews with developers and operators
Shadowing of debugging sessions

Key Insights that guided the decisions:

Developers memorised unsafe workarounds
Logs were the main debugging tool, but hard to access
Users prioritised speed over elegance
Fear of mistakes slowed decision-making
Most errors happened during provisioning

User Pain Points

This resulted in:

Slower deployments and debugging
High Mean Time to Resolution (MTTR)
Increased operational cost
Heavy reliance on support teams

Technical Constraints

Developer's Journey — Before & After

Developer's Journey — Happy flow & Error flow

Key Decisions

1. Make system status the visual entry point not the service list

Insight

The first question in every debugging session was "is it broken?" Operators spent the first 30–60 seconds just scanning to answer this before they could begin investigating.

Decision

Designed a status-first service list with clear visual indicators (Online, Warning, Failed) and progressive disclosure for technical detail. Status answers the first question before anything else competes for attention.

Impact

Operators could triage the situation immediately. Time spent in the initial scan phase dropped significantly. Focus shifted from orientation to investigation.

Tradeoff: reduced information density at the list level, power users lost some at-a-glance detail. Accepted because speed in the critical first moment outweighed completeness.

2. Bring logs inside the product, but only when they're needed

Insight

Logs were the primary debugging tool. Accessing them required leaving the console entirely, which broke the diagnostic flow and increased MTTR with every incident.

Decision

Integrated a full-screen inline log viewer. Critically: logs appear by default only when a service is in error state, not during normal operation. This addressed both the developer need for speed and the operator concern about information overload.

Impact

Debugging became a continuous flow inside the product. Context switching was eliminated for the most common failure scenarios.

The tradeoff that almost didn't happen

Engineering pushed back on inline logs, concerned they'd overwhelm non-technical operators. The PM wanted a single dense page with everything visible. I prototyped both approaches and ran usability testing under simulated pressure. The dense layout failed: people couldn't scan it fast enough when stressed. But I didn't cut the logs, I made them contextually visible: hidden during normal operation, surfaced automatically in error state. Both concerns were resolved with evidence, not compromise.

3. Replace the multi-step wizard with a single-screen validated form

Insight

Configuration errors during provisioning, such as the wrong plan, region, or replication mode, were causing failed or expensive deployments. The cost per error was high. But developers found step-by-step flows frustrating: they're professionals who prioritise speed.

Decision

Replaced the wizard with a single-screen form: all fields visible at once for experienced users, but with tight inline validation catching errors before submission. Live pricing feedback and plan comparison kept the safety without the hand-holding.

Impact

Provisioning errors dropped significantly. Developer satisfaction improved the flow felt professional, not condescending. Both the business need for accuracy and the user need for speed were served.

Tradeoff: single-screen forms have a high cognitive load. Accepted, this was a workflow with professional users who preferred speed.

4. Make destructive actions feel safe enough to take confidently

Insight

Operators hesitated before restarting or deleting services, not because they didn't know what to do, but because the consequences weren't visible before committing. Hesitation was a performance cost in time-sensitive incidents.

Decision

Introduced context-aware confirmation patterns showing instance name, status, and consequences before execution. Not generic "are you sure?", precise, relevant information for that exact action.

Impact

UAT showed measurable increase in operator confidence. Accidental outages from misclicked actions dropped. Operators reported feeling more in control, not less.

Error Prevention, Immediate Feedback, Consistency & Standards

Design System

The system saved 12 weeks of engineering handoff time across the product portfolio. More importantly, it gave engineering one source of truth, reducing UI inconsistency across product lines and making cross-team collaboration significantly faster without requiring a designer in every room.

Outcome

Process

How I worked?

1. Frame the stakes

2. Shadow first

3. Model the system

4. Prioritise ruthlessly

5. Prototype + test

6. Ship + measure

What I would do differently?

I would involve operations engineers earlier in the research. I weighted developer feedback heavily early on and missed some operator-specific needs until mid-project. I'd also instrument the shipped product more aggressively from day one to build a continuous feedback loop rather than relying primarily on UAT snapshots. And I'd propose the design system infrastructure earlier; I started it mid-project, which meant the first few components needed retroactive system entries.