The standard design system handoff — designer exports specs, engineer implements — assumes two people. When one person is doing both, the process collapses into something different: faster in some ways, more fragile in specific ways that are worth understanding before you start.
This is what building the Datamotive design system looked like from one seat.
Start with tokens, not components
The first decision that made everything else tractable was refusing to touch components until the token layer was solid. Not "mostly done" — actually solid. That meant: six brand colour tokens with clear semantic roles, a type scale with named steps not arbitrary sizes, a spacing system with documented intent, and shadow tokens with defined elevation levels. Eight hours of work before a single component existed.
The reason this matters: if you start with components, you end up with components full of hardcoded values that have to be retrofitted later. I'd done this before on a smaller project and the refactor cost more time than the original build. Token-first means every component you build consumes the system from day one. The tax is paid upfront. Everything downstream is cheaper.
Figma variables became the single source of truth. Every colour, every spacing value, every radius — defined once in Figma as a variable, mapped directly to a CSS custom property. No translation layer. When the brand colour shifted slightly after the first client review, I updated it in one place and it propagated everywhere: Figma mockups, React components, the production site. That's the promise of a token-first system and it held.
The no-handoff process
The no-handoff model — where the same person who designs it also builds it — removes the information loss that normally happens in translation. A designer who can't code hands over a Figma frame and waits. What gets built is always a lossy version because the engineer doesn't have the implicit knowledge the designer carries.
When you're both, you have that knowledge, but you're also under time pressure to use it. The practical workflow: design in Figma against the variable system, verify alignment and spacing against the 8px grid, then move directly to code. No redlines, no spec documents, no handoff notes. The Figma frame was close enough to read from; the token system meant the CSS values were already decided before a line of code was written.
Real constraints at Datamotive
The context: full-time role, three product identities to unify, no dedicated frontend engineer, shipping cadence of weeks not months. The token-first approach worked because it front-loaded the decisions that would otherwise be made inconsistently dozens of times. Once the primary action colour is decided and encoded as a token, that question never gets asked again in a component.
The constraint that pushed hardest was time. Sixteen token foundations is not a small number. In the first two weeks, I built the foundations document, mapped everything to CSS custom properties, wrote the React component library foundations — buttons, cards, badges, inputs — and shipped the first product identity. That pace required the system to make decisions for me. When building a new component, the tokens told me what values to use. I wasn't making ad hoc spacing judgments mid-build.
The constraint I underestimated was voice. Visual tokens are straightforward to encode and document. Brand language — the tone rules, the CTA patterns, the messaging conventions — took three iterations to get right. Enterprise buyers read copy more carefully than you'd expect, and inconsistent language undermines a visually consistent system. If I were starting again, I'd treat voice tokens with the same rigour as visual tokens and establish them earlier in the process.
Discussion
Loading comments...