One Source, Two Tools
Design and code had their own version of the same values, so both were right about half the time. The tokens now live in code in GitLab. From there we generate the CSS custom properties for the shop, and Tokens Studio pulls the same repository into Figma.
- Client
- Calida Group Digital GmbH, in-house
- Engagement
- Ongoing, together with the design team
- Role
- Frontend Lead
- Year
- 2026 to present
- Stack
- GitLab, Tokens Studio, Figma, Storybook, Twig, CSS custom properties
- components in the system
- 32Counted as components that exist in Storybook and in Figma. If it only exists in one of them, I do not count it as part of the system yet.
- place a token is defined
- 1Colours, spacing and typography are defined in code and live in GitLab. From there we generate the CSS custom properties for the shop, and Tokens Studio syncs the same repository into Figma. Both sides read the same file.
- mockups built from outdated components
- 0UX can build mockups from the real components, in Figma or with AI tools like Figma Make. What they hand over is made of parts that already exist in code.
None of the differences were big. A gray that is one step off, a spacing value someone rounded, a button that got an extra hover state in code but never in Figma. On their own they are small, but they cost us a discussion every few days.
So this is more an organizational thing than a tooling thing. The tokens have one owner and one source, and changing a value is a merge request like any other change. For UX it means designs get faster and more accurate, because they build with components that really exist. For me it means I review whether something belongs in the system, not whether the values match.