The WHY: Visibility Is a Myth
“I understand my enterprise infrastructure completely, very well, all the time.” Said no system admin ever.
Infrastructure visibility at enterprise scale is notoriously poor. Industry surveys (e.g., IDC 2022 Cloud Migration Survey) report that 64% of enterprises lack full visibility into dependencies when planning migrations. Gartner estimates that over 70% of cloud migration failures stem from incomplete discovery and dependency mapping. [1][2]
The reality is messy:
- Unknown ports silently throwing errors.
- Zombie VMs consuming resources but serving no purpose.
- Spaghetti-like interdependencies where one app secretly ties to three others across multiple regions.
Before redesign, the Discovery Client surfaced these as flat lists of VMs and APIs. Accurate, but not actionable. It was like being handed the Latin names of plants when what you really need is a map of the forest.
This was the WHY: We weren’t just onboarding a product into GCP’s style guide. We were solving the fundamental gap between what exists and what admins need to see in order to migrate with confidence.
[1] Gartner, Why Cloud Migrations Fail (2021).
[2] IDC, State of Cloud Migration Survey (2022).
The Process: Designing With, Not For
Our approach blended infra constraints with UX empathy:
- Research with sysadmins: Contextual interviews and think-aloud studies revealed trust gaps. A common refrain: “Don’t show me all the servers. Show me the loose thread that will unravel the sweater.”
- Prototyping complex flows: Service account permissions, API grouping, Guest OS credential prompts.
- Iterative validation: Quick mocks tested in real enterprise contexts, refined every week.
The design ethos: Don’t flatten complexity. Surface it in ways people can reason with.
Narrative One: The Illusion of Control
Imagine a dashboard that insists everything is green. Meanwhile, a rogue process maxes out CPU on a forgotten VM in a shadow subnet. By the time alerts arrive, it’s too late. That’s the illusion of control admins lived with.
What I Did
- From flat lists → structured narratives: Redesigned API discovery so instead of surfacing hundreds of raw Compute or Networking APIs, the system grouped them by application tier (frontend, middleware, DB).
- Usable tissues: APIs became connective tissue. Hovering over one API surfaced its dependencies on service accounts, workloads, and other APIs. This turned cryptic entries into narratives admins could follow.
- Migration-ready clusters: Instead of 2,000 isolated dots, admins saw 12 clusters of related services, prioritized for sequencing.
Result
Admins could finally see *why a service mattered*, not just that it existed. The system stopped dumping puzzle pieces and started showing the picture on the box.
Narrative Two: From Gardens to Ecosystems
Gardens are simple: water, prune, repeat. Enterprise infra is not a garden — it’s a forest. Self-healing, interdependent, tangled. A single fallen tree can destabilize the whole canopy.
What I Did
- Redesigned Service Account flows: Visualized the relationships: *Service Account → Service Account Key → Google API Access*. Instead of raw JSON keys, admins saw *who needed what, and why*.
- IAM transparency: Simplified permission prompts. “This app needs X permission because it calls Y API on Z VM.” Replaced opaque requests with clear justifications.
- Credential modelling for Guest OS: Designed progressive disclosure flows. Casual users saw simple permission prompts. Power users could expand into least-privilege command-line scripts. Always with revocation controls.
- Zoomable layers: From the canopy (swarm of thousands of VMs) down to the trunk (single VM OS processes). Dependencies lit up like fungal networks, making hidden risks visible.
Result
Admins trusted the system. Instead of “Grant root access?”, they saw *what would be collected, why it was necessary, and how to revoke it*. The redesign turned paranoia into partnership.
[4] Google Cloud, Best Practices for Service Accounts.
[5] NIST, *Principle of Least Privilege* (SP 800-53).
Narrative Three: The Pipeline Nobody Sees
Migration is pipelines: data from VMs → inventory → insights → UX. Before redesign, this pipeline was like a leaking basement pipe: telemetry dripped through, got messy, and surfaced as raw, contextless logs.
What I Did
- Guest OS signal prioritization: Partnered with engineering to isolate ~20 signals that actually matter for migration readiness (e.g., steady-state CPU, open ports, dependency maps) from thousands of possible datapoints.
- Contextual surfacing: *Port 5432 open* became: *This VM runs PostgreSQL; services A, B, and C depend on it*. Signals became stories.
- Explainability: Every migration recommendation linked back to data. *This VM moves first because its DB dependency supports three clusters*.
Result
The pipeline became reliable, transparent, and actionable. Migration prep times dropped. Failed discovery jobs reduced. Admins and engineers trusted insights that once looked like guesswork.
Results: Why This Matters
This work was never about making a dashboard “prettier.” It was about collapsing the gap between infra realities and UX design.
- For admins: From swarms of scattered VMs to structured, clustered ecosystems.
- For engineers: From black-box outputs to transparent, explainable insights.
- For enterprises: From risky migrations to strategic, planned transformations.
In short: we turned spaghetti into structure, swarms into signals, and forests into maps.
And maybe, for the first time, gave admins something close to that mythical state of: “I understand my entire infrastructure completely, very well, all the time.”