Tokens contain a lot of information and even more the relationship between tokens. Making sense of this information is the hidden knowledge living within tokens. Unlocking this knowledge is the next evolution step for design tokens.

Tokens not only have a name and a value, they carry on a lot more data, which when given proper meaning is a knowledgeable resource.

Theming in Design Systems is a de-facto standard way to exchange the look-and-feel of your product. There is a high divergence of what is a theme? What does it consist of? Which constraints exists when building a theme? When and what to use a theme for?

Naming design tokens can sometimes be considered its own discipline. Naming is surprisingly straight forward, and if it isn’t then it solves the wrong problem.

Design tokens become scalable when they are replicable. A token specification is a formula for achieving design tokens scalability and tools interoperability.

Ever worked with a set of design tokens that are super inconsistent and hardly distinguishable? Perhaps a wrong scale? This article explains the available scales, their problems and what to use them for.

Design system architecture with focus on design tokens, that form the vocabulary of your visual design language, helping to streamline the communication amongst stakeholders. Modeling the system with boundaries to ensure clear purpose and predictability for design tokens and stability guarantees with fine control for theme authors.

Features encode user preferences, inherit behavior(s) and are communicated by several principals through agents. Design tokens may or may not support features.

Over the past three years, I’ve researched design tokens for usage in Theemo and I’m sharing my discoveries in this article series.