Design Tokens: Our Model  

Adoption | January 2025

The goal of our design tokens work is to promote adoption of the look and feel of IDS for application teams that use non-IDS components. 
 
We accomplish this by defining variables—the design tokens—and structuring them in multiple layers to align our base palettes to their intended use across the components. This creates an inheritance structure that can be extended to components outside of the IDS library.

We organize our components across these categories: 

• Core: Our base palettes—such as red or green—are organized in 10-step progressions that provide a variety of shades of each color for the visual identity. These colors would be named things like “red-20” or “green-50” to help differentiate each shade. 
• Role: This maps how a token behaves as part of larger design patterns across the UI. For example, all components with a filled background element may be grouped by a role variable just called “color-background”, which can then be filled by a color identified by the designer. 
• Component: This is where the role groups are paired with their explicit use in an individual component. Following the background example, our general “color-background” type variable would be used to influence the button by being inherited by the explicit “button-background” variable.

While these variables will be available for teams to review when we launch our identities, we’ll be working with adopting teams mostly at the role and component levels. We can help match component interactions unique to their application to the general usages identified by our system.

More questions about tokens? Ask in the IDS forum in Microsoft Teams.