Why Design Systems Are an Engineering Problem
Bridging the gap between Figma components and React codebases for true organisational scale. Tokens, theming, and release management.
Figma files are not a system
A library of beautiful components in Figma becomes drift the moment engineering ships a one-off variant under deadline. Design systems fail when they are treated as a design deliverable instead of a versioned product with APIs, release notes, and breaking-change policy.
Engineering ownership does not mean designers lose authority over visual language. It means tokens, packages, and accessibility contracts are enforced in CI the same way API schemas are.
Tokens as the source of truth
Colour, space, type, and elevation should live as tokens that compile to CSS variables, iOS assets, and Figma styles from one pipeline. When marketing wants a seasonal accent, you change a token — not forty hard-coded hex values.
We version tokens separately from components so product teams can adopt visual updates without rewriting interaction logic. That separation is what makes theming and white-label work tractable.
Release management for UI
Component libraries need semver, changelogs, and migration guides. A breaking change to Button props is as serious as a breaking REST change because it multiplies across every product surface.
Visual regression tests and accessibility checks on the system package catch issues before they fan out. The teams that scale are the ones who treat the system like infrastructure, not a side project.
Governance without bureaucracy
Contribution paths matter. Product teams should be able to propose variants with a clear review bar: documented use case, token usage, a11y notes, and Storybook coverage.
Rejecting ad-hoc styles without offering a path creates shadow UI. A lightweight RFC process keeps the system coherent without becoming a bottleneck that encourages forks.
Sofia Reyes
Design Engineer
Design engineer bridging Figma systems, accessibility, and motion into production UI.
