Matthew Huntsberry

I build the tooling before the components.

Design systems end to end — Figma variable architecture, token pipeline, components — plus the MCP server and quality gates that let a team ship on it without me in the room.

Live system

Every control below is the real component. Change a mode and watch which token moves.

TokensComponentsGovernance
Theme
Brand
Density
Radius
--brand-solid
--height-md
--radius-md
--surface-1

Work

Case studies

Five systems across different industries and scales. Each write-up covers what the team was stuck on, how the platform was put together, and what it changed.

The playbook

Five layers, and the order I build them in.

Tooling comes first — the Figma plugin and MCP server before the components — so everything built afterward inherits the same source of truth. Each layer ships as a discrete deliverable.

  1. 01

    Token Pipeline

    Figma Variables → JSON → semantic CSS, published to npm. A rebrand becomes a token PR instead of a component sweep.

  2. 02

    AI Context (MCP)

    An MCP server over the live system — 17 tools spanning tokens, components, specs, and audits. Assistants query the real thing instead of hallucinating a plausible-looking button.

  3. 03

    Figma Plugin

    The same data pushed back into Figma. Variable scaffolding, dark-mode audits, spec annotation — whatever the team keeps doing by hand becomes a command.

  4. 04

    Component Library

    A framework-agnostic runtime that other frameworks consume, rather than a React library everything else has to work around.

  5. 05

    Governance

    20 ADRs, accessibility gates in CI, alignment scoring. Governance becomes a number a PM can read instead of a design review someone has to attend.

About

The parts that usually get skipped.

I’m Matt. I work hands-on, and I care most about the details that decide whether a system survives contact with a team: variant axes that map onto the component API, tokens that survive a rebrand, density that lives in variables instead of duplicated components, documentation that can’t drift because nothing maintains it by hand.

The case studies cover how each of those held up once a team was actually using them — including where they didn’t.

Contact

Open to design systems roles.

There’s more behind each case study than belongs on a public page — the constraints, the approaches that didn’t work, the calls I’d make differently now. Ask and I’ll walk you through it.