In our new comprehensive online course, Subatomic: The Complete Guide To Design Tokens, we discuss the need to revisit the powerful concept of separation of concerns.

Separation of concerns is a computer science principle introduced in the mid 1970s that describes how each section of code should address a separate piece of a computer program. Applying this principle results in more modular, understandable, and maintainable codebases.

Web designers & developers of a certain age might remember the separation of concerns applied to the three languages of the web: HTML provides the structure, CSS provides the style, and JavaScript provides the behavior of a web page.

Illustration showing the separation of concerns between the three languages of the web. HTML provides structure, CSS provides style, and JavaScript provides behavior

The separation of concerns was beautifully articulated by Dave Shea when he introduced the CSS Zen Garden in 2003. The CSS Zen Garden demonstrated that from the exact same structured markup in HTML:

The source HTML code of CSS Zen Garden, devoid of any styles

web designers could apply CSS to achieve wildly different aesthetic results:

Several examples of submitted designs from the CSS Zen Garden

This beautifully and viscerally demonstrated the separation of concerns, and contributed to an era of web design and development where separation of concerns and progressive enhancement were best practices widely .

Alas, this era didn’t last. This is in part because “JavaScript don got big” (to use the parlance of the great Chris Coyier). In fact, the capabilities of all three languages of the web have greatly advanced, new concepts have emerged, and techniques have evolved. That means the separation of concerns for the web can no longer be cleanly delimitated between HTML, CSS, and JavaScript; the lines are a lot blurrier!

An illustration showing the lines blurring between HTML, CSS, and JavaScript

Doors of Perception

Let’s talk about doors! Need one? If you did, you’d wander back to the door aisle of the hardware store and peruse the finite number of products on display. One may be a primed semi-hollow door, while another may be an untreated solid oak door. Both options adhere to standard construction dimensions (to pass inspection, meet ADA requirements, be compatible with other materials, etc), the hinges on positioned on either the right or the left, and the bored-out holes anticipate the door’s knob and lock hardware.

A door’s structure and the functionality are on full display in the door aisle. But you may notice there are no turquoise doors for sale in the door aisle. No pink doors. No orange even! And where’s the brass hardware? The modern matte black finish? What gives? For those aesthetic decisions, we must wander over to the paint and door hardware aisles.

A sampling of different colors of exterior doors and a collection of different door hardware materials

Hello, separation of concerns! The door’s paint color and hardware finish — aesthetic decisions — don’t impact the structural integrity and functionality of the door; these separate concerns come together to form the final (functional! beautiful!) result.

The New Separation of Concerns

We need to apply our door metaphor to our wonderful world of pixels. Because even though the lines between the three languages of the web are a lot blurrier, separation of concerns is still a great principle!

After all, it would be ludicrous to require manufacturing a brand new door from the ground up every time someone wants an orange door instead of a lavender door. Unfortunately, that’s exactly what we’re currently doing in our digital work! Designers and developers often break away from established design systems for aesthetic reasons (“But our buttons need to be blue!“), and in the process lose all of the important structural, functional, and infrastructural benefits these systems provide.

We need a new separation of concerns. Thankfully, the brainy design systems community has already cracked the code. Our now-familiar component libraries — delivered via Figma team libraries, Web Components, React, Angular, et al — serve as our door frames, providing rock-solid structure, functionality, accessibility, UX, and front-end best practices.

But what about our digital turquoise paint and matte black hardware? Those aesthetic design decisions for color, typography, border, shadow, spacing, animation, and other UI properties are now defined and managed as a design token system.

Decoupling our structural component system from our aesthetic design token system creates the separation of concerns we need to address the needs of our Multi-All-The-Things organizations.

These complementary systems work together to create themeable design systems that can power multiple products, brands, color modes, tech stacks, product families, and more. Trends like headless UI solutions Base UI, React ARIA, and others are showing us the desire to decouple structure/functionality from aesthetic choices.

Our new online course, Subatomic: The Complete Guide To Design Tokens, dives deep into how to wield this new separation of concerns. The course features 13 hours of in-depth videos, Figma & code sample token architecture, naming & governance workflows, a certificate of completion, and a whole lot more to help you master the art of design tokens. We use the theme-switching magic trick to demonstrate this new separation of concerns: