← Back

CDRO — CD Release Orchestration Redesign

Design Manager — full product redesign, leading a team of three designers

Role: Design Manager

product-designuiux-researchdesign-leadership

Problem

CDRO's interface was built for pipeline configuration experts, but CloudBees needed to reach a broader engineering audience. At the same moment as the redesign mandate, the Honey UI design system was disbanded — the team lost its design-system foundation just as it faced its largest redesign challenge.

Solution

Ran a full double diamond with a team of three designers: discovery through delivery across the core CDRO UI, a new MyWork dashboard, a manual approvals widget, and YAML configuration surfaces. Adopted Material Design/MUI as the new design language, built a theming system on top of it, and prototyped each feature area before engineering handoff.

Understanding the product and the people using it

01 Discover

CDRO had grown into a highly capable but expert-only tool — powerful for pipeline engineers who already understood the system, opaque for anyone else. The redesign mandate started with understanding: who was actually using the product, what they were trying to do, and where the current interface was getting in the way. The early wires phase was diagnostic — mapping the existing information architecture, identifying friction surfaces, and beginning to sketch a new conceptual model for the dashboard and core workflows.

CDRO early wires — initial discovery, current-state mapping, and first redesign direction

001

CDRO basic UI and dashboard concept — early structural exploration

Problem

Release users had no consolidated starting point in CDRO. Pipeline status, task queues, and approval requests were scattered across separate views with no single home screen.

Solution

A modular, widget-based dashboard where users could configure their own view — adding, removing, grouping, and repositioning widgets to match their workflow. The widget library introduced a self-serve model for layout management.

002

Constraints, direction, and the MUI decision

02 Define

The constraint that shaped the project wasn't purely UX — it was the loss of Honey UI. With the design system disbanded, the team needed to adopt a new foundation: Google Material Design implemented through MUI. This wasn't a component swap; it was a decision about product identity. The early CBUI explorations — login surfaces, layout patterns, responsive breakpoints — were the first output of building that new design language from the ground up, establishing the visual grammar that every feature surface would inherit.

CBUI login — MUI design language applied to login surfaces

003

Wireframes and prototypes across four product surfaces

03 Develop

With direction established, the team moved into a sustained development phase across four interconnected surfaces. Managing three designers across these streams meant keeping each thread aligned to the same interaction principles while allowing each surface to evolve at its own pace. The microinteractions work captured a layer of detail that rarely makes it into portfolio decks: the small animations, transitions, and state changes that make a complex enterprise UI feel responsive rather than mechanical.

CDRO microinteractions — animation and state-change detail

004

A single view for everything a release engineer owns

MyWork Dashboard

The MyWork dashboard was the most user-facing feature of the redesign — a consolidated view giving release engineers a single starting point for everything they owned. The 0.2 iteration reflects the team's learning cycle: early dashboard concepts tested against real workflows, with structure and hierarchy adjusted based on how engineers actually moved through their day.

MyWork dashboard 0.2 — release engineer home view

Problem

The 0.1 dashboard prototype had a practical flaw: at smaller widget sizes, the header control bar overloaded with icons, making it hard to act on the right control. The quick start guide was also non-sequential — unclear which step to do next.

Solution

Consolidated widget header controls to reduce icon count at compact sizes, restructured the quick start guide into a sequential task model, and refined the drag-and-drop interaction so users could reposition widgets without accidentally triggering other controls.

005

Widget design and iterative versioning

Manual Approvals

Manual approval workflows are a critical control point in release orchestration — any team with compliance requirements or staged rollout processes lives in this UI. The widget design worked through the full interaction arc: requesting approval, notifying approvers, displaying status, and handling the edge cases. Clean enough for engineers encountering it for the first time, precise enough for pipeline engineers running hundreds of approvals a week.

CDRO manual approval widget — full interaction arc and approval flow

Problem

Release users in compliance-heavy environments had to manage approval queues manually, but CDRO had no consolidated surface for it. Requests were buried in the pipeline view, and bulk operations weren't possible at all.

Solution

A two-layer approval system: a dashboard widget for quick individual approvals and status overview, and a dedicated data grid in the notification center for bulk editing, filtering, sorting, and column management across large approval queues.

006

CDRO 0.4 — manual approval widget iteration

Problem

The previous approval widget required users to navigate to the pipeline view to approve requests — interrupting their workflow every time they needed to clear an approval, even for simple cases with no ambiguity.

Solution

Added inline approval from the dashboard widget (data grid with pagination, quick preview, undo), a summary toggle for users who only need a count, and a full notification center with tabbed management and bulk actions including per-task comment and review.

007

AI-assisted release management

AI Integration — BeeBot

BeeBot was an exploratory prototype: what would AI-assisted release management look like inside CDRO? The exploration ran in parallel with the core redesign work — a signal that CloudBees was thinking about LLM integration seriously, and an early test of how a conversational layer could surface pipeline context without replacing the visual interface.

BeeBot — AI-assisted release management prototype

Problem

CDRO dashboards required manual widget configuration — users had to know which metrics existed and how to surface them. Getting meaningful pipeline visibility required significant product knowledge before the dashboard could deliver value.

Solution

A conversational AI layer that interpreted natural language requests — 'what was our release frequency this month vs last month?', 'add failed runs', 'create a DORA metrics group' — and built the corresponding widget layout in real time, without requiring users to navigate the widget library.

008

MUI theming system and layout across breakpoints

Responsive Design & Theming

Theming was a core CBUI concern from the start — the platform needed to carry the CloudBees brand identity while sitting on the MUI Material Design foundation. The theming work established the token layer: how Material Design colour roles mapped to CloudBees semantic tokens. The responsive layout work ran alongside it, ensuring the layout system held from full desktop to compact views without breaking the visual hierarchy.

CDRO theming — Material Design token system and CloudBees brand layer

Problem

Material Design's default colour system needed adapting to carry the CloudBees brand identity without overriding the accessibility guarantees and semantic logic baked into Material Design's role-based token model.

Solution

Tested foreground/background combinations across CloudBees brand colours, identifying how illumination behaviour varied by hue — informing the mapping between CloudBees semantic tokens and Material Design's colour roles.

009

CBUI responsive layout — fluid grid across breakpoints

010

CBUI breakpoints — responsive behaviour across viewport sizes

011

Configuration surface design

YAML Configuration

YAML is the power-user surface of any CI/CD tool — where engineers define pipeline behaviour directly in configuration. The CDRO YAML surface design tackled how to make configuration editing feel intentional: syntax awareness, inline help, and a layout that kept the editor connected to the visual pipeline view it was modifying.

Final designs and engineering handoff

04 Deliver

The deliver phase was a handoff exercise as much as a design one — working closely with the engineering team to ensure MUI implementation matched the design intent, component by component. The design-to-engineering process first established by Honey UI — specs, annotations, and a shared token language — adapted to the MUI context and carried forward into production across every CDRO surface the team had redesigned.

Part of the CloudBees selected work