Your Design System Is Becoming a Rules Engine

Sidenote. What localization and white-labeling taught me about where design systems go next, and why Jakob Nielsen got to the same place from a different door.

---

Someone asked me last week what I paid attention to when I was designing UI for SaaS products. The honest answer is localization and white-labeling, which sounds like a boring answer until you sit with what those two things actually do to you.

They force you to stop designing a screen and start designing the conditions under which a screen gets assembled.

I did not have language for that at the time. I do now, and I think it is the most useful way to describe where design systems are headed: the design system is turning into a rules engine for UI.

Someone else got here first

Before I go further: in March, Jakob Nielsen published a capability maturity model for AI in design . It runs six levels, from Limited up to Symbiotic. His description of the top one:

"Designers shift from architects of screens to architects of systems, defining constraints while AI generates interfaces in real-time."

That is designers setting the physics of a product and letting the system assemble the interface from user context.

I had been circling the same idea from the localization and white-labeling side, which is a much less glamorous door into the same room. When two people arrive somewhere from different directions, it is a reasonable bet there is something actually there.

So take the rest of this as the practitioner's route to a conclusion someone with far better data reached independently.

The convention that just broke

For about a decade the working agreement was: build from generalized specs, publish them, and have everyone adapt to them. One set of patterns, one canonical dashboard, and if a customer wanted something different they filed a request and waited two quarters.

That agreement held because buyers accepted it. They do not anymore.

Part of it is AI. People now use software that reshapes itself to them inside a single turn of conversation. Once that is your baseline, a dashboard that shows every customer the same nine modules regardless of what they bought reads as lazy in a way it did not three years ago. The expectation is software shaped to what a company actually does.

The other part is quieter and older: acquisitions. Nobody buys one product anymore. They buy a portfolio and then have to make it feel like one thing. At Omnitracs I worked on unifying acquired products into a single system serving more than 30,000 fleets, roughly a million vehicles, in over 60 countries. You do not merge four products by picking a winner and redrawing the other three. You go underneath them and find the rules they all share.

That is the same job. It just used to be a special case.

What a rules engine for UI actually means

A component library answers one question: what does a button look like.

A rules engine answers a harder one: which button does this tenant get, in this locale, with this feature set, at this permission level, on this plan.

That means three things stop being decisions a designer makes in a file and start being data the system reads.

Entitlement. What did this customer buy. A tenant on three of nine modules should not see six empty rooms with upgrade prompts nailed to the walls. The system needs to know not to draw them, and the layout needs to still hold when it does not.

Locale. Not just translated strings. German runs about a third longer than English. Arabic reverses the reading direction of your entire information hierarchy. Japanese has no spaces to wrap on. If your navigation is pixel tuned to English, it is not localized, it is decorated.

Role. What is this person allowed to see, and what does the interface look like when the answer is "less than the person next to them." Most systems handle this by hiding things, which leaves holes. A rules engine reflows.

None of that is exotic. What is new is that the rules have to be written down somewhere a machine can read, not held in the heads of the three people who have been there longest.

The test I use

Can a new tenant be configured without a designer in the room.

If the answer is yes, you have a rules engine. If the answer is "well, someone would need to look at it," you have a component library with good documentation, which is a fine thing to have and a different thing entirely.

Most teams I have worked with think they are in the first category and are actually in the second. The tell is usually a Figma file named something like Acme - custom.

Where AI actually helps, and where it does not

The temptation right now is to point a model at your design files and ask it to generate the variants. That mostly does not work, and the reason is instructive.

A model cannot infer your entitlement logic from a picture of a dashboard. It cannot see that the reason the reports tab is missing in one screenshot is a plan tier and not an oversight. Your constraints are invisible to it unless you have made them explicit.

Which means the teams getting real leverage out of AI in product design are not the ones with the best prompts. They are the ones who wrote their rules down first. This is, I think, the mechanism underneath Nielsen's top level. You do not get to a system that assembles itself by context until the context is written somewhere a machine can read. The system becomes legible to a machine at exactly the same moment it becomes legible to a new hire, and for the same reason.

That is a satisfying thing to notice. The work that makes AI useful is the same work that makes your team faster without it.

The honest cost

This is slower up front, and it is slower in a way that is hard to defend in a sprint review, because you are designing a system that produces designs instead of designing the thing someone asked for.

It also fails in a specific way: the moment a rule lives in a person rather than in the system, the whole thing quietly reverts to a component library and nobody notices for two quarters. The rules engine is not the tooling. It is the discipline of writing the condition down every single time instead of just handling it.

I have watched that discipline slip on teams that had every other advantage. It slips because writing the rule down takes twenty minutes and handling the exception takes five.

Same shape, much smaller

I have been building a personal project this year, a caregiver-curated video app for teens and adults with autism and intellectual and developmental disabilities. One product, one tenant, no acquisitions, nothing enterprise about it.

It still needed a rules layer, because a caregiver configures what each viewer can see, and two viewers in the same household get materially different interfaces. Designing and shipping that solo, without a team to absorb the exceptions for me, made the cost of every un-written rule immediate. If I did not encode it, nobody else was going to.

That turned out to teach me more about what a design system actually owes a product than any project with a full team ever did.

If you want to start Monday

1. Write down your entitlement matrix. Modules by plan tier, in a table, in one place. Most teams have never seen theirs written out and are surprised by it.
2. Pick your longest locale and design to it. Not your prettiest one. The one that breaks your nav.
3. Audit three components for hardcoded assumptions. Fixed widths, English-shaped labels, icons that mean something specific in one culture.
4. Ask the configuration question out loud. Can a new tenant be stood up without a designer. Sit with the answer.

The shift is from a catalog of parts to a set of decisions the product can make without you in the room. That is uncomfortable, because a lot of us built our careers on being in the room.

It is also the only version of this that scales.

---

I write Building in the Open about designing and shipping products with AI in the loop.

If you want to know where your own team actually sits on this, I built a short assessment that scores two axes separately: how mature your design practice is, and how far your AI adoption has really gone. Most companies are further along on one than the other, and the gap is usually the thing causing the trouble. Fifteen questions, about four minutes, and every benchmark in it is cited. Where you land is free. The full written read comes by email.

Take the assessment