The old dashboard was right about one thing

The migration’s real enemy

Replacing a legacy product isn’t a redesign problem, it’s a trust transfer. The unified dashboard consolidated two aging test dashboards, and the migration goals were concrete: move every active team over before the deprecation date, holding retention above withheld: retention target and lifting the internal satisfaction index from withheld: satisfaction baseline toward its target. Every friction report was a vote against migrating.

Two frictions dominated the feedback analysis, and both were navigation: switching between builds took too many clicks, and global search — a power feature the old dashboard had — didn’t exist yet.

The friction, measured in clicks

The iterative debugger’s loop is brutal in its simplicity: run a build, open the failing test, fix the script, run again, compare. In the old dashboard, the next build was one click away — a persistent list alongside the detail view. The new architecture’s cleaner hierarchy had buried that loop:

For teams that run one session per build and iterate against a live stream, this wasn’t an annoyance — it was the whole product experience. The old dashboard was right about one thing: the next build must never be far.

Stealing well: the on-demand panel survey

The pattern we needed — a collapsible, on-demand list that coexists with a detail view — is solved all over the industry. I studied how the best versions behave: the analytics tool whose panel slides over without displacing content, the issue tracker whose sidebar remembers its state, the code editor whose explorer is a keystroke away. The survey wasn’t decoration; it settled interaction questions (dismissal, persistence, width behavior) before we drew anything.

Two explorations, one design-system fight

The first exploration mirrored the analytics tool’s show/hide interaction — visually familiar, and already supported as a pattern in our design system. The second placed the trigger beside the build name itself: spatially clever, and wrong. Reviewers from the design-system side made the case that it introduced a novel pattern for no gain; a peer reviewer added the sharper point — a control next to an entity’s name reads as an action on that entity, not as navigation.

The design system won, and should have. A migration is the worst possible moment to invent interaction patterns: the product is asking users to re-learn enough already. Novelty budgets are real, and this feature had no claim on one.

Stakeholder review then made the sidebar more ambitious: build rows gained quality-gate status and tags, so the panel answers “which build do I need?” rather than just listing candidates. The open question it surfaced — how the project switcher behaves when the sidebar crosses project boundaries — got its own design pass.

What shipped, and the friction that’s next

The sidebar design was adopted and the prototype carried the review: an on-demand build list available anywhere in the debugging journey, opening over the detail view, dismissible without losing place. Global search — the second named friction — was designed in the same initiative and sits next in line. The migration’s lesson holds beyond this product: when users say the old thing was better, they’re usually naming one behavior, not the whole thing. Find it, keep it, and the rest of the migration argues for itself.