Behavioural Tokens
Capturing behaviours that propagate through your token system
Design tokens are a now well-established means of storing and transferring information about a design system, often in a platform-agnostic way, allowing for accurate and efficient communication within and between different teams of developers, designers, educators and documentors.
Various formats exist to manage them; from Style Dictionary, the new DTCG specification, and numerous bespoke proprietary formats developed on an ad hoc basis to serve individual teams' needs.
Whilst the development of the DTCG specification is a welcome improvement that will standardise tokens and promote free movement of tokens between tools and systems, it does not make any easier the authoring of tokens.
Behind every semantic token, hidden sometimes within its naming, is a story. The story of how this token came to be; where it can be used; what its related siblings may be. Whilst this story might be decodable from context, wouldn't things be easier if these stories were also recorded?
Determining what is the source of truth in a Design System can be a prickly subject, and can lead to unfortunate divisions being created between teams. Is the 'source of truth' for you design tokens the variables in your Figma file? Is it your foundation team's Style Dictionary package? Does moving token definition into code mean that developers are now the source of truth?
The answer to all of these is, simply, no. Any structured manifestation of design tokens, like Figma variables or Style Dictionary packages, are in fact records of truth. The source of truth of a design system is the people who make the decisions - the result of all the teams working together to define how the system should behave.
Maybe the real source of truth is the friends we made along the way.