Lifecycle Editor Redesign · Octopus Deploy · 2026

The first thing every Octopus user had to do -
and 44% of them couldn't.

I redesigned the Lifecycle editor - Octopus's core setup step - running two competing interactive prototypes to find an approach that actually worked.

Senior Product Designer Octopus Deploy · Yosemite team Solo design lead 2026

The redesigned Lifecycle editor - building a lifecycle with the Kanban phase builder.

Context

Why Lifecycles matter - and why this work mattered more

Development
→
Staging
→
Production

In software deployment, a lifecycle defines how a release moves from code to production - which environments it passes through (Development, Staging, Production), in what order, and whether each step deploys automatically or requires a manual sign-off. Every project in Octopus needs one. It's one of the first things a new user has to configure, and it shows up throughout the product: next to the deployment process, during project creation, and in trigger configuration.

The lifecycle editor hadn't been updated in years. It didn't reflect Octopus's current design language, and it forced users to think in abstractions - phases, progression rules, retention policies - before they could express a much simpler intent: which environments does my release pass through, and in what order?

Why this work mattered in 2026: Octopus was mid-transition from an Enterprise sales-led motion to a Product-Led Growth model - self-service sign-ups, self-service configuration. In a PLG world, there's no sales engineer to walk a new user through Lifecycle setup. If the UI doesn't teach itself, users churn. The Lifecycle editor was one of the most critical friction points in that sequence.
My role
Senior Product Designer - Yosemite team. End-to-end ownership: research, design, prototyping, copy, Frontend Foundations sign-off.
Collaborator
Oleg Turbovsky (Lead Engineer)
Discovery

Two research streams, the same finding

"Users don't think in phases. They think in environments and sequences."
Research stream 1

PURE expert evaluation

An expert "secret shopper" evaluation (PURE method, run by the Associate Design Director in their first week at Octopus) walked through the full onboarding experience cold. Key findings relevant to Lifecycle:

Sam Irons, "Twice I've failed to deploy my first K8s project - a noob's secret shopper evaluation of Octopus Deploy", Confluence
Research stream 2

Synthetic onboarding study - 18 participants, 3 personas

"Lifecycle" was the most persona-split term in the product. Familiar to enterprise/.NET users, but opaque to startup and container-native users. 8 of 18 simulated participants were confused by it - a higher confusion rate than any other term or concept in the study.

The study confirmed that the problem wasn't nomenclature. Users who understood the word still struggled with the interaction model. The issue was conceptual: the UI presented phases and rules, when users were thinking about environments and sequences.

Sam Irons, Results - Synthetic onboarding research, Confluence
Confluence - PURE evaluation: Twice I've failed to deploy my first K8s project

Sam Irons' PURE evaluation - "Twice I've failed to deploy my first K8s project" - the expert audit that rated the lifecycle flow "Not Usable" at multiple points

Field research · User calls

A user showed us their mental model - unprompted

During a research session, a participant shared their screen without being asked to explain how they think about deployment. They navigated to AWS documentation on cell-based architecture and pointed to this diagram.

They call them waves - not phases. Environments grouped into sequential stages, each broader than the last, with a clear left-to-right flow. It's the Kanban mental model, described spontaneously by someone who had never seen the design.

User call screenshot - participant shares AWS cell-based architecture docs showing deployment waves (Wave 1 through Wave 5) with environments flowing through columns

A research participant shares their screen mid-call to explain how they think about deployment - "waves" of environments in a left-to-right sequence. Unprompted. This is the Kanban layout.

Three problems

What was broken - specifically

1
No hierarchy between what matters and what doesn't
The core job is simple: define a release flow from Dev to QA to Production. But the editor presented that alongside retention policies, deployment rules, and environment minimums - all at the same visual level. Users couldn't tell what was essential from what was optional, or where to even begin.
2
Phase / environment relationship is invisible
Users couldn't tell at a glance which environments belonged to which phase, or in what order releases moved through them. The UI required mental mapping that the interface didn't support.
3
No visual representation of the pipeline
Deployments flow - from dev to staging to production. The UI showed a flat list. The interface and the mental model were in direct conflict.
Before · Original UI

Watch someone try to build a lifecycle in the old card UI

Describing the friction is one thing. Watching it happen is another. The recording below shows the experience of building a lifecycle from scratch using the original card-based editor - the exact flow users were expected to complete at onboarding.

Building a lifecycle from scratch in the original card-based UI. This is the flow every new user was expected to complete.

Solution

Where I started: two sketches, two worlds

The whole thing started with two sketches. One explored a form-based approach - a phase with a name field, environment selector, and a toggle for manual or automatic promotion. The other explored a Kanban model - columns as phases, environment cards dragged in from a panel. Both took minutes to draw, but they represented genuinely different mental models.

Rather than choosing one based on intuition, I built both as fully interactive prototypes - real HTML/CSS/JS builds, drag-and-drop working, toggles clickable - and let real users and stakeholders tell me which one worked.

"I built two competing interactive prototypes - not mockups - to find out which mental model actually worked."
Form layout
Sequential, explicit. A phase has a name, an environment list, and toggle settings. Familiar to power users of the existing editor. Works at any screen resolution.
  • Familiar to existing Octopus users
  • Resolution-agnostic - works in small windows
  • 2 of 3 session participants with a stated preference chose this as "more straightforward"
  • Doesn't visualise the pipeline - still a list mental model
Form layout sketch - phases with name field, select env dropdown, manual toggle
Kanban phase builder
Direction chosen
Phases as columns, environments as cards dragged in from a persistent panel. Direct manipulation. Spatially represents the deployment pipeline.
  • Matches the deployment pipeline mental model - you can see the flow
  • Environments are first-class objects, not menu selections
  • Participants naturally created all phases first, then populated them - a behaviour the Kanban layout supported directly
  • Phase settings are cut off at typical screen resolutions - a critical discoverability issue requiring further work
Kanban layout sketch - columns as phases, environments dragged in from left panel
User testing · Qualitative sessions

Participants tested both. The Kanban felt different.

I ran qualitative sessions with both prototypes - giving participants the same task with each and watching how they moved through it. The results weren't a clean winner, but they pointed clearly in one direction.

The Kanban prototype got a consistently different reaction. Participants described it as feeling more intuitive - environments as physical objects you place, rather than values you type into a form. Several used the word fun. The drag-and-drop interaction made the mental model tangible in a way the form couldn't.

The form was faster to complete and more familiar to users already in the Octopus ecosystem. But familiarity isn't the same as clarity - and the goal was a tool that new users could understand on their own, without a walkthrough.

The qualitative signal was clear: Kanban matched how people wanted to think about the problem. That became the direction.

"The Kanban felt more intuitive. More fun. That's not a soft signal - that's the mental model fitting."
Lookback session - Zachary Perales testing the Kanban prototype, transcription visible on the right

Lookback session - a participant working through the Kanban prototype. Transcription on the right: "I think it's clear and more straightforward and intuitive."

Interactive prototypes

Try it yourself

Interactive prototype · Live
Form layout
The competing approach - sequential, explicit, familiar. The same tasks as the Kanban build but expressed as a structured form. This is what session participants compared it against.
Try it ↗
Interactive prototype · Live
Kanban phase builder
Drag environments from the panel into phase columns. Hover to see the visual connection between the inventory and the drop zone. Not a mockup - a working build.
Try it ↗
Two approaches, one winner

What a completed lifecycle looks like in each

Both approaches reached a finished state. The Kanban board became the primary direction - it matched the mental model users already had, made the pipeline visible, and felt more intuitive in testing. The form layout deserves an honourable mention: it was clean, familiar, and would have been a significant improvement over the original. It just wasn't as good.

Kanban lifecycle creator
Completed lifecycle in the Kanban builder - phases as columns with environments dragged in

The Kanban approach - phases as columns, environments placed inside them. The pipeline is visible the whole time.

Honourable mention · Form layout
Completed lifecycle in the form layout - structured fields for each phase

The form approach - structured and familiar. A real improvement, just not the winner.

End-to-end flow

What the redesign actually changed

The new lifecycle editor isn't a reskin of the old one. The interaction model, the information hierarchy, and the mental model it's built on are all different. These are the four ideas that drove it.

1
Hierarchy through progressive disclosure
The core job is simple: give your lifecycle a name, build its phase structure, add your environments. That's it. Everything else - retention policies, minimum environments, promotion modes - is real configuration, but it's secondary. The redesign puts it in a separate layer. The main flow stays clean. Settings are available without being in the way.
2
A mental model that just fits
Phases as columns. Environments placed inside them. Releases flowing left to right. This is how users already described deployment when we asked them - before they'd ever seen the new design. The Kanban layout didn't teach a new model. It matched the one users brought with them. When that happens, the UI stops being something users figure out and starts being something they just use.
3
Building a lifecycle is the same as seeing it
This was the key insight. In the Kanban builder, you're not filling out a form that will eventually produce a deployment pipeline - you're looking at the pipeline while you build it. Drop Development into a phase, add Staging, set Production to manual. The board you're assembling is exactly what your releases will move through. That visual connection between configuration and outcome was entirely absent before. It became one of the strongest signals in user testing.
4
Phase settings stay in context
When a phase needs configuration - auto-deploy vs manual, minimum environments before promotion, retention policy - a drawer opens alongside the board. The lifecycle stays visible. You can see which phase you're configuring and how it sits in the rest of the pipeline. Settings feel like part of the flow, not a detour out of it.

The full lifecycle creation flow - from blank canvas to a complete, configured pipeline.

The lifecycle list - before and after

The lifecycle list is the first screen users land on. In the old UI, every lifecycle looked the same - a name, then a tree of phases and environments nested underneath. There was no description, no sense of what the lifecycle did or how releases moved through it. Users couldn't scan the list to orient themselves or decide which lifecycle to use for their project.

The redesign treats the list as a map. Each lifecycle shows its description, its phases as distinct columns, the environments inside each phase, and whether each environment deploys automatically or requires manual approval. At a glance, you understand the shape of a lifecycle without opening it.

Before
Old lifecycle list UI - tree view showing phases and environments with no descriptions or visual pipeline

A flat tree. No descriptions. No sense of what each lifecycle does or in what order releases move through it.

After
Redesigned lifecycle list - cards showing description, phase columns, environments with Auto/Manual badges

Each lifecycle tells you what it does. Phases as columns, environments inside them, Auto/Manual badges visible - the pipeline is readable at a glance.

Design decision

Phase settings go in a drawer

Phase settings - retention policies, minimum environments, promotion mode - needed a home. A modal was the default option, but it hides the lifecycle behind it, which is exactly the context a user needs when configuring a phase. A side drawer keeps the board visible, gives more vertical space for the settings, and treats configuration as part of the flow rather than an interruption of it.

It also fits how Octopus already handles contextual panels elsewhere in the product - the step editor, runbook settings. No new pattern to learn.

Phase settings drawer open alongside the lifecycle Kanban board

Phase settings open in a drawer - the Kanban board stays visible behind it.

UX Copy

Writing for states that had never been addressed

Copy is part of the design - not a phase that happens later. I wrote UX copy for four states that previously had none. Each piece of copy had to do real work: orient a confused user, explain a concept without jargon, or handle an edge case gracefully.

"The states that needed copy the most were the ones that had never been written."
Kanban phase builder - phases section and environments panel annotated
1
2
1
Phases
"Phases define the environments your release must pass through and the conditions for progressing between them."
First-time explanation of what phases do - without using the word "lifecycle" to explain itself. Written for a user who has never opened the editor before.
2
Environments
"Drag an environment into a phase to add it to your deployment flow."
An invitation, not an instruction. Tells users exactly what to do in the Kanban layout - specific to the drag interaction, not copy-pasted from the form flow.
Results

Everything shipped

✓
Kanban phase builder shipped Drag-and-drop lifecycle creation live in production, built with dnd-kit. The primary design direction from testing.
✓
Redesigned lifecycle list shipped Every lifecycle now shows its description, phases, environments, and Auto/Manual configuration at a glance - without opening the editor.
✓
Phase settings drawer shipped Settings surface in a side drawer, keeping the Kanban board visible and configuration in context.
✓
All UX copy shipped Four states written from scratch - phases description, Kanban empty state, default lifecycle description, edge-case snackbar.
✓
Frontend Foundations sign-off Design system compliance verified, implementation feasibility confirmed, full sign-off received.
Reception

The feedback was clear

The redesign landed well internally. The engineering team found the Kanban paradigm straightforward to implement, and the drag-and-drop interaction held up cleanly in production. The design passed Frontend Foundations review without revision requests - a bar that's explicitly about system coherence and production quality, not just visual polish.

User testing gave the clearest signal: participants who used both prototypes described the Kanban as feeling more intuitive and - notably - more enjoyable to use. That's not a soft result. When a configuration UI is described as fun, it means the mental model fit.

"More intuitive. More fun. That's not a soft signal - that's the mental model fitting."
"This was a complete UI overhaul - and it had to be. The old editor wasn't just dated; it asked users to think in the wrong way. When the mental model is wrong, you can't fix it with a coat of paint. You have to rebuild the whole surface around the right idea."
Shoham Samuel · Senior Product Designer · Octopus Deploy