design-system

Naming

The following set of principles guide our team when naming things in the system. These principles are loosely based on the guidelines from Brad Frost’s CSS Architecture for Design Systems.

Make it modular

Modularity reduces complexity and improves our system’s reusability. This applies to our naming as well. Different parts of the design system need to be clearly separated.

Keep it consistent

Consistency enhances clarity and makes our design system more predictable and easy to use. We use the same language and naming wherever possible.

Prioritize legibility

Developers and designers should be able to understand the system at a glance and understand the structure and purpose of any given part.

Avoid conflicts

It’s critical to ensure that the design system’s naming doesn’t conflict with other libraries and systems. This is accomplished by the provided namespacing.

Clarity over succinctness

The system may seem verbose, but it delivers clarity and resilience in exchange. Keeping naming legible and scalable sometimes means sacrificing a shorter syntax.


Colors

Semantic colors

Semantic colors carry meaning and imply how and where they should be used. Each semantic color name contains a role, a modifier, and a theme mode. This accommodates needs such as state, interactivity, and emphasis for different Kesko brands. For example, a component may require color variations for :hover and :focus states.

Primitive colors

For the Kesko primitive palette, we use numeric scales (100, 200, 300, ..). This provides clear ordering and makes it easy to add values between the existing tokens when necessary.


Components

Kesko Design System uses a simple naming structure for component naming based on {prefix}-{name} format.


CSS Properties


Design Tokens

Designers and developers should be able to understand the purpose of a design token at a glance. To make sure naming stays consistent and legible, we follow these guidelines for design tokens:


Sizes

Kesko Design System defines semantic sizes using the t-shirt metaphor. This makes it possible for anyone, technical or non-technical person, to understand the differences and how they relate to each other at a glance.


Styles

Our design system styles follow a simple naming structure based on .{prefix}-{name}-{modifier} format.


Attributes

When naming Custom Element and Figma attributes, it’s important to pay attention to the consistency between the different components so that API stays as predictable as possible. Our shared conventions include: