Pick any mature design system and open its documentation about color. What you find reads almost like a legal document. Every color has a name describing its job rather than its appearance, so the system talks about the color of a destructive action instead of talking about red. Each one carries a required contrast ratio against the surfaces it is allowed to sit on, along with a light-mode value and a dark-mode value. There is a stated meaning for disabled, for selected, for error. And there is a process, usually an uncomfortable one, for anybody who wants to add a new color to the set.
Now open the same system's documentation about motion.
eBay publishes theirs openly, and what is there is typical of the field. Nineteen values in a clean table. Eleven durations, running from seventeen milliseconds at the short end, which is roughly one frame on an ordinary screen and reads to the eye as instant rather than as movement, up to a full second at the long end, slow enough that a person notices they are waiting. Then eight easing curves, named things like standard, soft, continuous and bounce, describing whether a thing starts fast and settles, eases in gently, or overshoots its mark and springs back.
The table does not say which duration belongs to which kind of change. It does not say when a bounce is charming and when it is condescending. Nineteen correct values, and no guidance about any of them.
I am not picking on eBay. I chose them because their documentation is public and honest about what it does not contain, and because the same gap sits in nearly every system I have looked at, including ones I have worked on. For a long time I read this as a question of priorities: color obviously matters more, and motion is the thing a team gets to next quarter and never does. That reading is wrong. There is a mechanical reason motion and depth go ungoverned while color does not, and it has to do with where a team writes its decisions down and what that particular container is capable of holding.
A token is a decision, not a value
Start with what a design token actually is, because the word gets used loosely enough to hide the point.
Style Dictionary, the build tool that has been the default in this space for most of a decade, defines a design token as the platform-agnostic way to define design decisions. The word carrying the weight is decision. A token is a choice somebody made about how the product should look or behave, given a name, written down where both designers and engineers can read it, and translated into whatever form each platform needs when the software is built. One decision, named once, arriving correctly on the web and on iOS and on Android without anyone deciding it again.
That framing also tells you what does not belong in a token system. Donnie D'Amato, who writes on design system architecture, offers the cleanest test I know: will this value ever need to change independently of the property it is applied to? If the answer is no, it is a constant, and a constant does not need a name. A token holding zero, used where a component has no border, is a name for the absence of a decision, and zero is never going to become something else. A corner radius large enough to guarantee a pill shape is a decision one component made about its own silhouette, not a value anything else will inherit.
The standard describes thirteen kinds of decision
There is now an agreed format for writing tokens down. The Design Tokens Format Module reached its first stable version in October 2025, and it recognizes thirteen kinds of design decision: seven simple ones, and six it calls composite, meaning a decision assembled from several values that only mean anything together.
The simple seven are color; dimension, which covers any distance in an interface, including width, height, spacing, corner radius and border thickness; font family; font weight; duration, measured in milliseconds; an easing curve, expressed as the four numbers that define its shape; and plain number, for things like unitless line heights.
The composite six are where the argument lives. A border is a color, a width and a line style bound into one decision. A shadow is a color, a horizontal offset, a vertical offset, a blur and a spread, or several of those layered to produce a single believable sense of depth. A transition is a duration, a delay and an easing curve treated as one thing rather than three. Then gradient, typography, and stroke style.
Read that list as a design leader rather than as a file format, and most of the second half describes what people actually argue about in critique and almost never write down anywhere: how fast something moves and along what curve, how far a surface lifts off the one behind it, whether type is four values chosen together or four values that drift apart over three years. The standard treats each of those as one nameable decision. Most systems treat them as leftovers.
One button, five scales, five different levels of care
To see what that costs, count what decides the appearance of a single ordinary button.
Color decides the container, the label, the icon and the border, each of them changing across five states. Dimension decides the padding, the height, the gap, the corner radius and the focus ring. Typography decides family, size, weight, line height and letter spacing. Motion decides how long the state change takes and along what curve. Depth decides whether the button sits flat or lifts above the surface, and by how much.
Five scales feeding one component, and they are not governed the same way or often even by the same people. The color decisions have named roles and a review conversation. The dimension decisions have a scale behind them, usually built on multiples of four or eight, and a designer who uses an off-scale number gets caught. The typography decisions are half-governed, since size and weight usually sit on a scale and line height frequently does not. The motion and depth decisions are typically made once, by whoever happened to build the component, and never revisited by anyone.
So the honest answer to how multiple tokens come together to describe a component is that in most systems they do not come together at all. They arrive from five governance regimes of wildly differing seriousness, and the result stays invisible in review, because review looks at a still picture and two of those five scales do not appear in a still picture.
The container holds four
Here is the mechanical cause I promised.
Most teams treat their design tool as the source of truth for tokens, and in that tool the mechanism for holding a named decision is called a variable. A Figma variable can hold exactly four kinds of value: a color, a number, a piece of text, or a true-or-false switch. Those four, and nothing else.
Set that against the thirteen kinds of decision in the standard. Color fits. Dimension, font weight and duration fit as numbers, font family as text. An easing curve does not fit, because it is four numbers that mean nothing individually. None of the six composite kinds fit either. A shadow, a gradient, a border, a transition, typography treated as one unit: all of these have to be expressed as Figma Styles instead, a separate mechanism that does not participate in the same way in modes, the feature that lets a single named decision carry a different value in light and dark, or in compact and comfortable density.
That is the whole explanation for the gap I opened with. If the design tool is your source of truth, the kinds of decision it cannot hold as variables are the kinds that quietly fall out of your system. They become loose styles at best, and values buried inside a component at worst. Motion and depth are not ungoverned because designers do not care about motion and depth. They are ungoverned because the place the team writes decisions down has no shape for that kind of decision, and a decision with nowhere to live gets made once inside a component and forgotten.
The best argument for leaving things exactly where they are
There is a serious case for keeping the design tool as the source of truth anyway, and it is not the lazy one.
Designers author in the design tool. That is where the decisions get made, in the moment of making them, by the person qualified to make them. A designer can add a semantic color, see it applied across a file, adjust it, and have it right before lunch. Move the source of truth into a file that lives in the engineering repository and the same change becomes a request, filed in a system the designer does not work in, waiting on somebody else's review queue. Design systems fail from disuse far more often than they fail from disorder, and a tidy token file that designers have stopped contributing to is worth less than a messy variable set they use every day. Plenty of teams have arrived at a cleaner architecture and a design team that quietly went back to picking values by hand.
There is a practical answer to the type gap too: plugins can export shadows and typography out of the design tool into the standard format, and a team willing to maintain that plumbing can have both.
Where the case breaks is in what the workaround achieves. Exporting a shadow through a plugin gets the value out of the tool, but it does not make the shadow a governed decision, because governance is not storage. It is a name, a stated meaning, a review conversation when somebody wants a new one, and a place the decision can be found and argued with later. Composite decisions come out of that pipeline as bare values with no roles attached, which is exactly how they arrive today. The choice is not between a well-governed design tool and a well-governed file. It is about which kinds of decision are allowed to exist as decisions at all.
Moving the source of truth, and what it costs
What works is an ordinary file in the standard format, kept in version control, treated as the real source, with both the design tool and the codebase reading from it rather than writing to it. Version control here means the machinery engineering already uses for code: every change carries an author, a date, a stated reason, and a review before it takes effect.
Artur Sopelnik makes the case for reversing the usual direction, and the benefits are unglamorous ones. A token change becomes a reviewable record, which for most organizations is the first time a design decision has had a documented history at all. Automated checks catch a contrast failure before it reaches anybody. From that one file, a build tool such as Style Dictionary or Terrazzo translates each decision into what every platform needs.
The cost is the one the argument above identified. Designers lose direct authorship, and if the path to contributing a change is slow or unwelcoming they will route around it, and the drift returns wearing different clothes. Reversing the pipeline only works if contributing is genuinely easy, which is a governance problem rather than a tooling one.
The test worth running
For each of the thirteen kinds of decision, name who decides and when. Not who owns the documentation page. Who actually makes the call, and at what moment. If the answer for color is the system, at review, and the answer for motion is whoever builds the component, on the day they build it, you do not have a token system with a motion gap. You have two token systems, and only one of them is governed.
Conclusion
Motion and depth drift in otherwise disciplined design systems for a structural reason rather than a cultural one. The agreed standard describes thirteen kinds of design decision, six of them assembled from several values at once, and the design tool most teams treat as their source of truth can hold four. The kinds it cannot hold are the kinds that never become governed decisions, however much the team cares about them. Move the source of truth into an ordinary file under version control, let the design tool and the codebase both read from it, and make contributing genuinely easy or the drift comes back by another route. Then ask the question that reveals where you actually stand: for each kind of decision, who decides, and when?
Sources
