B2B SaaS · Design System
In progress
·
2026
Role
Product Designer, UX/UI
Team
DS guild: 4 designers (me included)
Timeline
2026 · ongoing
Company
Performance management platform
Signals
business units served
components implemented in code
of style properties tokenized in the Figma file (internal audit)
Competencies
Design Systems
Delivery & Quality
Context
The company had wanted a design system for a while, but with no dedicated design or engineering team for it, the work kept stalling. Products across ten business units were being built on their own patterns.
My role
I create and adjust tokens, build components, write documentation and implement them in code, working alongside the other three designers in the guild. Everything is validated together: nothing ships without another designer’s review in Figma and in code.
Problem
There was demand for a shared system and nobody whose job it was to build it. Any solution had to work without dedicated people, across ten business units, and without letting quality slip.
Discovery
How might we
Solution
We created a design system guild to build and evolve one cross-BU system. Four designers take part actively, and every component is validated by other designers in Figma (component and documentation) and in code.
Claude as part of the workflow. We wrote skills that help create components, generate documentation, and open and review pull requests on GitHub.
Design first: we brief Claude on what the component should be and how. It builds it, and we check that it’s correct, works for the business units and has tokens applied properly.
Then docs: Claude drafts the documentation, we review it, and once approved we ask Claude to implement the component and open the pull request.
Code first, when a squad needs it: the component is built in code first, and Claude replicates it from Storybook into Figma, where we adjust it if needed.
Key decisions
A guild instead of a dedicated team. With no headcount for a DS team, we shared ownership across four designers.
Humans validate, Claude drafts. Claude produces components, docs and pull requests, but correctness, fit for the business units and token usage are always checked by a designer.
Skills for repeatable steps: component creation, documentation, and GitHub PRs and reviews.
Two-way flow between Figma and code, so a component can start on either side without breaking the source of truth.
Three-layer variables (primitive, brand, semantic) to support multiple business units.
Results
The system is still in progress and serves ten business units, with 35 components implemented in code and 37 component pages in Figma. These figures come from an audit of the Figma file, not from product adoption, which I haven’t measured:
99.4% of style properties are bound to tokens (11,670 of 11,744), up from 97.0% in the October 22 audit.
628 variables across three layers: 327 primitive, 127 brand and 174 semantic. Semantic-layer adherence went from 85.6% to 100%.
Documentation grew: 89% of UI components have a description (from 58%), and documentation links went from 1 of 95 to 69 of 138.
Variables scoped to ALL_SCOPES dropped from 75 to 2.
What’s next
Next I’d tackle governance and stability, since the audit shows 30% of tokens are still unused. I’d also measure how many products actually adopt the components, and tokenize the remaining radius, text and effect properties.