Work HUM
Design system, tokens and theming
One token set, so design and code stopped drifting.
HUM is where I owned the design system end to end: tokens, theming architecture, and the code-side styling structure the rest of the team built against. I took the front end to roughly 60% before moving to a supervisory role, reviewing the handover developer's work against the original requirements.
- Role
- Design System Owner
- Organisation
- AIENAI
- Period
- 2025
- Status
- Handed over
Built with
- Design tokens
- Theming architecture
- Figma
1
Source of truth for tokens and theming
~60%
Front end built before handover
The problem
Design and code drift apart quietly. A colour gets nudged in Figma, a developer hard-codes a hex value under deadline, and six weeks later nobody can say which of the four greys is the real one. The cost does not show up as a bug. It shows up as every future change taking longer than it should.
What I owned
- Design tokens and theming architecture. One source of truth for colour, type, spacing and elevation, shaped so a theme is a set of token values rather than a fork of the components.
- The code-side styling structure. Aligned so that the names a designer uses in Figma are the names a developer reaches for in the codebase. Translation is where drift enters, so I removed the translation step.
- Front-end development to roughly 60% completion, before moving to a supervisory role while I picked up another project.
- Handover review. I stayed on to check the developer who took over implemented the requirements as intended, rather than treating the handover document as the end of my involvement.
Where this stands
HUM is still in build, so there is no shipped outcome to point at yet. What I would claim is narrower and true: the team worked from one token set across design and code, and the theming architecture meant adding a theme did not mean touching a component.
This page will be updated with screenshots and results when the product ships.