Design Systems in the AI Era: What is the Right Density?

What a Design System Is, and What It Isn't

Design systems are about "consistency" and "decision-making cost"

As features multiply, maintaining a design system becomes both a task of preserving consistency and managing the cost of decision-making.

This post is a record of how we redefined the "right density"—deciding which decisions the system should handle and which it shouldn't—to protect both of those aspects.

We also realized that as AI rapidly generates drafts, it is ultimately the "standards" that keep a team grounded.

This story is a case study of our organization, but it's also a problem that any environment where multiple teams build the same UI together will experience in a similar way.

From ADS 2.0 to 3.0: What Changed?

This revamp wasn't about "creating more components"; it was an upgrade to recalibrate our standard specs.

There are three main changes.

Semantic: We changed the language so that the role comes first rather than interpretation—using terms like Foreground instead of expressions like Emphasis.

Typography: We maintained the role structure but limited the combinations of scale and weight, simplifying the naming convention to reduce the decisions needed when applying them.

Palette: We tiered the previously inconsistent values, fixing the options into a "structure" rather than relying on "gut feeling."

This post chronicles what the system needs to handle during this upgrade process to make the team faster and more stable.

Redesigning the foundation of a 13-year-old service

Before talking about fixing the design system,
I want to start with why this wasn't an easy task.

This is a service that was launched in 2013 and has been around for 13 years.
Features have grown, teams have split, and speed remains critical.

Tinkering with the design system in this situation is akin to opening the engine of an airplane in mid-flight.

Furthermore, we weren't building something new.
We were re-examining a system that was already running well.

Fixing something broken has a clear justification.
But fixing something that works well requires a slightly different kind of judgment.

The problem wasn't the UI, it was the standards

The screens looked fine. The service operated stably.

The problem wasn't the "outward result," but the standard specs that produced those results.

At first glance, ADS 2.0 fit together like a puzzle, but upon closer inspection, the sizes of the pieces were slightly different.

Those differences didn't break the screens immediately, but as time passed, they slowed down decision-making.

The way the differences showed up was simple.

• It was the same gray, but felt different on every screen,

• It was the same emphasis, but the tone varied,

• So every time we had to double-check, "Is this right?"

If the standards aren't clear, the judgment keeps falling back on people. When humans have to make repeated decisions, speed gradually slows down.

That's when we realized it.

As features multiply, a design system is no longer a matter of aesthetics, but a matter of reducing repetitive decisions and fixing the standards.

Not more intricate, but more clear

The direction of this project was surprisingly simple.

Instead of creating more rules, we made the system handle only the points of repetitive deliberation.

We didn't force other areas into rigid bounds.

The right density we talk about here is the balance between how much the system substitutes for repetitive decisions and the resulting maintenance cost.

As AI alleviates repetitive tasks, human judgment will ironically converge more toward "exceptions and standards."

Palette — Viewing by structure, not gut feeling

The first thing we looked at was the palette.
There wasn't huge confusion about the colors themselves. They were already being used well, and the designers were used to them.

But looking closely at the Gray Scale, there were many granular values like 97 and 95 instead of 50 and 100.

Looking at the Gray Scale alone, there were 21 tiers. That meant every time we picked a gray, there were 21 "potential right answers."

This didn't instantly break the screen or cause a major disaster.

However, every time we created a new screen, the micro-decision of "Which one of these should I use?" kept repeating. Therefore, the key wasn't to make the colors "more dense," but to make them easier to choose.

We decided not to fix it by feel. We decided to look at the data.

1. We extracted the ADS 2.0 palette values as a CSV,

2. Compared them with a reference public palette (e.g., shadcn),

3. Mapped the closest tiers based on ΔRGB + 3×ΔL,

4. Extracted the mapped color data again, visualized it with Figma Make, and QAed it based on actual screens.

Extracting palette values as CSV and comparing them with a reference public palette (shadcn)
Using Figma Make to compare and verify the existing palette against the upcoming mapped colors

We actively utilized AI in this process.
Number comparisons and spreadsheet organization were undeniably faster.

But we soon found out something.

There was a bigger gap than expected between the mechanical "mapping" AI came up with and the actual tiers used in the UI that reflected intent and context.

The color math was precise.
The problem was "which 3.0 item to attach this 2.0 token to."

Time and again, it either failed to fully reflect token naming or connected to totally wrong items based purely on the closest HEX value.

So we didn't just pull the CSV once and call it a day.

Extract → Map → Review → Edit → Extract again.

We repeated this process nearly 10 times.

What AI provided was a quick rough draft.

Ultimately, judging "Is this mapping result correct?" was still up to humans.

Overwriting to verify, not starting from scratch

Even after defining the new palette, we didn't delete 2.0 right away.

Instead, we mapped and overwrote the 3.0 values onto the 2.0 palette Variables.

This was to see what changes would occur on the screens already in production.

We checked sections with large color differences first, and re-adjusted screens that looked visually awkward.

This operation was closer to a migration than a reset.

Before declaring a new framework, we stress-tested it thoroughly on top of the existing system.

As a result, choices were narrowed down, and cross-team consensus became faster.

Semantics — A system language, not just a collaboration tool

Semantic tokens (meaning-based tokens) existed in ADS 2.0 as well.

But their purpose was mainly for design collaboration.

For example, a structure like Emphasis / High, Medium, Low describes the degree of emphasis, but it doesn't reveal its role.

Humans can understand it. But a system has no intuition.

So we introduced the concept of Foreground instead of Emphasis.

Foreground doesn't just mean text.

It groups every element that sits on top of a background into a single role.

This change was less a choice to make collaboration comfortable, and more a decision to reduce room for interpretation.

What a design system is, and what it isn't

Sometimes when talking with engineers, I hear things like this.

"It's hard to develop because we don't have a design system."

Hearing this makes me rethink what a "design system" actually is.

Continuing the conversation, the "design system" the engineer is referring to is often closer to *the definitions for drawing a screen (policies and priorities)* rather than tokens or components.

When trying to implement a specific screen, the standards for what to show and in what priority, or what states and exceptions to consider, were often unorganized, leading to repeated moments of getting stuck on, "How should I structure this screen?"

A design system doesn't replace product specs.

It doesn't replace policies either.

It won't make decisions for you.

It merely helps you consistently repeat decisions that have already been made.

And as AI increasingly assists with parts of product planning, how to implement those decisions consistently based on what standards becomes just as important as "what to build."

What we specifically focused on in this revamp was creating clear guidelines that maintain consistency, including states and exceptions.

The question of the right density

As features multiply, a design system becomes a task of both maintaining consistency and managing decision-making cost.

Through this project, we drew a sharper boundary around what the system should and shouldn't handle.

The next step is to move beyond colors and tokens, expanding the standards for how much the system will manage states and exceptions (policies).

The right density is less of a single correct answer and more of a balance.

This time, we essentially just made that balance a bit clearer.

Especially in the AI era, making the "standards for decisions" crystal clear comes before producing more output.