Logo
Systematically makes design-system logic explicit.
It is a design token authoring tool and cloud IDE built around a custom DSL. The goal is to make tokens, scales, modes, references, and outputs readable as rules instead of scattered across files and tools.
Systematically product interface
The DSL is the core of the work. It gives design systems a way to describe relationships, generate numeric scales, resolve references, and export to formats like CSS, W3C Design Tokens, Tokens Studio, and Figma Variables.
Background
Design tokens are often treated as static values, but the useful parts of a design system are the relationships behind those values.
Spacing scales, typography steps, colour modes, references, aliases, and contrast decisions all carry logic. Systematically is an attempt to write that logic down in a way people can read, edit, compile, and use in production tools.
Challenge
The challenge was to keep the language expressive without making it feel like a developer-only tool.
The product needed to support real design-system work: named tokens, semantic scopes, modes, generated scales, references, exports, documentation, and Figma sync. It also needed to stay legible enough for designers and design technologists to reason about the system directly.
Solution
The solution is a readable DSL with an editor, compiler, documentation, and a Figma bridge around it.
The editor makes the source easy to write. The compiler turns it into structured outputs. The docs explain the grammar and workflows. The Figma plugin connects compiled variables back to design production. Each part can move independently, but the DSL remains the shared source.
My Role
Product design, systems design, and engineering
I shaped the product concept, the language model, the editor experience, and the technical structure behind the workflow.
The work spans product framing, UX design, interaction design, DSL design, documentation, SvelteKit implementation, compiler integration, and Figma workflows. The emphasis is on making design-system decisions visible, testable, and repeatable.
The work is less about storing tokens and more about describing how they are made.
A token can be a fixed value, but a system often needs more than that: scales, formulas, modes, references, output formats, and rules for how values relate to each other. The DSL gives those decisions a place to live.
A readable source can become many outputs.
The same source can compile into design-token formats for code, documentation, and Figma. That keeps the intent closer to the output and reduces the amount of manual translation between design and implementation.
Logo
Let's connect!