Artifact Deployment Workflows

What problem existed?

The deploy page brought several concepts together on one surface: ecosystems, version selectors, deployment status, and artifact management. People could finish their tasks there.

The relationships between those concepts were where design could add the most. A version selector applies within a specific ecosystem, and version terminology varied across the surface, so there was room to make what a user is acting on clearer and more consistent.

Why did it matter?

Deployments are operational workflows. People need to understand what they’re acting on before they can act with confidence.

When ecosystem, selector, version, and deployment status sit close together, the relationships between them carry a lot of the meaning. The job was making those relationships clear, working with what was already there.

What constraints existed?

• The underlying deployment model already existed and couldn’t be reshaped.
• Different ecosystems carry different selector behaviors and versioning conventions.
• Existing deployment and artifact APIs had to stay intact.
• The Add Artifact flow had already set terminology and patterns that users were learning elsewhere in the product. Consistency mattered.

What role did I play?

I led the UX work for the redesign and took the design into the frontend, which engineering reviewed and shipped.

My focus was the deployment mental model: how people move through ecosystem, version, state, and action, and how to make the experience more consistent using the infrastructure that already existed.

What options were explored?

Two real directions came out of the work.

• The richer one. An “intent abstraction” model that surfaced what a user wanted to do (deploy, pin, roll back, preview) and let the system pick the right strategy underneath. It was powerful, but it depended on new backend work, new payload shapes, and would have introduced loading-state and performance tradeoffs.
• The lighter one. A frontend-only redesign that sharpened the existing concepts without changing the engine. It ships sooner and does not preclude the richer direction later.

The lighter direction won for the first iteration. The intent abstraction stayed on the shelf as a future move.

What tradeoffs were considered?

The biggest tradeoff was depth versus shippability.

The richer model was philosophically right (it matched how users think about what they’re trying to do), but it would have shipped slowly and made every action wait on a backend round-trip. The lighter model moved the same mental model forward inside the existing system. Users would feel the difference. Engineering wouldn’t have to rebuild the engine to deliver it.

A second tradeoff was new terminology versus existing patterns. Consistency won. The deploy experience deliberately echoes the Add Artifact flow so users learn one deployment vocabulary across the product.

How did UX, engineering feasibility, and business strategy intersect?

The most useful improvements came from aligning all three.

UX focused on making the deployment model easier to understand. Engineering focused on reusing existing APIs, selectors, and ecosystem logic instead of building new ones. The business gained a friction reduction in a core operational workflow without funding a platform rebuild. A small set of structural changes paid back across the page.

How was AI used in the process?

I used AI to explore alternative workflow shapes quickly, challenge my own assumptions about what users were doing, and prototype implementation approaches.

It accelerated iteration. Decisions still came from product constraints, existing platform behavior, and the user mental model. AI was most useful for quick back-and-forth on alternatives, which compressed the loop between an idea and a testable artifact from days to hours.

What was learned?

People don’t think about deployments as rows in a table. They think about:

• Which ecosystem am I working in?
• Which version selector am I using?
• What is deployed right now?
• What action do I want to take?

Once the interface answered those four questions, a lot of friction went away. Improving terminology and the relationships between concepts often has more impact than adding new features.

I also learned to keep the richer direction on the shelf. The list of parked-but-still-good ideas turned out to be valuable on its own.

What was the outcome?

A redesign that clarified the deployment mental model with no backend changes. No new queries. No new payload shapes. No coordinated backend rollout.

• Sensible ecosystem defaults. Users start inside the right setup for the ecosystem they’re in, instead of a blank slate.
• A guided selector replaces the blank text input. Plain-language descriptions of valid values. Warnings for risky selectors.
• Optional historical suggestions drawn from cached deployment history.
• A free-form escape hatch via a “Specify…” affordance for power users.
• Harmonized terminology with the Add Artifact flow, so the same words mean the same things across the product.
• Common deployment actions surfaced directly. Advanced capabilities preserved without making them the primary path.

A registry lookup is still on the wish list. It would unlock available-versions surfacing, validation, and resolution preview. The redesigned UX doesn’t depend on it anymore. The shape is ready when the registry is.