Unifying install across an enterprise suite

At a glance

Role

UX designer on a common services layer shared by products in an enterprise hybrid-cloud suite.

Problem

Every product team had built its own install process. Users could not complete an install without help.

What I did

Distilled every product's install into one five-step model, then aligned the operator forms behind it around common fields, language, and defaults.

Outcome

The model became a certification requirement, so a product had to meet it to ship. A guide tool I built for the documentation teams also shipped, and teams published install guides with it.

The honest part

I designed and prototyped the Platform Installer, an on-cluster install experience. My previous work improved the process and instructions around the install. This was our opportunity to own the install experience, and it never shipped. It was researched, prototyped, and validated, but never staffed. I learned a valuable lesson: It is not enough for a design to be good, it needs the organizational backing to make it real.

Our platform’s products ran on a Kubernetes container platform, and their installation was notoriously difficult. It was a pain point significant enough to draw attention from senior leadership. Formal research put it beyond argument: users could not complete an install without substantial help.

The screens above are an illustration of installing a single operator. Spoiler, a product was never just one operator. It was usually an assemblage of many, some pulled in automatically others manually. They had to be added in a specific order, onto a cluster in a specific state. So users ran the sequence again, and again, and a single step taken out of order, or if anything failed along the way, caused the entire installation to fail or worse destabilized the cluster.

The problem had structure to it. Multiple product teams, each operating independently, had built their own install processes. Same platform, same customers, but different answers to “how do I install this?” I was a UX designer on a common services layer shared by all the products. The difficulty was that I was working largely outside those teams’ reporting structures. This meant driving consistency across groups that didn’t answer to me and often without dedicated product-management support.

I made an unusual investment for a designer: I learned the infrastructure itself. I taught myself to deploy Kubernetes clusters on-prem, and then learned what it took to install our products end to end. That fluency earned me the credibility I needed with my architects and engineers, and it meant my designs started from how the system actually behaved rather than how it was documented.

My first major swing at the problem was an install guide tool.

The documentation was one visible failure, working through it felt like a maze. Steps were underexplained, procedures would stop partway and link out to another section, or hand the user off to generic Kubernetes documentation that wasnt relevant to that user’s installation. It assumed knowledge our users didn’t have, and it read like a reference rather than a how-to.

But the writers weren’t being careless. No single linear document could cover every combination of product, capability, and starting cluster state, and every product team had its own method of installing on top of that. Faced with all of it, the docs hedged, and the hedging is what made them a maze.

So I built a tool for the documentation teams. They used it to construct install guides from the documentation they already had. Their users answered a short questionnaire covering which product they wanted, which of it’s capabilities they needed, and the state of the cluster they were starting from. Out came a linear, step-by-step guide assembled for that specific case: the right operators, in the right order, beginning from where the user actually was. Multiple product teams adopted it and published guides.

It worked, but it was aimed one layer away from the problem. The tool made the instructions better while the install process itself remained broken. Users got a cleaner map through the same maze. It was a tertiary solve: real value, genuinely adopted by our teams, but ultimately not fixing what was broken.

The generated guide, from my mid-fi design: answer a few questions about your cluster and storage, and get steps tailored to your situation, with honest time estimates and one task in flight at a time. Rebuilt with neutral branding for publication.

✕

So I went at the process. I installed the products myself, on my own clusters, and recorded each step as I performed it. That record captured what the documentation could not: the true order of operations, the places the instructions were wrong, and the steps no document mentioned at all. Then I pulled every product’s install apart and laid them side by side, looking for what they had in common. The work was unglamorous, hundreds of steps on a wall, but from the chaos there was a pretty clear pattern. Every product’s install, however different it looked, distilled into the same five consistent steps.

It was slow work, and it changed the conversations. I could talk about any product’s installation with authority, in detail, to the team that owned it. More importantly, I could show that team how closely their install already resembled everyone else’s, which made a shared specification possible.

The spine, redrawn from the comparison board: the five steps every product's install turned out to share, in the order they have to run. Product and vendor names neutralized for publication.

✕

The spine fixed the shape of the install, not what the user met inside each step. Every operator collected its configuration through its own form, and the forms had drifted apart. The same field went by a different name in each one. Defaults that could have been filled were left empty.

So the second half of the work was consistency inside the steps. We aligned the operator forms across the suite on common fields, common language, and sensible defaults. Getting the order right stops an install from failing. Getting the forms right is what makes a suite feel like one product.

The harder part was adoption. We had multiple product teams with their own goals, their own backlogs, and no obligation to listen to a designer outside their org. It moved through persistent, unglamorous influence: sharing the analysis openly, presenting the model in cross-team design and architecture forums, and grounding every conversation in the research and in my own hands-on installs.

The model was ultimately written into our product container certification requirements, which meant a product had to meet it to ship. That is the outcome I am proudest of on this project. A designer with no authority over those teams got the install model made a condition of release.

The Platform Installer

Every improvement so far shared a limitation: it was process and documentation. The install experience itself, the actual screens and workflow, lived in the underlying open-source platform, which we couldn’t control or affect. Its owners were receptive but honest: their resources were finite, and our needs weren’t their roadmap.

What they did have was a new extension capability that would allow for custom experiences inside the platform’s console, in the same navigation as the operator catalog users were already lost in. For the first time, we could own the install experience directly instead of writing better instructions around it.

That gave the Platform Installer its shape. The user installs exactly one operator, ours. It adds a single item to the console’s Operators menu, and from that point on they never install an operator by hand again. They open the tool and use it to install any product in the suite. The one install a user still has to perform by hand is the last one they ever have to perform by hand.

The name was part of that design. The user meets this tool in an operator catalog, at the moment their intent is “install this product,” so the listing had to answer that search and nothing else. Before, the catalog asked users to already know which of hundreds of operators they needed and in what order, a question the catalog was never able to answer. Now it only has to answer one: search for install, find the Platform Installer, install it once.

The five-step model is what made that possible: once every product installed along the same spine, one tool could drive any product’s install. The design goal followed from the problem. Everything the user was expected to know and get right, which operators, in which order, on a cluster in which state, had to move out of their head and into the tool. Four steps:

Storage. The install died here more than anywhere else, because the cluster had to be prepared before anything else could land. So the tool states the hardware and software requirements plainly, up front, and then provisions the storage stack itself rather than handing the user a checklist to go execute somewhere else.

Capabilities. A tabbed table of the suite’s products, each capability listed with a plain description of what it does. The user checks what they want, and selections accumulate across tabs with a running count, so capabilities from several products can be chosen in a single pass. This is the pivot of the whole design: the user chooses outcomes, not operators. Which operators that implies, and in what order they have to go on, is now the tool’s problem.

Review and deploy. One page: the storage that will be provisioned, the capabilities grouped by product and numbered in the order they will be installed, the licenses to accept, and one field for the entitlement key. Then a single Deploy button. That button is the twenty-one screens.

Monitor. A progress bar with an honest time estimate, next to a live install log that shows the real work in sequence, from provisioning storage through installing the operators to deploying the instances. It ends with Launch, which opens the product the user actually came for, rather than returning them to a console to find it themselves.

I grounded it in interviews with the customer-facing teams who lived the install pain secondhand, documented the pain points, and validated the happy path with the architecture team. Then, working with an intern developer, we built a working front-end prototype running on the platform. Not slides, a demo. I presented it widely, including to senior executives.

The Platform Installer, living in the platform's own console under Operators, one item below the catalog users used to get lost in. The user checks the capabilities they want, across products, and the tool works out which operators that requires and what order they have to go on in. Rebuilt with neutral branding for publication.

✕

What happened

The Platform Installer never shipped.

Not because the design failed. The prototype worked, stakeholder reaction was positive, and the approach was validated. It didn’t ship because getting it built required a staffed product team, and assembling one required organizational will that I, an early-career designer at the time, did not have the standing to summon. I ran a long campaign of playbacks and advocacy. It earned recognition and goodwill. It did not earn a development team.

I think what we had was a great idea. We were never able to get it built.

The lesson I took wasn’t cynical, it was structural: a good design is necessary but not sufficient. Shipping requires pairing the design with the organizational position to carry it. Influence without authority has real limits, and the answer isn’t to stop designing ambitious things. It’s to build the standing, the alliances, and the business case alongside the design, not after it. That lesson is baked into how I’ve worked since: embedding with architecture and product from day one, driving direction from inside the roadmap process rather than campaigning from outside it.

What this project shows

The five-step model shipped and became the suite’s standard: real consolidation, adopted through certification, still the shape of the install experience after I moved on. The guide tool shipped and helped teams communicate installs better. And the Platform Installer, though it never shipped, proved the technical approach and taught me the most durable lesson of my early career.

Between this work and my current platform work sits the same throughline: find the actual problem under the reported one, design the smallest structure that resolves it, and be honest about what it takes, beyond the design, to make it real.