What We're Building and Why
Author: C. Maldonado, Product Design @ KWI
Started: February 2026
Status: In progress — living document
Repo: https://github.com/UX-Maldo/kwi-design-tokens
This is a running diary documenting the build-out of a design system's infrastructure — from Figma to production code. Each session picks up where the last one left off. The intent is to capture not just what was built, but why — the decisions, the dead ends, and the thinking behind the architecture.
The broader goal: take a design system from a collection of Figma files and scattered dev implementations to a fully automated, token-driven system that scales across products. This diary documents that journey so it can serve as a reference for the team, a case study for the design community, and an honest record of what it actually takes to build this stuff.
I'm a designer, not an engineer. I built everything documented here using Claude Code (Anthropic's agentic coding tool) as a collaborator. That's part of the story too — what becomes possible when the barrier between "I have an idea for how this should work" and "here's a working proof of concept" starts to collapse.
The Vision
KWI has multiple products and eventually needs to support white-labeling. That means the design system can't be built around specific colors, hard-coded values, or one-off naming conventions. It needs to be:
Intent-driven — token names describe purpose (brand, accent, muted), not implementation (blue, gray, #0055BB)
Automated — changes in Figma flow to code through a pipeline, no manual handoffs
Layered — primitives (raw palette) → semantics (intent) → eventually components (usage)
Multi-product ready — swap the primitive palette and the entire system re-themes
The Phases
| Phase | What | Status |
| 1 | Token pipeline — color, typography, spacing through Style Dictionary | ✅ Complete |
| 2 | QA scripts — WCAG contrast, contract testing, impact analysis on PRs | ✅ Complete |
| 3 | Claude Code as intelligent middleware — reads reports, generates component updates, assembles interfaces from component specs | Planned |
| 4 | Full component sync from Figma | Planned |
| 5 | Design system documentation site + bidirectional Figma sync | Planned |
The End Game
The QA scripts are the data layer for something bigger. The vision is a component specification layer — a structured description of what each component is, what tokens it uses, its variants, constraints, and how it composes with other components. With that in place, an AI collaborator could read a feature spec and assemble a coded interface from the design system's actual building blocks. Not generating UI from scratch — composing from known components.
There's an open-source toolkit called Tambo doing something similar at runtime for React. I'm exploring whether a design-led team can build this at the pipeline level.
It's a proof of concept. But the question feels right: what happens when design systems become intelligent enough to participate in building the interfaces they define?
How This Series Works
Each session is published as a separate post. Sessions may cover pipeline work, token architecture, QA automation, documentation, or anything else that moves the system forward.
The tone is honest, technical, and conversational. The failures are documented alongside the wins. The dead ends are part of the story.
Built with: Figma, Tokens Studio, GitHub Actions, Style Dictionary v4, Claude Code, and an unreasonable amount of patience for YAML indentation.