Token references
ImplementationTypes, aliases, theme mappings, generated outputs
ValidationCycles, unresolved references, and theme switching
↗SI / ENGINEERING
One design language
A system that scales across products
Design token references and component APIs together, so Figma variables, themes, code packages, accessibility, and release governance work as one product system.
- DTCG tokens
- Figma variables
- Component contracts
- Accessibility / Visual regression
01INSIDE THE SYSTEM
The mechanism, made explicit
A reference graph connects primitive values to semantic and component tokens. Themes change the semantic layer while components consume role-based references rather than hardcoded colors.
Scroll the diagram horizontally to inspect the complete flow
02DESIGN & VALIDATION
Implementation criteria
meet acceptance evidence
Concrete design decisions and acceptance scenarios to agree for the project.
Component contract
ImplementationFigma variants ↔ props, states, events
ValidationLoading, errors, long content, and keyboard use
Product adoption
ImplementationVersions, deprecation, and migration guides
ValidationIntegration checks on representative product screens
Technology choices and acceptance criteria depend on discovery, integrations, and agreed scope. We define reproducible acceptance scenarios and handover evidence for the operating environment.
03ENGINEERING APPROACH
Engineering decisions
in detail
From visible features to failure conditions,
we work through the decisions before launch.
Model tokens as a reference graph
Separate primitive, semantic, and component layers with types and aliases for color, spacing, typography, and motion. Assess the DTCG format for interchange and code transformation, validating cycles, unresolved aliases, and invalid types during builds. Express brand and dark-mode variation through semantic mappings rather than scattered screen-level overrides.
Align Figma properties with component contracts
Define size, variant, emphasis, disabled, loading, and error behavior as a component contract. Map Figma variants to code props and use composition when combinations become unmanageable. Documentation environments such as Storybook describe constraints, events, long content, and responsive behavior alongside examples, making the package usable by teams beyond its original authors.
Validate accessibility and regression at component level
Specify keyboard order, focus behavior, accessible names, roles, states, and error associations by pattern. Manually exercise behaviors that automated checks cannot establish, such as dialog focus restoration or combobox navigation. Use selected states, viewports, and themes as visual-regression baselines, with a review process that distinguishes intended changes from defects.
Govern adoption and the cost of change
Maintain package versions, changelogs, deprecation notices, and migration guides. Distinguish token-renaming impact from component API changes and adopt high-use patterns incrementally in existing products. Assign responsibility for proposals, design review, code review, and release so teams have a supported contribution path rather than maintaining disconnected copies.
04DELIVERY & HANDOVER
A tangible handover
- Design principles, token definitions, themes, and naming rules
- Figma library, agreed code components, and documentation
- Pilot screens, state and accessibility checks, and governance and migration guides
05BEFORE WE BEGIN
Where we start
- Target products and existing Figma and frontend assets
- Supported frameworks, brands, themes, and languages
- Initial shared screens and the future library owners
06HOW WE WORK
Discover
Understand your goals, workflows, and operating environment.
Define
Define features, priorities, and integration requirements.
Build
Build the agreed scope and review progress together.
Launch & Operate
Prepare testing, deployment, and operational handover.
↗YOUR NEXT CHAPTER
Let’s build the ground
for what comes next
You don’t need a finished specification.
Start with the problem you want to solve.