A design token looks like a small thing: a named value for a color, a spacing step, a font size, a shadow. Most of the writing about tokens is about the tooling, how to generate them, how to sync them from a design file. I think the value is the least interesting part of a token. The interesting part is that it is a decision with a name.
Naming a decision changes who makes it
Before a team has tokens, every spacing choice is made by whoever is writing the component, at the moment they write it, and reviewed by whoever happens to be reviewing. The decision is remade hundreds of times, by different people, with different taste. Review threads fill up with opinions about eight pixels versus twelve.
Once the spacing scale has names, that decision is made once, by the people whose job it is, and the engineer's job becomes choosing from the scale. Review changes character. The question is no longer whether twelve pixels looks right but whether this gap is a small gap or a medium one, which is a question with an answer. I think that single change removes a surprising share of the friction between design and engineering, because it moves an argument about taste to a conversation about categories.
Exceptions announce themselves
The second thing tokens do is make exceptions visible. When every value in a codebase is a raw number, an exception looks like everything else. When every value is a token, a raw number stands out, and a linter can flag it.
I think this is the real accessibility and consistency win. It is not that tokens make the interface consistent. It is that they make inconsistency cost something: a comment, a justification, a visible choice to go around the system. Most of the time the engineer takes the easy path and uses the token. The rest of the time, the team learns that the scale has a gap, which is information the scale's owners need.
A contract that survives distance
The third thing is that a token set is a contract between design and engineering that does not depend on the two being in the same room. A designer in one time zone and an engineer in another can both read the same file and get the same answer. The contract survives turnover, too. A new engineer learns the scale in an afternoon and inherits years of decisions without having to be told them.
That matters most on distributed teams, where the informal channel that keeps design and engineering aligned, the walk over to someone's desk, does not exist. The token file is the desk.
What goes wrong
Tokens fail in two ways I have seen. The first is too many of them, where the scale has forty spacing steps and choosing from it is no easier than choosing a number. A scale is only useful if it is small enough to hold in your head. The second is tokens without an owner. A scale nobody is allowed to change becomes a thing people go around, and then the exceptions stop announcing themselves because there are too many to notice.
So my view is that a token set needs the same two things any standard needs: a small enough surface to be learnable, and a named owner who can change it when the team finds a gap. Given those, I think tokens do more for how a team works together than for how its interface looks, and I would adopt them for the first reason alone.
Photo source: https://photos.robertstowe.com/venice