AI and Design Systems

If you work on design systems, AI is already in your job, and nobody asked you first. Annoyingly, it’s great at some of it.

Give it a button with five states and it’ll produce every variant with the right tokens in minutes, most of the way to production. The rest is edge cases and deciding whether the pattern was right in the first place, which is where the real time goes. It drafts documentation too. The drafts are generic and never explain why anything was decided, but editing a bad draft beats staring at an empty page. Naming tokens and spotting inconsistent values is rule-following work, and it does that reliably.

Component variantsAll states and conditions from an established pattern, tokens appliedBy hand → most of it in minutes

DocumentationFirst-pass docs from component specs, needs editing, faster than blankBlank page → a draft to edit

Token namingSystematic naming conventions, inconsistency flags, hierarchy proposalsManual checks → done reliably

What’s left in each case is the judgment call: whether the pattern is right, why it was decided, and whether the abstraction holds.My estimates, not measured.

The trouble starts when people treat making artifacts and making decisions as the same job.

The hardest question in systems work is whether something should be a component at all. That depends on what keeps coming up in your product, and on which differences are real and which are just drift from people working without agreements. A model has no idea about any of that. It wasn’t there when your team made those calls, and it doesn’t know which ones were compromises or which ones exist because someone senior really liked purple.

It can’t write the rules for how things behave either. It can tell you what a dropdown looks like. It can’t decide how filters should persist when someone switches views, or what an empty state should say halfway through a compliance workflow. You only know that from living with the product.

At Scaler I saw what happens when a system is built without those decisions. Navigation looked the same in every module and behaved slightly differently in each one. It all looked polished and felt unreliable, and users are very good at noticing the second part. AI would have tidied up the visual side even faster and never noticed the rest.

Back works the same in every module

Emissions

Needs review

Suppliers

Needs review

Illustrative data

Don’t

Back looks the same and behaves differently

Emissions

Needs review

Suppliers

Needs review

Illustrative data

Visual layer

Components look consistentSpacing, colour and type tokens applied

Variants generated at speedStates and conditions all present

Documentation existsCoverage is high

Looks polishedThe surface holds together

Behavioural layer

Interaction contracts missingNo shared standard for how filtering, drilling, persisting work

Decisions made independentlyEach module solved the same problem differently

Empty states context-freeNo behavioural meaning, just visual presence

Feels unreliableThe behavioural layer was never standardised

AI tidies up what it can see. How things behave, persist and what they mean in context never shows up in the files it reads.

So I use it for the artifacts and keep the decisions with people. That split has saved me a lot of time, and a few arguments.

Tamara Milakovic is a senior product designer specialising in B2B SaaS, design systems, and the decisions upstream of the brief.

When to Standardise and When to Leave It Alone

Please Don’t Let It Sit at 99%

When Should a Form Tell You You’re Wrong?