← All work

Case study · Design Systems Governance

Operationalising the design system.

I turn a drifting component library into one system with shared owners. Three steps, in a fixed order: consolidate, connect, govern.

CompanyNextens / LexisNexis (RELX), B2B tax SaaS
RoleOwner · Senior UX Designer, UX Lead from Oct 2024
TeamUX team and a lead developer
PlaybookConsolidate → Connect → Govern
PeriodDec 2022 to present
01 · The problem

Two libraries, drifting apart.

One library lives in Figma, the other in code, and nobody owns either. Every release widens the gap, so teams build around it.

Figma library

Button
Dropdown
Input
Tabs
Modal
Table
No owner
drift
drift
drift
drift
drift
drift

Code library

Button
Dropdown
Input
Tabs
Modal
Table
No change rule
ReleaseReleaseReleaseRelease
02 · Consolidate

Cut the variants before you add a rule.

The first meeting, in December 2022, is about typography. From the foundations I work up to components, and every variant becomes a property.

Trade-off: short-term disruption to work in progress.

20+dropdown variants
1configurable component
SizeSML
StateDefaultHoverDisabled
IconOffOn
03 · Connect

One workflow, two owners.

Every component moves through the same steps and ships to Storybook and Figma together. A lead developer maintains Storybook with my team, so using the system is the easy path.

Design · UX team
Task
Design
Team review
Ready
Ready means documented: naming, states, responsiveness, accessibility and content.
Before the sprint, the delivery manager and developers set the priority
Build · product team and lead developer
Backlog
Build
UX review and QA
Code review
Storybook and Figma
Announce
A gap in review sends the component back to design.
04 · Govern

A rule for every new component.

Three questions come before anything new gets built.

Trade-off: real governance overhead, justified by the drift it prevents.

Question 1Does a similar component exist?
yes
Question 2Can it be adjusted?
yes
Question 3Should everyone get the adjustment?
Local exceptionOnly one context needs it
The workflowEverything else
Drift incidents, last year
1

Down from routine.

Drift is a component that enters the product outside the workflow. One definition makes it countable.
05 · Impact

All product teams build with it.

20 → 4
Button variants, with size, state and icons as properties
20+ → 1
Dropdowns, replaced by one configurable component
1 → 10
Product teams building with the system by Q1 2024
1
Drift incident last year, down from routine
Teams reuse components and page layouts, so refinement takes about 4 rounds instead of about 12. The other half is in the UX function case study.
06 · What comes next

Make the system readable for AI.

In 2026 I audit both libraries again, to see what an AI tool can understand. Figma Make reuses a pattern only when it knows what the pattern is for.

99
components in Storybook, 97 active, 2 deprecated
87
components in Figma
51
match Storybook one to one
51 match4 only in Figma32 uncertain
Baseline audit · doneSemantic model · in progress
Designers validate every meaning. The AI does not decide them.
07 · What travels

Two lessons I take to any product.

Governance is a human problem.

The components are the easy part. The system lasts because it fits how engineers work, and a developer co-owns it.

Formalise contribution early.

The decision tree arrives after the first wave of components. From day one, it grows maintainers as fast as users.