Token framework

How Moments tokens are structured: why we use them, the three tiers (Core → Semantic → Component) and how each tier is named. For the practical side — adding, renaming and deprecating a token — see Token workflow. For how tokens fit the wider naming rules of the system, see Standards.

• What are design tokens?
• Benefits of tokens and themes
• Design token types
• How to name tokens
• Core tokens
• Semantic tokens
• Component tokens

---

What are design tokens?

Design tokens are the single source of truth for every design decision in the design system. They are all the values needed to construct and maintain a design system — spacing, colour, typography, component styles, animation, etc. — represented as data. They can represent anything defined by design: a colour as an RGB value, an opacity as a number, an animation ease as Bézier coordinates. They're used in place of hard-coded values to ensure flexibility and unity across all product experiences.

Design tokens are directly integrated into our component libraries and UI kits. They cover the various options of platform scales, colour, component states, spacing, typography and more.

For example, the green colour for an icon on a success flag uses a design token such as colour-icon-success, instead of a specific colour value like #36B27E or Green300.

Design tokens store repetitive design decisions in a platform-agnostic way. A design decision is the choice you make from the available options — like choosing a brand colour.

---

Benefits of design tokens and themes

Theming with design tokens lets us make visual design changes at scale across products.

One component, two brands: only the core value changes — the semantic and component tokens stay the same.

---

Design token types

The following types of design tokens are the building blocks and design decisions that make up the Moments design language for Easol.

Core tokens

Core tokens are the primitive values in our design language, represented by context-agnostic names. Our colour, typography and dimension values are all recorded as core tokens. They can be used directly, and are inherited by all other token types.

Semantic tokens

Semantic tokens relate to a specific context or abstraction. They communicate the intended purpose of a token, and are effective when a value with a single intent appears in multiple places.

Semantic tokens are context-specific and reference core tokens. Each semantic token has a specific intent, meaning and role. Unlike core tokens, semantic tokens appear in specific contexts or instances.

Component tokens

Component tokens are an exhaustive representation of every value associated with a component. They often inherit from semantic (alias) tokens, but are named so engineering can be as specific as possible when applying tokens in component development.

How one core value flows through semantic tokens into several component tokens.

---

How to name tokens

The naming structure of tokens organises the design properties and styles of the system into a logical, hierarchical structure. As Nathan Curtis describes, the right structure depends on the needs of the system and its team — what matters is that it is clear, consistent and easy to understand for everyone.

We follow a slightly different structure for each tier, because the three tiers are different levels: although each builds on the previous one, each needs its own categories. So that our products share visual similarities and the tokens share a naming structure, the bases below are used across every product in the organisation.

---

Core tokens

The naming structure for core tokens is the easiest to follow, since we only give consecutive values to our options. Only moments and core are the same for every token in this tier — the first is the name of the system, the second the name of the tier.

Segment	What it is
category	The most primitive grouping of values — what we build our Foundations with (colour, font-size, spacing…).
element	A subcategory for which value we are using. Only used in colour (primary, neutrals, error…).
amount	The value on the category's scale — size, opacity, step, etc.

Categories

Colour

Colours are a set of predefined colour values used consistently across all design assets, such as interfaces, graphics and marketing materials. moments.core.colour.primary.500

Font family

The name given to a set of fonts that share the same stylistic characteristics, with variations in thickness, width, etc. moments.core.font-family.primary

Font size

The characteristic that gives the font a specific size, large or small. moments.core.font-size.100

Line height

The spacing between lines of text. Useful for separating paragraphs, headings and subheadings. moments.core.line-height.200

Font weight

Variations in weight/intensity within the same font family. moments.core.font-weight.bold

Letter spacing

Letter spacing (character spacing or tracking) is an optically consistent adjustment to the space between letters, changing the visual density of a line or block of text. moments.core.letter-spacing.100

Text case

The distinction between uppercase (capitals) and lowercase letters. moments.core.text-case.none

Border radius

Rounds the corners of an element's outer border edge. A single radius makes circular corners; two radii make elliptical corners. moments.core.border-radius.50

Border width

The width of an element's border on all four sides (shorthand for top, right, bottom and left). moments.core.border-width.200

Opacity

The degree to which content behind an element is hidden — the opposite of transparency. moments.core.opacity.60

Spacing

The length of space between elements. moments.core.spacing.125

Sizing

The dimensions of elements such as icons and containers, ensuring consistent scale and proportion across the interface. moments.core.sizing.250

Elements

Only colours have an element in their name, since colour is the only place we use subcategories — to name all our palettes correctly and keep control and organisation within the system.

Colour elements

• Primary
  • Neutrals
  • Error
  • Success
  • Any other colour palette we have in the product

Amount

Every category needs an amount, so we can define which value corresponds to each core token. The naming of the amount depends on the category.

Amount by category

• Colour: 100, 200, 300… from lightest to darkest
  • Font family: primary, secondary…
  • Font size: 100, 200, 300…
  • Line height: 100, 200, 300…
  • Font weight: 100, 200, 300… (depends on the weights available in each family)
  • Spacing: 0, 25, 50…
  • Border radius: 0, 25, 50…
  • Border width: 0, 25, 50…

---

Semantic tokens

Semantic tokens in context on an Easol dashboard.

Semantic tokens describe the purpose of a value — where it is used and for what. They are named with this structure:

Part	Description
moments	The design system namespace. This prefix groups all tokens belonging to the Moments Design System.
semantic	The token is a semantic value, describing its intended purpose rather than a raw design value.
category	The type of design property the token represents, such as colour, border-width, spacing, radius or typography.
role	The semantic purpose or usage within the interface, for example text, background, border, icon, reactive or supportive.
variant (optional)	Distinguishes visual contexts or emphasis levels within the same role, such as default, accent, inverse or subtle.
state (optional)	The interaction or component state the token applies to, such as hover, pressed, focus, disabled or selected.

Categories and roles

Depending on the category, a semantic token has different properties that define where it is integrated in our components and designs.

Colour

The colour roles tell us where each token goes in any frame:

• Text
• Icon
• Border
• Container background
• Page background
• Supportive feedback
• Reactive

Typography

Defined by grouping several core tokens (family, size, line height, weight, letter spacing, case) into one semantic token that gives meaning to each text style:

• Heading
• Paragraph
• Label
• Monospace

Shadows

Shadows are defined from smoothest to strongest in colour intensity. At the component level, each shadow has to be nested to a specific colour.

Border radius

Border radii are semantic values with a purpose-agnostic nomenclature.

Border width

Like radii, border widths are semantic values with a purpose-agnostic nomenclature.

Aspect ratio

At the semantic level the aspect ratio already carries meaning, and should only be used where a specific token exists for that use case.

Spacing

Spacing gets a more explicit name about where it is used; it becomes most relevant at the component level.

Sizing

Sizing tokens get clear, context-specific names that reflect their intended use. Their true significance emerges at the component level, where they define precise dimensions for each UI element.

Variant

Core values are defined with sequential numbers or pixel counts. Semantic tokens use a more flexible naming that makes tokens easier to define and apply across contexts. The convention varies by category:

Colour

Semantic colours align with the company's brand colours, named after their usage context in the interface. Examples: overlay, base, error.

Typography

Named from largest to smallest size. Component-specific styles, such as buttons, use semantic sizes like medium or small. Examples: heading, action small, paragraph, link.

Border radius

Named after the level of roundness or where the radius is typically applied, rather than the pixel value. Examples: none, small, medium, large, full.

Shadows

Named after elevation, visual prominence or interface context. Lower levels are subtle separation; higher levels are elements further above the page. Examples: subtle, raised, floating, overlay, focus.

Border width

Named after visual emphasis, purpose or interaction state. Border width and border colour stay separate categories so they can be applied independently. Examples: default, subtle, strong, focus, disabled.

Opacity

Named after the visibility or emphasis it provides, not the percentage. Examples: disabled, muted, subtle, overlay, hidden.

Spacing

Named after relative size or layout purpose. General spacing uses size-based names; more specific tokens can describe their role in a layout or component. Examples: x-small, small, medium, large, x-large, gutter.

Aspect ratio

Named after the content or element it supports, not the numerical ratio. Examples: square, avatar, thumbnail, media, landscape, portrait, video, hero.

Duration

Named after the perceived speed or purpose of the transition; the core token holds the milliseconds. Examples: instant, fast, standard, slow, emphasized.

Easing

Named after the motion intent — why the curve is used, not its maths. Examples: enter, exit, standard, emphasized, expressive. A semantic motion token can combine both: motion.enter = duration.fast + easing.enter; motion.standard = duration.standard + easing.standard; motion.emphasized = duration.slow + easing.emphasized.

State

Only colours use states — no other category has them. Colours are used differently in components depending on the variant. Not every state exists for every property, so only use the ones that are available.

Default

The initial appearance of a component before any interaction — the baseline for how it looks and behaves under normal circumstances.

Hover

When the pointer is over the component without clicking. Gives visual feedback that an element is interactive.

Pressed

When the user clicks or taps the component. Confirms the interaction was registered.

Loading

While data or content is being retrieved or processed. Shows the component is working on the request.

Disabled

When the component can't be interacted with, temporarily or permanently — e.g. a button that stays disabled until a required field is completed.

---

Component tokens

Component tokens are defined by the nomenclature of each component part — colour, text, text colour, border radius, etc. Each component has its own nomenclature, but parts that are the same across brands must share the same name, so theming between brands works without changing each property. Following Nathan Curtis's approach, the structure is:

Segment	What it is	Examples
system	Always the same — the name of the design system.	moments
component	The name of the component we are tokenising.	button, row, text-field
category	The main thing we are defining on the component (same categories as semantic).	size, spacing, typography, colour, breakpoints, shadow
element	Depends on the component and the pieces it's made of.	label, icon, background
variant	Depends on the component and the variant being tokenised.	primary, secondary, tertiary, error, warning, success, info
state	The state being defined for that variant.	default, hover, pressed, focus, active, disabled

Component tokens mapped onto the parts of a Row.

Component

A reusable element or module used to build interfaces. This segment is the name of the component being tokenised.

Category

The same categories as semantic tokens. It gives context about what we are tokenising.

Element

Every component is different: text, description, icons or other parts change its meaning and look. Each of these parts needs its own token, which is why components need an element segment.

Variant

The same component can come in different types — primary, secondary, tertiary, or error, warning, success. Each is defined by different colour tokens, so each variant is tokenised.

State

Each variant has states that need defining too — hover, focus, disabled, etc. — each requiring its own token adjustments.