Design Tokens for Decision-Makers: What to Ask Your Team For

Open any mature digital product and look for its primary text color. Without a token system, that one color is typed out by hand in many places, along with a few near-misses that nobody chose on purpose. Each one is a small inconsistency. Together they are why a product starts to feel slightly off as it grows.

Design tokens fix this at the root. You don’t need to write them, but you should know what to ask for.

What a design token is

A design token is a named decision. Instead of writing #141414 everywhere you need dark text, your team defines a name once, such as text-primary, and every screen refers to the name.

Colors are the obvious case, but tokens also cover type sizes, font weights, spacing, corner radii, borders, and shadows. Each is a choice your brand has made, stored in one place and given a label that people and software can both read.

Think of a paint order. A contractor who writes “the warm gray from the lobby” on every work order will eventually get five different grays. A contractor who writes one paint code gets the same gray each time.

Why tokens matter to the business

Speed. When the decisions are already made and named, designers and engineers stop re-deciding them. A new page is assembled from known parts instead of negotiated from scratch. That is where the time savings come from, and they compound with every screen shipped.

Consistency. Your website, mobile app, email templates, and internal tools can all draw from the same source. Customers should not be able to tell which team built which screen. Tokens are what make that possible without a person policing every pixel.

Rebrands. This is where the gap shows. If the brand color lives in one token, changing it is a single edit that flows outward. If it was typed by hand across several codebases, a rebrand becomes a search-and-hope project. Tokens also make smaller changes cheap, such as a refined type scale, an accessibility fix, or a dark mode.

Five questions to ask your team or vendor

You don’t need to read code to judge the answers. You need to listen for specifics.

1. Where is the single source of truth for our colors, type, and spacing? A good answer names a place and an owner: “It lives in this repository, and this person approves changes.” A weak answer is “the Figma file and also the stylesheet,” which means there are two sources and they will drift.
2. If we changed our primary brand color today, what would have to be edited? A good answer is “one token, then a rebuild,” plus an honest note about the exceptions, such as images and legacy pages. A weak answer is a long pause followed by “it depends.”
3. How are the tokens named, and can a new hire understand them? Good names describe purpose, like text-secondary or surface-elevated, not appearance, like light-gray-2. Purpose-based names survive a rebrand. Appearance-based names become lies the moment the gray turns blue.
4. Do design and code use the same tokens? A good answer is yes, and the team can show you the connection, whether it is an automated export or a shared file. A weak answer is that designers and engineers “keep them in sync manually.” Manual sync is how drift begins.
5. How do we prove the product is actually using them? A good answer includes some form of checking: a lint rule, a review step, or an audit that flags hard-coded values. A weak answer is “we trust the team.” Trust is fine, but it doesn’t catch a rushed Friday fix.

What a good system looks like in practice

At Artasce, the Crystal Design System is built on tokens. Each token carries the ac- prefix so it is unmistakable in code, and spacing follows a Fibonacci-based scale (4, 8, 16, 24, 40, 64 and up) instead of arbitrary pixel values. Type follows a fixed 1.25 ratio. The result is that most layout questions already have an answer before anyone opens a design file.

The details of your system will differ. What should be the same is the discipline: a small set of named decisions, owned by someone, used everywhere.

Reading the answers

Pay attention to how the answers are delivered, not only what they say. A team with a real token system answers quickly, shows you where things live, and admits where the gaps are. A team without one tends to answer in generalities, or to reach for words like “flexible” and “scalable” without an example.

If the answers are weak, that is useful information, not a failure. Adopting tokens is usually a matter of auditing what exists, choosing names, and migrating one layer at a time. It is more tractable than it sounds, and the sooner it starts, the less there is to untangle.

A short checklist for your next review

Ask the five questions in your next product or vendor review and write down the answers. Compare them to what you see on screen. If your site and your app disagree about something as basic as a heading size, the token layer is the place to look first.

If you’d like a second set of eyes on what you find, we’re glad to talk it through with your team.