Design System from Scratch

No buy-in? Lead by example

Three existing product lines, each built by freelancers with no systematic mindset behind them, had accumulated their own disconnected UX, playgrounds and UI files: no naming conventions, no shared libraries, hand-offs kept manually in sync with live product by whoever had time. After my pitch was turned down and I decided to use this product as a proof of concept anyway, I got to work laying strong foundations and building as stable a structure as I could.

Scaffolded in Phases, building on the go

I was juggling product key feature decisions, research, UX flows, UI, handoffs, QA, reviews... I was the solo designer in this.

The system was never going to land in one pass, nor be sturdy from the beginning, so it didn't try to. Right after getting approval on the look and feel, I launched into Phase 1: prove the core tokens, type, and a first handful of components, enough to build the dashboard's first complete flow. Phase 2 expanded it: semantic tokens, gradients and elevations, a wider component set that grew over time out of strict necessity. Phase 3 pushed into solidifying, looking back and reinforcing where it had become wobbly.

Delivery and handoffs also followed a set order: components first, screen sections, full screens, then flows. Every time, changes cascaded predictably because of the architecture underneath.

The semantic layer was wrong twice, in two different ways.

✦ As my first time setting up a design system from zero, newbie errors were to be expected. The first iteration of semantics was thin, loosely drawn from an outside reference I no longer remember, and token creation quickly skipped past it, with component tokens piling up connected straight to primitives. With no dedicated time to build the system properly, about five to six months in, the pattern was obvious and quickly growing unmanageable. I gave my frontend developer a heads-up that a large structural change was coming, then scrapped the original semantic layer and rebuilt it from what the screens were actually using. Now that a full UX flow was completed, I had a much clearer view of how I, myself, was using colours and values, so extracting the pattern felt more natural.

✦ That rebuilt semantics held for a while, but around month ten to twelve, I noticed something else: patterns repeated across many components, like text or cards having the same hover/focus behaviour everywhere regardless of whether they were nested, colour usage on elevations, disabled statuses on fills/texts/borders/backgrounds... which weren't semantic in the usual sense but weren't component-specific either. Bunching them into the current semantic layer felt conceptually weak, yet a full rebuild didn't make sense. I looked for examples or precedent in other systems and found none, so I outlined a fourth level, sitting between semantic and component, and called it post-semantic. The main goal of this layer: to hold the cross-component patterns I was coming across.

✦ From the get-go, dark mode was off the table, which freed up a more experimental use of Figma Variables modes. Closer to prototyping than traditional system-building, smaller collections scoped only to component-level tokens were created to match recurring state patterns: default/active/focus/hover/disabled, default/pressed/focus/hover/disabled, on/off, xs/s/m/l/xl, primary/secondary/tertiary. This choice kept the system contained in terms of number of variables and sped up the breakdown for delivery of full UX flows.

An unusual stack requires a custom solution

This project stack was JavaFX, a language I was unfamiliar with and my research of design systems within it came back empty. It turned out it was also incompatible with every industry standard tool available at the time: Supernova, Storybook and Zeroheight were all ruled out, so the choice was made for me.

Tokens lived in Figma; the developer in Japan needed them as consumable JavaFX-specific CSS. Getting there took two attempts:
✗ First proposal: use Token Studio to get tokens as a JSON file. Denied, asked for CSS files manually sent.
✓ Second proposal: have direct repo access with me pushing from my own machine. This was approved though it meant manually copying and cleaning CSS output by hand for a stretch.

During this manual period, I was convinced a more efficient way existed out there, but knowing my limitations on the tech side, I reached out to a fullstack developer in the company to help me scope the problem. Together we scaffolded a solution and set it up. The eventual pipeline we ended up building used, initially, Token Studio as the "launchpad", pushing directly to the GitHub repo, where every push triggers two sets of GitHub Actions: one transforms it into a web CSS file (and overwrites the previous version), and a consecutive one that transforms the JSON into a JavaFX-specific CSS.
_{{for geeks, this is the reference point for those later transformations}}

The Buy-in Moment

This particular pipeline was what, unexpectedly, ended up gaining the CEO's attention. He was independently dealing with the same async, cross-language friction with my frontend developer, on an unrelated issue, at the same time I was. In a catchup meeting, I walked him through my delivery tactics as well as this Figma-to-GitHub pipeline. He was impressed enough and the reaction was immediate: "I want this running on all projects asap!!!!" triggering my official upgrade to Design Systems Lead and greenlight to audit and train the rest of the design team accordingly (of course, while still doing this project full time!)

Now, by this point there were: 7 product lines running on 6 different dev stacks (React, Flutter, Swift, Nuxt, JavaFX, Framer). My approach to scaling was "education, not imposition": fill the knowledge gap first, then implement and follow through on rules and guidelines. That took the form of a five-part internal series, Design Bites: the 1.01 sessions, covering foundations, components and terminology, governance, design tokens, and naming systems, alongside hands-on workshops: brand and component self-audits, a shared design-principles exercise, an expert walkthrough on tokens, and first-iteration attempts at the company's own core and semantic tokens.

Reception was outstanding: changed behaviour across every team member but one, followed by individual conversations and requests from designers wanting to work out how the theory applied to their own product's daily reality.

~50% Faster Hand-off

Component-first delivery, build the pieces, annotate every state and edge case, assemble screens second, cut hand-off time by roughly half compared to other teams at the company, by informal comparison with other designers rather than controlled measurement. Set against the baseline it replaced: four or five review rounds per handoff, sometimes corrections happening after a product had already gone live.

A Pipeline, Not a Hand-off Ritual

The side effect mattered as much as the fix: the same pipeline that turned token hand-off into a one-click export also unlocked white-label capability for an unrelated, earlier product, which is what first got the CEO's attention, independently of the design system pitch itself. Within roughly five to six months, that became a promotion to Design Systems Lead.

Documentation, Deferred on Purpose

No traditional component documentation existed for most of the build, a deliberate trade-off while the sole consumer of the system was its own author. It held up, but it also meant the system lived in one person's head for longer than was comfortable once the team started to grow, eventually scaling to 8 designers. That gap is part of what the later Design Bites series was built to close: five internal sessions and hands-on workshops, run once governance work began, rather than documentation written as the system was built. With earlier buy-in, component documentation would have started sooner, even lightweight, instead of waiting for a workshop series to catch up.