A design system here, a design system there

Generally speaking, in practice, a design system is singular. In that, it's created for one particular identity. This is a misnomer, as design goes beyond identity. You can look at design systems in a purely holistic manner. Still, the practical realities of implementation start with the understanding that a design system is a system of systems. The complexity is daunting. Nee, it's effectively impossible. No wonder Brad Frost wrote about reframing the concept of design systems and how we could move forward.
But let's not go scorched earth on design systems. Yes, we need to frame the conversation on what design systems are and, more specifically, what they can do. It sounds like we should discuss design system architecture.

A design system is a collection of patterns, best practices and tooling. Like any process, we need to have a view of that journey. BizOps - DesignOps - DevOps - SysOps

Yes, I agree. We need all these Ops' like a hole in the head. But hear me out; they shine a light on the systems we will need to tie together.
Look at it like this: Market - User - Implementation - Delivery.
These terms oversimplify it too much, and the domain overlap makes things fuzzy. It does do one thing; it helps frame the discussion.

From my perspective, as a Design Engineer, I need to tie the user and implementation together. I'm moving information from one to the other, from a design tool to a web framework. The collaboration between design and implementation is where the design system comes to fruition. Yes, a design system holistically involves all the Ops' I mentioned but creating a design system happens in the space between design and engineering.
Design transfer to development happens in several ways. But what's new is the advent of Design token automation. The ability to import and export design values into (web) components directly.

So, now we have a new problem. What should we put in these tokens?
The first thing to understand is the scope of the system. How many identities, brands and variations must it serve? Does it help just content and marketing, or should it enable applications?
Web? Native? Desktop?
If the system is simple and its expression is singular, it could simply be a one-to-one relationship containing most of the design values. These tokens include things like dark mode values so the engineering can be literal in its implementation.

/* Design System */
--ds-color-dark: black;
--ds-color-light: white;
/* Component rules */
p {
color: var(--ds-color-dark);
@media (prefers-color-scheme: dark) {
p {
color: var(--ds-color-light);

If you have a multi-brand requirement, that approach will make the system unusable in a short time.
Here are some of the types of values we need to implement a design:

  • Design tool values
  • Design tokens (A subset of the Design tool values)
  • Implementation values (Think of Light Dom and global patterns)
  • Component values.

To feed the shared components with the appropriate values, we need to manage each theme's various implementation value sets.

@layer normalize designsystem themes components;

/* Design System root layer */
@layer designsystem {
:root {
--ds-color-1: red;
--ds-color-2: yellow;
/* Design System theme layer
Teams can swap out their own themes, with or without dark mode

@layer themes {
:root {
--theme-color-text: var(--ds-color-1, orange);
@media (prefers-color-scheme: dark) {
:root {
--theme-color-text: var(--ds-color-2, white);
/* Component token */
@layer components {
:host {
--cmp-color-text: var(--theme-color-text, --ds-color-1);
/* Component rule */
p {
color: var(--cmp-color-text);

It's becoming evident that these layered systems benefit from being declarative. You describe its relation to the rest of the system and not what it is in precise terms. I know it's a cliche, but that will not scale.
CSS is also moving in the direction of implied values instead of fixed precise values.

width: min(50vw, 200px);
width: calc(var(--variable-width) + 20px);
font-size: clamp(1rem, 2.5vw, 2rem);
grid-column: 2 / -1;

Writing CSS for large scale projects was never easy, and with all these additional features and possibilities, it looks to be getting harder and harder, year after year. Working towards a Declarative Design System might be your best bet.

Posted on: June 6th, 2022

Next Post

CSS Day 2022, all aboard for Interop 2022

Interop 2022 will improve the experience of developing for the web in 15 key areas. And Rachel Andrews spoke about this on CSS day 2022.

Previous Post

CSS Day is drawing nigh

CSS Day conference is coming up this June, and looking at the lineup and the topics; it is easy to see that we're on the precipice of a new way of implementing a design on the Web..