Don't Tell Anybody, These Are Evals

The design decisions behind Fluent Flex, the token reduction, the semantic naming, the mathematical scales, were made with AI legibility as an explicit goal. And they were the kind of decisions you could actually test: color rebuilt on an OKLCH model for perceptually uniform ramps, elevation on an exponential formula instead of hand-tuned presets, radius and spacing on semantic tiers tied to component hierarchy. Mathematically derived, not eyeballed. The argument: if names encode intent and relationships are mathematical, a model should be able to reason over the system the way a designer would, inferring hierarchy, suggesting appropriate values, and generating consistent output without a lookup table.

But "AI-inferable" is a claim, not a fact, until it's tested. The field has no established methodology for evaluating whether a token system can serve as a machine-consumable instruction set. So with Lydia Mitchelson, we built one, and ran it against three models: Claude, ChatGPT, and Copilot.

The methodology: Docs 🤝 Schema, a pipeline for translating design language documentation into something a model can reason over, then stress-testing whether it holds. The goal was never whether a model could generate something that looks right. It was whether a model could reason from our token system and get the answer right once we took the source docs away.

The starting point: Fluent Flex documentation for spacing, corner radius, and typography, the same docs designers read. The ask to the model: translate this into a machine-friendly schema that can be fed to models for generative UI. Prompt language included: "Some of the pages have really good tidbits of info. Make sure to add those in model-friendly, prioritization language."

The model produced a YAML schema with structured fields for intent, increment, examples, allowed tokens, constraints, and model rules. Raw design knowledge converted into something executable. Notes baked into the schema: "Intent-first: choose semantic tier/level before selecting numeric values" and "Use lowest hierarchy that satisfies clarity; escalate only when needed."

Stress-tested the schema using only the generated schema, no source documentation, no Figma files. Three natural language questions asked directly against it:

The schema was self-sufficient. Correct answers, cited correctly, from the schema alone. No source documentation consulted.

Asked the model for a rationale: what patterns did it find in the raw token values that informed its schema decisions? The model identified four:

Applied the same schema approach to two additional token sets, the Copilot token file and the Fluent 2 token file, which lacked the rich documentation the Fluent Flex system had. The model generated parallel schema structures with inferred role, intent, and constraints from sparse source data alone.

Then: ran a cross-schema comparison across all three design language schemas, asking the same questions of each: long-form reading styles, button vs. modal corner radius, input-to-submit spacing at the roomiest density.

Initial result: mostly accurate, but incomplete. One follow-up constraint revealed the system's real depth:

The stress tests were evaluations all along. Not testing whether the model knew token values, but testing whether it could reason over the system the way a designer would. Whether the intent encoded in the names and structure was enough for the model to make the right call without a lookup.

Here's the honest part: this was early. The tokens we tested got refined a lot afterward, partly because the evals showed us exactly where a name carried an assumption a model couldn't infer. That was the value. Test the tokens against a model, find the gap, tighten the name or the guardrail, run it again. This is also where my job stopped being "designer" and became the SME who could tell whether the model was right or just confident. Knowing when the answer is wrong is the skill.

And the stress tests revealed something more important: the design language structure either causes or prevents specific AI failure modes.

When a model is asked to generate UI from intent, there are identifiable ways it breaks, and the design language structure is a primary cause or prevention of each one.

The cleanup work, the token reduction, the semantic naming, the mathematical scales, was infrastructure investment all along. Not just for designers and engineers. For AI.

Already in practice: AI used to automate accessibility testing between foreground and background color tokens across all 58 canonical pairings, recomputing in real time when a custom brand is applied. AI used to validate group token naming conventions against the schema. The evaluation wasn't theoretical. It was confirming what was already being built.