Intent vs Reality
Overview
Every design system tool describes what you intended. Only the shipped product shows what you actually built. When the two drift apart, only one of them is in front of your users. This article is about that gap, and the loop that closes it.
1.Every tool describes intent
Figma, Style Dictionary, Tokens Studio, Storybook, a brand guide PDF. They all answer the same question: what is the design system supposed to be. That is intent. It is necessary, and it is not the same thing as what shipped.
Source files describe the plan. Production describes the result. The two are only equal on the day you deploy, and they start diverging the moment someone overrides a value, a contractor ships a component, or a refactor quietly changes a default. Nothing in the design tooling can see that divergence, because none of it looks at the running product.
2.Only production is the truth
There is exactly one place where the design system as experienced actually lives: the rendered DOM of the running product. Not Figma, not the tokens file, not the component library. The shipped pixels.
Dembrandt reads that. It extracts the live, computed values: colors, the type scale, spacing, radii, shadows, component states. Measured from what users actually see, not from what a file says they should see.
The difference is not academic. Your spec says the primary color is one hex value. Your shipped button renders another. Every tool that reads the spec agrees the design is fine. Only the one that reads production catches the drift.
3.The loop runs both ways
Once you can measure reality, the relationship between design and production becomes a loop, not a one-way export.
Forward, from reality to design: extract a live product and use what is actually running as the starting point for the design system. No manual audit, no guessing at values.
Reverse, from design to guard: take the declared system and check, on every deploy, whether the shipped product still matches it. That check is drift, scored. Same data, two directions. One measures the world to inform the design. The other uses the design to watch the world.
4.Fixing is also two-directional
When a check finds a difference, the useful question is not whether it is bad. It is which side was wrong.
If the implementation drifted from the spec, that is a regression. Fix the code and bring production back to the system. If the design changed on purpose and the shipped product is simply ahead, then the spec is out of date. Update the design system to match reality.
The diff is the same either way. The decision, regression or intentional, is what sends the fix in one direction or the other. A measured before and after value is what makes that decision possible instead of a guess.
5.What this looks like in practice
Start with a live product. One command extracts its real tokens. Connect a design tool over its automation interface and let an agent author those tokens directly into a file: color styles, a type scale, spacing and radius values. A design system foundation built from what ships, not from memory, in a single pass.
Then turn it around. That same token set becomes a baseline. On the next deploy, the shipped product is scored against it. Anything that moved shows up as drift, with the exact before and after.
The foundation and the guardrail come from the same measurement. You do not maintain two sources of truth. You measure once and use it both ways.
6.Where this sits, honestly
The strong version of this depends on one thing: the baseline being your declared design system, not just yesterday's snapshot. Comparing against the previous extraction tells you that something changed. Comparing against the spec tells you whether the product still honors what you decided. The second comparison is the one worth building a workflow around.
Most tools will always describe intent. That is their job, and they are good at it. Dembrandt does the other half: it measures reality, so the gap between what you designed and what you shipped stops being invisible.
Intent is a plan. Reality is what your users get. The point of measuring production is to keep the two from drifting apart without anyone noticing.
Continue reading
Token Drift Is Silent. Here Is How to Catch It.
Design tokens drift quietly between releases. A color shifts, a spacing value disappears, a border radius changes. Nobody notices in the moment. Here is how a baseline-based approach catches it before it compounds.
Three Mindsets, One Product
Designers, developers, and business stakeholders all think about UI differently. This article looks at why that gap persists and how a token-first approach helps close it.
Design-Dev Workflows That Pay Off
Modern design and development workflows are not about picking the fanciest tool. They are about shared understanding, a common end goal, and a workflow that fits the team you actually have.