Design Systems — 2023
Helix Design System
Four products, four button styles, three date pickers and no shared vocabulary. A system built to be adopted, not admired.
One component library replaced four divergent product interfaces.
- Client
- Helix Software
- Discipline
- Design system architecture and governance
- Engagement
- 7 months, Mar to Sep 2023
- Team
- Four product designers, six engineers across three squads
Overview
Helix sells four B2B products that grew from three acquisitions. A customer using two of them saw two different date pickers, two different notions of what a destructive action looks like, and two different words for the same object.
I spent seven months building the shared system, and roughly half of that time was spent on adoption rather than on components. A system nobody uses is a very expensive Figma file.
Role
Design systems lead, contract
7 months, Mar to Sep 2023 · Four product designers, six engineers across three squads
- Interface inventory across all four products
- Token architecture covering colour, type, spacing, radius and elevation
- Design and specification of 48 components with their full state matrices
- Contribution model, review process and deprecation policy
- Documentation site structure and every usage guideline in it
- Migration sequencing with the three engineering squads
Problem
The audit found 31 button variants, 9 modal patterns and 14 shades of grey in production. None of that was anyone's fault. It was four teams solving the same problems independently, under deadline, for nine years.
The harder problem was political. Two previous attempts at a shared library had failed, both because the system was designed centrally and then handed over. Designers found it did not cover their cases and quietly went around it. I had to design the governance before I designed a single component.
Process
Inventory as a shared reckoning
Rather than audit alone, I ran the inventory as three workshops with the product designers. When a team counts its own 31 button variants, the argument about whether a system is needed simply stops happening.
Tokens before components
Three tiers: primitive values, semantic aliases, and component-specific tokens. Product teams consume semantics, never primitives, so a change to the brand grey does not require 400 file edits. This decision is the reason the eventual rebrand took nine days instead of a quarter.
Components earn their place
Nothing entered the library until it appeared in at least two products. That kept the initial set at 48 rather than 200, and made every component defensible when a team asked why theirs was not included.
A contribution path with real teeth
Any designer could propose a component through a template with two required product use cases. Review happened every second Thursday with a published decision, including the rejections and the reasons. Predictable answers matter more than fast ones.
Migrating by surface, not by product
We migrated all settings screens across all four products, then all tables, then all forms. Cross-product surfaces meant every squad felt progress in the same fortnight, which kept the effort funded.
Outcomes
- 48
- Components in the shipped library
- 31 → 1
- Button variants in production
- 9 days
- To roll out a full rebrand across four products
- 86%
- Of new feature work built from the library within six months
The adoption figure is the one I care about. It came from a monthly component-usage report I set up during the build, so the team could see drift early rather than discover it a year later.
Gallery
Tools
- Figma
- Storybook
- Style Dictionary
- Zeroheight
- GitHub
