Consistent experiences create trust in our organization. Each interaction is part of a user's overall experience with Sage. If the user experience isn’t consistent across touchpoints, users will question our organization’s credibility.
Small inconsistencies—like colors that aren’t exactly the same, or spacing that’s off by a pixel or two—may not seem like a big deal, but they create design dissonance: the feeling that something isn’t quite right.
So how do we ensure our users have the most consistent experience possible?
We use design tokens.
What design tokens are
Design tokens are records that define small, repeatable design decisions.
They are named and organized in a meaningful, platform-agnostic, and shareable format.
Most importantly, they are the atomic elements that underpin the Fusion Design System and empower designers and developers to create consistent interfaces that establish and maintain user trust.
How design tokens speed up development
- Meaningful design token names make handovers between designers and developers easy.
- Developers do not have to make design decisions when developing a component.
- When component-specific changes are made by the Design System team, developers only have to accept the latest release with no need to edit any code.
- Global changes are quick and simple to implement. For example, if Sage were to have a rebrand, the Design System team just need to update the semantic middle layer and then all the consuming apps will automatically be updated, saving weeks of development time.
- Tokens support light and dark theming.
- Tokens ensure visual consistency across the component library.
Developers: see information on using our design tokens in your application.
How design tokens are composed
1. Identify core visual attributes
Core visual attributes are used consistently throughout the design system to define the look and feel of our interfaces. They include things like color, font, dimension, depth, and breakpoints.
2. Organize and reference
Design tokens are named and organized in a standardized meaningful way, making their purpose clear and unambiguous.
They are split into 2 main types:
Core tokens
Core tokens reference the raw values of visual attributes, such as hex codes (color) and pixels (spacing).
Their naming has limited meaning.
Semantic tokens
Semantic tokens reference other tokens (either core or other semantic), applying their values to specific contexts.
Their naming has specific meaning, indicating their intended purpose in the UI.
Composition of a global font token
3. Name semantic tokens consistently
Semantic token names have specific meaning, defining how and where they are used within the UI. We use a straightforward naming system to make these tokens easy to understand and consume by both developers and designers.
Semantic naming structure
Naming structure in practice
4. Document and share
The standardized meaningful naming of design tokens allows design decisions to be documented in a platform-agnostic and shareable format.
Our design token repository on Github contains the design tokens for the Fusion Design System. This library is used to distribute our tokens across multiple platforms, and is maintained by the Design System team.
How design tokens are applied to interfaces
There are 2 sets of tokens which can be applied directly to interfaces. Both are semantic.
- Global tokens are generic semantic tokens that can be applied within components and in page layouts.
- They reference core tokens
- Component-specific tokens are bespoke semantic tokens that are only applied within components.
- They mostly reference color mode tokens
How color tokens connect component elements to raw values
How design tokens are updated
How tokens facilitate theme switching
Color mode tokens are semantic tokens that create a middle layer between core and component-specific color tokens. They respond to theme switching by remapping their color reference from one core token to another.
- Component-specific color tokens -> color mode tokens.
- Color mode tokens -> core color tokens.
- Mode tokens change their reference value and pass this to component-specific tokens.
Example of light and dark mode in practice