Design systems drift the moment somebody starts building with them. What that costs you depends on the end user.
Role
Design systems lead
Organization
Self-directed
Last fall I was trying to figure out how Redwood’s Figma toolkit was going to be maintained once AI got its hands on it. Oracle’s design system is enormous and mostly uniform across industries. A Redwood supply chain app and a healthcare app feel unmistakably Oracle.
Bidirectional Figma < > Claude Code tooling didn’t exist then. We had recently been allowed to use Figma Make, and Make couldn’t properly talk to the toolkit the Redwood Figma team had built. So all we ever got was componentry that felt vaguely Redwood but never grounded in the reality of the design system.
When it came time to update my site, I knew I wanted to define the design system first. Since I’m looking for design system jobs, it helps to have a real design system to point at. But, also, I wanted to see if I could achieve what I never could just a few months prior.
I was braced for disappointment, sure that I’d get a set of values and components that pass for a system, but underneath it’s every component for itself. That isn’t what happened. I giggled a bit as a token hierarchy formed. Then components that used the tokens instead of restating them. I watched a usable system assemble itself in front of me. You can take a look at my design system Figma file. Dig around. See how the sausage is made.
It’s easy to make a component library. What makes a design system truly work is documenting how every component is to be used.
For instance, my design system has a rule that my orange accent color gets used once per section of a page, and the design system names which elements are allowed to use it.
There’s a rule that a card heading is exactly two lines, because Jubilat at 24 in a 296-pixel column wraps at about 22 characters, so write to 38 and stop. That rule exists only after my choice in titles broke the design of the work index.
And there are some that battle default AI design tendencies: if the type is already doing the work, the decoration doesn’t belong. Don’t toss in an icon or color border unless there is a justified reason.
As I iterated on this site’s design, the Figma design system began to fall behind, and I synced the two before handing over a link. Drift is not a failure state. It’s what happens when a system is used. Going back to update the system is a separate act of discipline, and when you’re in the thick of trying to get your portfolio up ASAP, it gets pushed aside.
The scale and frequency of this reconciliation is going to be different for every single design system that exists. When it’s my site, I hold all the design intent. If it weren’t for me using the design system of a portfolio piece, I’d consider regular maintenance an unneeded formality. But, when hundreds of people build against a system, a stale rule isn’t deferred maintenance, it’s a wrong answer that propagates, and the results could be dangerous, depending on the industry being developed for.
At that scale I’d want a hook that checks the coded outcome against Figma and stops when they disagree. I’d want it to stop and ask which side moved, and whether that was on purpose. Whether any documentation of the rules needs to change. Depending on the size of your system, this can expend a lot of tokens, and on a small system you might reasonably decide the drift is cheaper than the hook.
A stale rule on my site produces a heading that wraps to three lines. A stale rule in a clinical app could cost a life.
