How to Build a Design System That Stops AI Slop

A designer's guide to AI with taste

At Streaver we build fast. Much faster than two years ago, because AI writes most of the code and on several projects the client writes code too.

That changes what I do. Most projects today don't allow taking days for full research, wireframes, defining a design system, producing final designs and iterating on constant changes. It's not that any of that is wrong, but the product keeps moving while you do it.

What I can do is define the base the AI builds on.

What is AI slop in UX/UI design?

You see it in almost every AI-built product on the market today, and it might just be part of the new reality. The problem is when those interfaces hurt the user experience: unnecessary text, low contrast, text sizes nobody can read, navigation that makes no sense, criteria that contradict each other from one screen to the next.

Example from impeccable.style/slop, which catalogues the patterns AI reaches for by default.

It's not that AI designs badly, it just has nothing to compare against. Every new screen comes out a little different because every time it picks again: another grey, another size, another modal hand-built instead of the one that already exists.

On projects moving fast, where things change constantly, rules that hold the product together are essential.

Case study: a design system for an AI-built product

The client is a golf booking platform with two surfaces: a web app course staff uses all day, and a portal where golfers book their tee times.

The goal was to write the product's design rules down in one place, so that any AI creating a new screen follows them instead of inventing patterns that make the experience worse.

Step 1: Auditing the code before designing anything

Before deciding anything I asked the AI for a report on the code. Count, don't touch.

Some of the things that came back:

• For every color using a token, there were six written by hand
• Three different brand oranges in the code
• 24 text sizes, some of them 6, 7 and 8 pixels
• Around 1,900 hand-built buttons
• Confirmations were built five different ways, including the browser's native popup
• Twelve documents with design rules contradicting each other

That last one is the one that mattered most. Skills someone downloaded at some point, left installed, and the AI uses interchangeably with no criteria for deciding which one to follow.

Step 2: Making the decisions that shape the design system

Three decisions shaped everything else.

1. Based on the report, I decided what stays, what goes and what changes, and built the design system on top of that.
2. The rules apply to whatever gets built from now on. What already exists gets tidied gradually each time someone touches a screen.
3. Having everything recorded as tokens was key. The AI uses whatever already exists in the code, so if there's one value per role, named after its function ("secondary text", not "grey 600"), the AI knows which is the right one.

Step 3: Creating the brand.md and guidelines.md files

The output was two files in the repo: one with the UX guidelines and one with the branding.

The guidelines one is a collection of UX best practices I pulled from different sources, put together for this product and filtered through my own criteria as a designer. The point was not to end up with one more guidelines document like the thousands online, full of rules an AI made up.

The branding one is written in DESIGN.md format, an open format from Google Labs for describing a design system to AI tools. It has two layers: the values up top as data, and prose below explaining when to use each one.

As for the design skills that had already been added to the project: some I deleted, some I pulled valuable information from, and others I kept because they complemented my documents. If an old document stayed around saying the opposite, the AI would follow whichever it read last.

How this holds up: design tokens and automated reviews

A document the AI reads is a strong suggestion; it doesn't necessarily work as a rule. What holds it up is four levels, from weakest to strongest: the documents, the tokens, an automated check, and someone looking at the screen.

Tokens are stronger than the document. They work as a tool; if the right value exists under the right name, the AI uses it without reading anything.

For the automated part I built two things.

A check that compares the code against the branding document. If someone adds a style or value that isn't declared there, it fails.

A weekly report that only looks at what was written that week. It arrives on Mondays with two numbers: how many new values don't match and the comparison against the previous week. Below that, each finding comes with the value that doesn't match and a short explanation of why, where to see it, and the PR it came from. It has only just started running, so there's no trend to show yet.

Testing if the AI is following the design system

This last step gave back the most. I asked the AI for a new screen, without reminding it of any rule and about something that didn't exist in the product, so it wouldn't copy from another screen.

It came out pretty well, but not perfect. A few things came out wrong, for different reasons:

• The document had the answer, and the AI didn't follow it. When two rules pulled in different directions, it picked the convenient one and flagged the problem instead of fixing it. So the document now says explicitly which rule wins when they clash, and that a known violation gets fixed.
• The document didn't have the answer. It said what a component should follow, but not how it should be built. And where a case didn't fit any category, the AI guessed differently each time. These gaps only show up by testing, so each one becomes a new rule or a concrete example in the document.
• Plain bugs, unrelated to the documents. Small implementation errors the AI caught and fixed itself by testing in the browser. No rule prevents these; what does is making that check part of the process every time a screen is built.

Before and after example: same screen, new rules

Here's a before and after of the Events page. Same information but following the rules that were written down.

Original screen

Version following the new docs

What changed:

• More events fit at a glance.
• Color means something again. In the second image, red appears once in the overdue balance. In the first every amount is orange, so the color says nothing.
• The filters show their counts, so you know whether narrowing down is worth it before you do it.
• The language is the one the staff uses: "still to collect", "past its due date", "paid in full". The first version repeats "Balance Due" on every card and shows raw dates.
• Events are grouped by month, which is how anyone running a venue thinks about a calendar.

Key takeaways

I went in thinking the product needed more rules. It turned out it needed fewer, and ones that didn't contradict each other.

It's worth testing, more than once. Asking for a screen and watching what the AI makes up is the most honest feedback a document can get. Every time it guesses, it's showing you exactly where you haven't been clear yet.

This is only one part of how we work at Streaver, and it isn't a recipe. Nothing about working with AI is settled yet, and that's part of what makes it fun. The best thing you can do is try things, see what breaks, and find the way that works for you and your team.