Evolving a design system

Habanero was Salsify’s design system, and it once had an established governance process. It was paused after the designer leading the system left. The role wasn’t backfilled, so design system work was folded into another designer’s role, competing with existing feature work.

Without that process, the system slowly drifted. The Figma library fell out of sync with production, so designers could specify variations that engineering couldn’t reliably build. Teams also lacked a consistent way to propose changes, evaluate new patterns, or manage exceptions, so one-off solutions could accumulate and fragment the system.

We initially tackled the visible problem: rebuilding the component library. But that work raised a larger question:

I co-led a team-wide rebuild of roughly 50 components, using Storybook and production behavior as our reference. My contribution centered on making the work executable: organizing dependency-aware tasks, coordinating reviews, documenting expectations, and keeping design and engineering aligned. We launched the rebuilt library in March 2025, and designers began using it across the team.

One recurring tradeoff was how much flexibility to expose. In engineering review, we simplified button groups by replacing combinations of toggles with clear label-only, icon-only, and icon-plus-label variants, while defining missing states and sizing behavior. The goal was to offer the flexibility the product supported, not every configuration Figma could make possible.

We also stress-tested the library with eight designers recreating actual product screens. Our bug bash surfaced 106 issues, from missing states to resizing and overlay behavior. We fixed launch-priority problems and separated future enhancements from immediate needs. For example, an obscured date-picker overlay prompted clearer canvas-stacking guidance.

A refreshed component library could still drift if teams lacked a shared way to decide what belonged in it. Through conversations with designers and engineers, we heard recurring uncertainty around ownership, reviews, and when a need justified a new component versus an extension or a local exception. For example, engineers described forking an entire navigation component tree to support one product-specific behavior. Those local copies did not automatically inherit updates from the shared system, adding maintenance overhead.

This exposed a real tension. Habanero couldn’t absorb every request without losing the consistency it existed to protect, but making it too hard to add or adapt components just pushed teams to work around it. Exceptions would always exist; the goal wasn’t to eliminate them, but to make them deliberate and visible instead of accidental. We needed to make the path for proposing, evaluating, and releasing changes explicit, without turning the design system into a bottleneck.

With limited capacity dedicated to Habanero, we needed a governance process that could work within existing team structures rather than depend on constant centralized oversight. Three ideas shaped the model.

The previous process stalled when its one owner left, so we designed for distribution from the start. Any team’s designers and engineers could contribute, supported by a small steering group providing guidance, consistency, and review. Habanero would be a shared responsibility: if a team proposed a new component or improvement and it was judged valuable both for their work and for the wider system, that team would take on building it. We proposed three volunteers on a rotating basis, so anyone interested could learn the process, starting with two of us for a quarter or two before assessing request volume. The goal was to distribute responsibility without sacrificing accountability.

When the library needed a tweak or a component was wrong, no one knew the quickest way forward, and engineers sometimes forked components rather than wait. We created a decision framework to help teams ask whether an existing pattern solved the problem, whether an enhancement or variant was appropriate, and when a new shared component or a documented exception was justified. The purpose was to make intentional reuse easier than ad hoc proliferation.

For example: Will this component occur multiple times within the product? Does it solve a problem that cannot be resolved by existing components? Do we need to develop it as a new component or as a variant?

I translated that approach into a governance infographic and contribution checklists, defining the steps and responsibilities across discovery, design, build, review, and release. A ticket-based intake would replace ad hoc Slack messages, giving every request a clear path and a visible record.

Interviews showed designers wanted to hear about changes before they landed, not after. The plan included release updates in Slack and the front-end forum, a regular roundup of what changed, and guidance on which forum to use for which discussion.

Reviewing the proposal with front-end engineers revealed a weakness in our initial framing: it made design and engineering look like sequential handoffs. In practice, component architecture, APIs, and constraints often needed to be worked through together before development began.

We revised the model to show parallel collaboration and earlier technical checkpoints, rather than treating engineering as a final approval stage. We also made expectations around review, sign-off, and release clearer, and planned to make some steps required rather than recommended: a designer would review and sign off on each pull request before it merged, and engineers would flag any that merged without design review. This was a process design exercise in its own right: listen to where the proposed workflow failed, then adjust the model to reflect how work actually happened.

Ownership was one of the clearest gaps. No one was explicitly responsible for bringing a component forward for a governance discussion: designers sometimes looked to engineers to raise it, while engineers saw it as squarely design’s call. We made ownership explicit at each step. For example, the designer would own bringing a component forward, consulting engineering as needed.

The rebuilt component library launched and was adopted across the design team. The governance framework was developed and aligned with stakeholders but had not formally launched. Like much of the design system work, it was a part-time responsibility alongside my product work. When a higher-priority initiative required my full attention, I paused on the remaining rollout.

This work changed how I think about design systems: reliability depends on clear ownership, decisions, and relationships around components as much as the components themselves. Given more time, I would have wanted to test the governance process in real contribution cycles and learn where it reduced friction or added it. I’d also follow through on making it lighter to use. We’d planned ticket templates with required fields and Jira notifications so contributing felt more automatic, but didn’t get to implement them.

We completed this work before AI became widely adopted in everyday design and engineering workflows. If I revisited it today, I’d explore how AI could help keep Figma and code aligned, identify opportunities to reuse existing components, and reduce the manual effort of reviewing contributions, ultimately making governance more sustainable for a team with limited capacity.