Why v3
v3 gave us one token set that switches the brand's primary color.
It runs Business ONE and the tablet sales app. ttb Touch stays on v2. Read the v2 story.
Values shown are representative; production values are confidential.
Two tiers
Raw values from ttb's brand guidelines, extended in 10% shade and tint steps. 26 families, never changed, only referenced.
Semantic tokens that reference general colors, organised by intent. Every product uses the same names; only the value per mode differs.
A five-part name
| # | Part | Values |
|---|---|---|
| 01 | Group (required) | Action, CTA, DataEntry, Navigation… |
| 02 | Category (required) | BG, Border, Icon, Text |
| 03 | Priority (optional) | Primary, Secondary, Tertiary, Quaternary |
| 04 | Emphasis (optional) | Strong (default), Soft |
| 05 | State (depends) | OnPress, OnHover, Disable |
Colors / Action / BG / BG-Strong-OnPress13 groups × 4 categories = 52 namespaces
Each group has BG, Border, Icon and Text namespaces. Brand differences live in the Action and CTA groups, where ONE-APP resolves to orange and B1 to blue; both share the same blue for Accent.
Scopes keep tokens in the right place
Shape and rectangle backgrounds: all BG fills
Container and page-level surfaces
Text only, so text colors never show up in shape panels
Border tokens only
The question behind every decision
If five more products join tomorrow, with their own colors, modes and platforms, will this hold without renaming a token?The test I used
With two tiers the answer is yes: general colors stay fixed, alias names stay fixed, and only the values per mode change.
What I learned
Token architecture must be designed for products that don't exist yet.From my notes on the project
Intent-based tokens scale to any number of products. Component-based tokens create debt. If a component exists twice, the token model is wrong.
At Thai Life I took the same idea to theme, light and dark, type and radius, in three months. Read the Thai Life case.