Decide the look yourself.
Write down your colours, type and spacing, give your builder the prompt below, and check the same task after. It's free.
Restyle it yourself →You don't need to start again to fix AI slop design in your AI-built app. Give your builder a short design file you write and one prompt that changes only the look, work one screen at a time, and check the same task before and after. If you would rather have a person do it, we can restyle it for you.
What it is
What is AI slop design?
AI slop design is the generic, default look an AI tool gives a screen when nobody has chosen one. That definition is ours, not a standard.
Your app can work and still have it. You don't need to start again: ask your builder to change only the look, then check that the app still works the same.
Style is not the fault. A gradient, a rounded card or a font is not bad in itself. What hurts is a screen that doesn't tell a new user what to do next, or one that looks different on every page.
To spot it in your own app, see Why do AI-built apps look alike?. This guide is the fix.
Before you change anything
What should I check before I change the look?
Pick the one task that matters most, such as signing up and then reaching the first useful screen.
Screenshot every screen of it on desktop and on a phone. Keep those as your "before".
Use your builder's phone view (Lovable's Mobile view, Bolt's Responsive mode), then open the published link on a real phone. Our post Why do AI-built apps look alike? has three quick tests for whether a new user can say what to do and whether the text is readable. The checks below include them.
Then go through these seven checks. The list and its order are ours, not a standard. Where a number appears, it comes from the W3C's WCAG 2.2.
One obvious next step. A new user can say what to do on the first screen (the first of those three tests).
The same thing looks the same everywhere. Buttons, fonts, colours and spacing match from screen to screen and between desktop and phone.
Readable text. Body text has a contrast of at least 4.5:1 (WCAG 2.2, success criterion 1.4.3). Check on a dimmed phone screen too.
Fits a narrow screen. Nothing runs off the side at 320 CSS pixels wide (WCAG 2.2, criterion 1.4.10).
Easy to tap. Buttons and links are at least 24 by 24 CSS pixels (WCAG 2.2, criterion 2.5.8, the AA minimum). Our Design Playbook recommends more room than that. That is the Playbook's advice, not a rule.
Every state is designed. What people see when there is no data yet, while it loads, after an error and after success.
Buttons say what happens. "Save changes" tells people more than "Submit".
Checks 2, 6 and 7 are our reading, drawn from our Design Playbook.
After the check
The two routes
Or we restyle it for you.
We take the app you have, make it look finished, and keep what works. It's part of Finish and Launch.
See Finish and Launch →Not sure which? The Free Build Audit is the free first look.
What to decide
What goes in a look?
A look is what a designer would hand you: a consistent set of colours, type, spacing and components, applied screen by screen.
A design system is the same idea, kept in a project. You don't need a designer to decide it. You decide seven things once, and write them down.
| Part | What to decide |
|---|---|
| Style direction | One name and one line on who it suits and how it should feel, plus three adjectives your builder understands, such as "minimal" or "premium" |
| Colour | Four to six named roles, such as background, text, main button and warning. Check each text colour against the colour behind it for at least 4.5:1 |
| Type | One or two fonts, with a job for each (headings, body), a size scale and a line height |
| Spacing and layout | A spacing scale, a widest content width, and how things stack on a phone |
| Shape and depth | How round the corners are, and one level of shadow |
| Components | Buttons, inputs, cards and navigation, plus the empty, loading, error and success states |
| Don'ts | What this look avoids, and where it avoids repeating itself |
Write the answers in a short text file, one short section for each part. DESIGN.md is the name of an open format for this, from Google Labs (alpha, free to use under the Apache-2.0 licence). It is plain text, so you can read it and change it yourself. We don't give you a file to download: the choices are yours, and they should look like your product.
Anthropic's frontend-design skill asks for the same kind of short list: four to six named colours, fonts with roles and a layout idea. It also lists tells to avoid, such as identical rounded cards with the same shadow on every block. A rounded card is fine; repeating the same one everywhere with no reason is the problem.
The full walk-through of building your own style guide is a separate guide. This is the short version.
Apply it
How do I fix vibe coding UI without starting again?
Decide your look, write it down, and give your builder a prompt that changes only the look.
Do one screen first, then check. All of it is free, with no sign-up.
Decide and write. Answer the seven parts above in your design file. Keep it under 10,000 characters, so it also fits Lovable's Knowledge field.
Change two or three values first. If you start from a style you copied or a palette a builder suggested, change the main colour, the font and the style's name, so your app doesn't end up looking like every other app that started the same way. Your changed colours and font still have to give body text at least 4.5:1.
Put the file where your builder reads it. Where your builder has a place for it, it's shown in the next section.
Paste the starting prompt below. It starts with the sign-up screen and the screen after it, then stops so you can look.
Compare with your "before." If it is right, carry on, one screen at a time. If it isn't, go back a version.
Never paste a key, token, password or secrets file.
Restyle this app using the design rules in DESIGN.md. Change only colours, fonts, spacing, corner radius, shadows and component styles. Do not change any text, data, pages, logic, logins or payments. Start with [the sign-up screen and the first screen after it], then stop and show me before you continue.
The prompt asks your builder to change only the look. Then you check that text, data, pages, logins and payments are the same. Changing one thing at a time and saying what stays is what Lovable's prompting guide advises. Working one screen at a time and stopping to check is our advice.
Why one screen at a time? A business user building with an AI coding tool wrote on that tool's forum (20 August 2026) that the design only held once they built it block by block. A reply advised keeping a design document in the codebase so the design doesn't drift, and the poster agreed. Your design file is that design document, and the prompt tells your builder to read it.
Which tool you use
Which design tools does each builder have?
Everything here was read in each vendor's own documents on 23 October 2026.
Labels may change. We have not seen these screens in the product.
Lovable
Lovable's docs don't mention DESIGN.md. They do give two places your design file could go:
- A root-level
AGENTS.md. Put your design file in your project's repository and point to it from a rootAGENTS.md. Lovable's docs say root-levelAGENTS.mdfiles are always read. - Project settings → Knowledge. Paste the file there. Knowledge holds up to 10,000 characters per field, and the docs recommend putting design guidelines there.
Both routes are ours, not a Lovable feature for DESIGN.md, and we have not tested them. After the first screen, check that your builder followed the file.
Lovable's preview toolbar (Select elements, Edit text inline, Draw annotation, Add a comment) now replaces Visual edits. Only text can be edited directly. To change a colour, font or spacing, use Select elements and then a prompt. When a request leaves the look open, Design guidance cards ask about Color palette, Typography and Layout before Lovable builds. The device toggle switches between Desktop, Tablet and Mobile view. Lovable's Design systems are a separate project on paid plans, which suits a team library more than a one-file look.
Bolt
Bolt's help centre shows how to add a DESIGN.md file and tell Bolt to follow it. Attach the file in chat, ask Bolt to save it in the project root, then open the gear icon, go to Knowledge, add a rule that tells Bolt to follow it and press Save prompt. Its help page doesn't say Bolt follows the file without that rule. Bolt's visual edits cover selecting, text, colours and font size. They have no control for spacing or font family, and editing is free but tokens are used when you save. Responsive mode shows your app at other screen sizes.
v0
v0 has Design Mode: select an element and change typography, colour, spacing, radius and shadow. Apply saves a new version, and there is a before and after preview. It isn't available on read-only chats or on mobile viewports. Design Systems 2.0 lets you teach v0 your design once; it is saved as a skill and attached from the prompt toolbar. Existing projects don't update on their own. v0's docs don't mention DESIGN.md.
Claude Code and Cursor
Put your design file in your project's root and name it in the prompt. You can also install Anthropic's official frontend-design skill from the public anthropics/skills repository. If you are searching for an anti AI slop skill, that is the official one, and its own description is about "making choices that don't read as templated defaults". Claude Design (Anthropic Labs, research preview, 17 April 2026) builds a design system from your codebase and design files. Anthropic's post doesn't say whether it accepts DESIGN.md, so we make no claim either way.
We don't rank third-party skills or DESIGN.md libraries.
After the first screens
How do I check what changed?
Run the same task again, on the same screens and the same devices, and put the result next to your "before".
Then run the task through to the end, because a restyle can break things. If something broke, go back a version. When your AI builder keeps breaking covers the routine.
Your restyle is done when four things hold:
The same task, recorded before and after on desktop and on a phone, shows no change to text, data, pages or logic.
Body text has a contrast of at least 4.5:1.
After you change the main colour and the font, body text and the main button still meet 4.5:1.
If you use Lovable's Knowledge route, the file is under 10,000 characters.
That is our checklist, not a standard. Check the published version too, not only the preview: a forum post on Replit describes a build that finished with different fonts, colours and spacing from its preview.
A nicer screenshot doesn't prove an app is easier to use, and it doesn't prove it is safer. For that, read our guide to whether your app is safe.
Both routes
Do you want us to restyle it for you?
We take the app you have, make it look finished, and keep what works.
A restyle changes the look, not your workflows, data or logins. It's part of Finish and Launch. See Finish and Launch →
Not sure yet? The Free Build Audit is the free first look. A person on our team records a walkthrough of your app, including how it looks, and sends you a one-page note: what stays, what needs fixing and what blocks launch. It is free. It doesn't promise any result.
It suits you if you have tried a look and gone in circles, or you would rather not touch the app. If you would rather do it yourself, the advice and the starting prompt are above, and they stay free.
Questions
Questions.
How do I fix AI slop design in my app?
You don't need to start again. Check one task on desktop and phone, give your builder a short design file you write and one prompt that changes only the look, and work one screen at a time. Then run the same task again and compare. If something breaks, go back a version.
Is there an anti AI slop skill for design?
Yes. Anthropic publishes an official frontend-design skill. Its own description is about "making choices that don't read as templated defaults" (checked 23 October 2026), and it never uses the word slop. Other anti-slop skills are third-party and mostly cover writing or code. We don't rank them.
Does Lovable support DESIGN.md?
Lovable's docs don't mention DESIGN.md (checked 23 October 2026). They do say a root-level AGENTS.md file in your project is always read, and that project Knowledge holds up to 10,000 characters per field and suits design guidelines. You can put your design file in either. Neither is a Lovable feature for DESIGN.md, and we haven't tested them.
Can I change the design without breaking my app?
Yes, if you say what must not change. Tell your builder to leave text, data, pages, logins and payments alone, change one screen at a time, and stop to check each one. Keep a version you can go back to, then run the same task from start to finish.
Will a new look make my app safer?
No. A look changes colours, type and spacing, not how your app protects your users' data. A polished screen is not proof that an app is safe, and a plain one is not proof that it is unsafe. Safety is a separate check, and our guide to it covers what to look at.
Do I need Figma?
No. You can write your colours, type and spacing in a plain text file and ask your builder to follow it. Bolt's help centre shows how to add such a file, and Lovable reads an AGENTS.md or its Knowledge field. You can write and read the file yourself. Figma is useful if you already have a design in it.
Should I do it myself or ask someone to do it?
Both are fair routes. Deciding the look yourself is free and suits an app you can check screen by screen. If you have tried and gone in circles, or would rather not touch it, we can restyle it for you and keep what works. The Free Build Audit is the free first look.