Tokens and composites in design systems

Last few days I have been fully immersed in design system architecture. More specifically I have been looking at the best way to structure our design tokens to allow for maximum design flexibility.

or anyone not familiar with design system tokens, quite a few people have already written extensively about them. Tokens in design systems, by Nathan Curtis, is a good article to read.

But before diving straight into how we approach tokens, it is worth mentioning the unique problems my team is trying to solve. The company I currently work at has a B2B product in the banking sector (web, iOS, Android) which has 3 distinct themes. In some cases clients employ their own design teams to style the product. Given there was no design system or style guide in place before I joined the company, more often than not the UI and style changes resulted in a fork which had to be maintained separately.

Most approaches regarding token architecture out in the wild tend to include every single configurable element as a token. In our circumstances this approach compounded on our main problems, allowing third party teams to change core values on so many elements unavoidably creates consistency issues.

In come the composites

To fix this problem, we decided to introduce a second level of a different kind of token, the composite. Tokens have values attached to them which can be changed by a design team to meet specific design needs. For example, the values of the typographic size scale can be changed to meet the design needs of a new product theme. Composites, our second level tokens, instead of values have first level tokens attached to them. The font size of the main button is a composite and references a font size token from the typographic scale. So if a designer wanted to change it without amending the scale, she would need to change which font size token it is referencing. This way we make sure only font sizes defined in the typographic scale will appear in a new theme.