One of the easiest traps to fall into when building a design system is accidentally recreating CSS.

At first, it seems harmless.

You add a few utility classes.

Then a few responsive options.

Then a few layout helpers.

Then a few exceptions.

Before long, you've built an entirely new syntax for doing the exact same thing CSS already does.

I've become increasingly interested in a different approach.

Not replacing CSS.

Not hiding CSS.

Creating a layer above CSS that focuses on intent.

The Problem With More Options

Developers love flexibility.

I do too.

The challenge is that flexibility often comes with complexity.

Consider responsive layouts.

Many systems solve this by exposing every possible breakpoint and layout combination.

The result is powerful.

But it's also easy to end up with markup that spends more time describing implementation details than communicating purpose.

The system becomes harder to understand.

Not because it's incapable.

Because it's trying to describe everything.

Intent Versus Implementation

Lately I've been thinking less about how a layout is built and more about what the layout is trying to accomplish.

For example:

<div content adapt="grid" mobile="stack">

This isn't trying to replace CSS.

It's trying to express intent.

The content should adapt as a grid.

On mobile, it should stack.

The implementation details can remain inside the design system.

The goal isn't more abstraction.

The goal is better communication.

Strong Defaults Create Simplicity

One lesson I've learned from building software is that good defaults are often more valuable than endless configuration.

Most layouts follow common patterns.

Most responsive behavior follows common patterns.

Most developers aren't trying to create entirely new layout systems.

They're trying to organize content.

A design system can help by providing thoughtful defaults rather than exposing every possible option.

The Danger Of Recreating CSS

The moment a design system attempts to expose every CSS capability, it starts competing with CSS itself.

That's usually a losing battle.

CSS already exists.

CSS is already powerful.

CSS is already standardized.

The job of a design system isn't to replace CSS.

The job of a design system is to reduce cognitive load.

To create consistency.

To communicate intent.

To make common patterns easier.

Designing For Readability

One question I increasingly ask when designing APIs is:

"Can I understand this six months from now?"

Not:

"Can I configure everything?"

Not:

"Can I support every edge case?"

Simply:

"Can I read this and understand what it is trying to do?"

Readability scales.

Complexity doesn't.

The Goal Isn't Less Power

Sometimes simplicity gets mistaken for limitation.

I don't think that's true.

The goal isn't to remove power.

The goal is to place power where it belongs.

Common workflows should be simple.

Advanced workflows should remain possible.

The design system should help developers move quickly without preventing them from solving unique problems.

Final Thoughts

I've become increasingly convinced that the best design systems don't try to replace CSS.

They try to create a shared language around common design decisions.

A language focused on intent rather than implementation.

A language that helps developers communicate purpose.

Because at the end of the day, most developers aren't trying to build layouts.

They're trying to build products.

The layout is simply one part of the system.