1. Background
This research note emerged from my Master's thesis work exploring how narrative frameworks from cognitive linguistics, specifically the concept of "semantic primitives" developed by Anna Wierzbicka, could inform how we build design token systems and component libraries.
The central argument: design systems are not just technical tools. They are semiotic systems, systems of meaning. The way we name, structure, and relate tokens to each other communicates intent, creates shared understanding, and encodes organisational values into artefacts that outlast any single designer's involvement.
Thesis question: If language has irreducible semantic primitives, concepts like GOOD, BAD, WANT, DO, what are the equivalent primitives in a design system? And what happens when design systems lack them?
2. The Framework
Wierzbicka's Natural Semantic Metalanguage (NSM) theory holds that all human languages share a set of universal primitive concepts that cannot be reduced further. These primitives are the irreducible atoms of meaning.
"A design token is not a colour. It is a semantic statement about when and why that colour should be used."
Applying NSM thinking to design systems produces a clear taxonomy:
- Primitive tokens are raw values, the design equivalent of phonemes. They carry no meaning alone:
#14C25F,16px. - Semantic tokens are named intentions, the equivalent of morphemes:
--color-action-success. - Contextual tokens carry situational meaning:
--btn-primary-bg-hover.
A design system that skips the semantic layer collapses primitive values directly into component contexts. The result is brittle: changing a primitive value requires touching every component that references it. More critically, the system loses its capacity to carry shared meaning, a new designer joining the team cannot understand the intent behind a value from the token name alone.
3. Practical Implications
The theory maps directly onto measurable engineering and design team outcomes:
Naming as Documentation
The most practical outcome of this research is a naming principle I apply to every token system I build: a well-named token should answer the question "when should I use this?" without requiring any external documentation.
--color-feedback-error answers its own question. #FF3B30 does not. The difference between these two naming approaches is not cosmetic, it is the difference between a system that scales with a team and one that collapses when its original author leaves.
4. Connection to Practice
This theoretical framework directly informed the PumpPay design system architecture, where the three-tier token structure (Primitive → Semantic → Component) was grounded in the NSM model of meaning-making. The naming conventions, governance structure, and documentation format all emerged from treating the design system as a semiotic system rather than a technical artefact.
The deeper insight is that design systems are a form of institutional knowledge encoding. When they are built with explicit semantic structures, they preserve the reasoning behind decisions, not just the decisions themselves.