Tokens or Components: where should we start first?
The answer affects the entire maintenance cost later on, not just the first week.
Start from the token foundation, meaning the color palette, typography, and spacing are named and organized into layers before creating any components. If you create components without tokens, each component will embed hard-coded values, and when you need to change brand colors or support dark mode, the technical team will have to manually fix hundreds of places. Tokens are established once, and the entire system updates in one go.
- multiple digital products, need for light and dark modes or multi-branding
- want a system that lasts and can expand
- a small product needing a quick launch (still using token as the base)
- waiting for the perfect token to start, freezing the entire project
Color, font, and spacing tokens are the foundation. Components are built on that foundation. Reversing this order will double your effort each time the brand changes, and later, if you want to support a dark interface or add a second brand, you will almost have to start over.
Tokens are the single source of truth.
Brad Frost describes a token as the "subatomic" unit of the interface: not usable on its own, but a foundational element that everything above must inherit. When the design team and the engineering team reference a token instead of each remembering a color code, the entire digital product maintains consistency without needing to manually check each screen.
If you change a primary color token at the root, the entire website, application, and all components will update immediately. No meetings, no need to send new color files to each person.
Organize tokens in three layers.
A flat token set that only lists colors is not enough for long-term operation. Sinh Vũ organizes tokens into three hierarchical layers:
- Primitive layer: the actual values of colors, font sizes, spacing, for example, blue-500 = #1A56DB. This layer is not tied to any context.
- Semantic layer: named according to usage purpose, for example, color-brand-primary refers to blue-500. When rebranding or switching to a dark interface, only this layer needs to be adjusted.
- Component-specific layer: tokens specific to each component when needed, referencing the semantic layer. This layer does not contain hard values.
This three-layer architecture allows for color changes at the root and controlled spreading, without affecting unwanted areas.
When to start from a token, and when can it be done in parallel
Starting from tokens first: When a business has many digital products, needs to support a dark interface or multiple brands, and wants the system to last for many years and expand to iOS or Android. This is the most common case and also the situation where technical debt accumulates the fastest if this step is skipped.
Can create in parallel when: There is only a small product, the brand identity has been fully finalized, and it needs to launch quickly. However, the mandatory condition is that from the beginning, every component must reference tokens, absolutely no hard-coded color values or font sizes inside the component.
Common errors to avoid
- Inserting hard values into components: This is the most serious error. When needing to change brand colors or support a dark interface, the technical team must find and manually fix each component.
- Creating tokens but only a flat layer: A token set lacking semantic layers makes it nearly impossible to support light and dark themes and multi-branding later, as there is no place to "bend" values according to context.
- Waiting for a perfect token before starting: Tokens do not need to be 100% complete before building the first component. Start with a usable set of tokens, build in parallel with control, and then gradually supplement.
Sinh Vũ's viewpoint
In the A3 process at Sinh Vũ, the initial stage always involves reviewing the current identity and transitioning everything to the DTCG JSON token set (a standard format proposed by the Design Tokens Community Group under W3C, allowing a token set to be used across multiple tools and platforms) in three layers, along with a report on the standard deviation between design and the actual product. Only after this token set is finalized does the team move on to the component creation stage.
The reason is not due to a rigid process, but because this is the only way to ensure that identity does not dilute when entering digital products. If components come first, each person will decide which colors to use, what font sizes are appropriate, and after six months, the interface will have dozens of small variations that no one can control.
A token is the single source of truth. Components can only reference tokens; they cannot define values themselves.
Design System operation principles, Sinh Vũ Studio
Decision checklist
Topic: Should you start with tokens or components in the design system. Sinh Vũ guide, sinhvu.com
Select each item you find appropriate, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
Brad Frost, Atomic Design and the article Design Tokens + Atomic Design. Design Tokens Community Group, W3C DTCG JSON specification. Nathan Curtis, EightShapes. Practical experience from project A3 at Sinh Vũ Studio.
Frequently asked questions
What is a token, and how is it different from a component?
A token is a pair of name and value, for example, color-brand-primary = #1A56DB. A token cannot be displayed alone; it is the raw material that components inherit. A component is a complete interface element like a button, information card, or navigation bar. Creating tokens first is like mixing colors on a palette before painting, rather than mixing colors while painting each stroke.
If the product is small and needs to be released quickly, can we skip the token?
Do not overlook it, but you can work in parallel with a small initial component group. It is essential that from the beginning, the component must reference tokens, and you should not hard-code color values or font sizes inside. If you skip this entirely, technical debt accumulates quickly and the cost of standardizing later is much higher than doing it right from the start.