AI Design Slop: Fix a Generic Page With a Checkable Brief
To fix AI design slop, give the agent a specific visitor, a decision to support, real content and checks it must pass. Then inspect the rendered page and request concrete changes.
“Make it more modern” leaves too much open. For a meeting-room page, “put capacity and hourly price beside each room” gives the agent a visible job.
This guide includes a copyable brief and a constructed before-and-after example. The example uses the same fictional room facts in two static HTML pages. It illustrates how to review a change; it does not measure which AI tool designs best.
Key Takeaways
- Describe the visitor's task before choosing a visual style.
- Give the agent facts and a clear order of importance.
- Compare the rendered versions at the same screen size.
- Check specific text contrast, controls and mobile behavior before calling the page finished.
What counts as “AI design slop”, and how do you make the fix checkable?
AI design slop means a generated page that looks finished but does not help a specific visitor complete a task, so the fix is a checkable brief and a rendered comparison rather than a new style. A rounded card or purple button alone cannot tell you who made a page.
The useful question is whether the design helps someone complete a real task. Can a visitor compare the options? Does the primary button explain what happens next? Is the text readable?
A Claude Code user asking how to improve repetitive UI described this problem directly. They wanted different interfaces instead of recurring rounded boxes and styling. That is one observed question, rather than evidence that every generated website has the same problem.
Before asking for a redesign, write one sentence:
“This page helps [person] choose [thing] using [information].”
For our example: “This page helps an office coordinator choose a meeting room using capacity and hourly price.”
That sentence changes the review. An impressive headline matters less than being able to find a suitable room.
What does a before-and-after example look like with the same room facts?
The example compares two versions of one fictional meeting-room page that use exactly the same room facts, so the only things you judge are structure, wording and the primary action. These names, capacities and prices are example data:
| Room | Capacity | Hourly price |
|---|---|---|
| Alder | 6 people | USD 24 |
| Birch | 12 people | USD 38 |
| Cedar | 24 people | USD 60 |
The constructed baseline has a large promotional headline, a generic “Get started” link and separate room cards. Each card contains its capacity and price.
The revision moves those facts into a comparison table and uses “Check availability” for the primary link. Both links lead to the same demonstration booking section.
View the full-size page comparison. Both versions contain the same fictional room facts.
We built and rendered both pages with AI assistance on October 29, 2026. The baseline was deliberately written to illustrate common review problems. We then implemented the specific revision described below.
This is one constructed example. It includes no customer testing, live bookings, conversion results or cross-model comparison. We did not install or benchmark Impeccable for this exercise.
What should a design brief contain to avoid slop?
A brief that prevents slop names the page, the visitor, the decision to support, the verified facts, their order of importance, one main action and the checks the page must pass, and it marks anything unknown before the agent starts.
Replace the room facts with your own verified information. If a detail is unknown, mark it as unknown before the agent builds the page.
Page: Meeting-room comparison and availability entry.
Visitor: An office coordinator planning a team meeting.
Decision: Choose a room that fits the group and budget.
Facts:
Alder: 6 people, USD 24 per hour.
Birch: 12 people, USD 38 per hour.
Cedar: 24 people, USD 60 per hour.
These are fictional demonstration values.
Information order:
Explain the service, then show capacity and price together.
Use one main action: "Check availability".
Keep the room selector clearly labeled.
Visual direction:
Use a quiet, readable layout with a clear text hierarchy.
Use decoration only when it helps explain or group content.
Preserve the room facts and the availability destination.
Checks:
Render at 390px and 1280px viewport widths.
No page-level horizontal overflow at either width.
Check the actual text/background colors for contrast.
Confirm the primary link reaches the booking section.
Keep the room label associated with its selector.
Report what was checked and what remains unverified.
The brief gives the agent something more useful than a list of forbidden styles. It specifies what the page needs to communicate and what must remain intact.
The visual direction can change for a bakery, a gallery or an internal dashboard. The visitor and decision should change with it. Copying the example's palette onto every project would create another default.
How do you compare a rendered page against the brief?
Compare the rendered page with the brief at the same viewport widths, checking the main message, the facts needed to choose, the primary link text and measured text contrast rather than a screenshot alone. The checks below describe those files and those widths.
| Check | Constructed baseline | Revision |
|---|---|---|
| Main message | Broad promotional headline | Meeting-room task stated directly |
| Room comparison | Capacity and price inside separate cards | Same facts aligned in a table |
| Primary link text | Get started | Check availability |
| Body font size | 14 CSS pixels | 16 CSS pixels |
| Selected secondary-text contrast | About 2.95:1 on white | About 8.42:1 on the page background |
| Page-level horizontal overflow | None at either tested width | None at either tested width |
| Room label association | Present | Preserved |
The contrast measurements use the selected text colors and their backgrounds. The baseline room-detail text is #9c92ad on #ffffff. The revision uses #354d4d on #f7f7f1.
W3C's explanation of minimum contrast gives a 4.5:1 threshold for normal text, with specified exceptions. The chosen baseline pair falls below that threshold; the revised pair exceeds it.
That is a check of two color pairs. A complete accessibility review would need to inspect the rest of the interface, its states and its behavior.
Some checks already passed in the baseline. Both pages avoided horizontal overflow at the tested widths. Both associated the room selector with its label. Those results belong in the comparison too.
How do you ask for the next correction and render again?
After each edit, ask for one correction tied to a problem you observed and re-render both versions at the same width to confirm it landed. It cannot confirm every interaction.
After the agent edits the page, use the page itself:
- Open both versions at the same viewport width.
- Read the headline and compare it with the visitor's task.
- Find the information needed to choose an option.
- Follow the main link and check its destination.
- Move through the controls with the keyboard.
- Repeat at a narrow width and inspect text wrapping.
For form controls, W3C's labeling tutorial explains how a label's for value should match the control's id. A visible word beside a selector is not enough to establish that connection.
Write the next request as an observable change:
Keep the three room names, capacities and prices unchanged.
Place capacity and hourly price in the same row for each room.
Keep the primary action linked to the booking section.
Render the revised page at 390px and check for horizontal overflow.
Show the result and identify any checks you could not perform.
If the agent cannot open a browser, ask it to say so. Treat code inspection as code inspection, and make the visual check yourself.
When two agents share the project, a shared worklog can carry the agreed brief and unresolved checks into the next session.
Do design skills for coding agents fix slop?
A design skill gives a coding agent shared vocabulary for critique, audit and polish, but it still needs your product facts and your judgment about the rendered result. Its official materials distinguish work such as critique, audit and polish.
That vocabulary can help you ask for a particular kind of review. It still needs the product's facts and your judgment about the result.
For the Fieldroom exercise, we used our own written brief and static pages. The results above support that example only. They provide no basis for choosing Impeccable over another design tool.
The same evidence boundary applies elsewhere: our REA guide explains why a tool's report and a verified runtime result answer different questions.
Which change should you ask for next?
Pick the next request from a problem you can see on the page, not from a general wish for a nicer design; the table below pairs each observation with one useful request.
| What you observe | A useful next request |
|---|---|
| Visitors cannot tell what the page offers | Rewrite the main message around the actual task |
| Comparing options requires hunting through cards | Align the decision facts in a consistent structure |
| The button could belong to any product | Name the next action and verify its destination |
| Secondary text is difficult to read | Measure its actual foreground/background contrast |
| Desktop looks fine but mobile feels crowded | Check content order, wrapping and overflow at a narrow width |
You can stop the first revision when the page communicates its purpose, preserves the facts and passes the checks you set. Save what changed and keep unresolved issues visible.
For a new project, begin with the visitor's decision. Fill in the brief, make one focused revision and inspect the result before requesting another.
About the author: JH-A publishes practical AI workflows at Charrette AI Room. The examples here use original fictional data and documented local checks.
Editorial note: This post was drafted with the help of AI writing tools, based on my own tests and notes. The page examples were also created with AI assistance.
Source notes: Official Impeccable materials and W3C guidance were checked on October 29, 2026. The community link documents a reader question. Original measurements apply only to the constructed Fieldroom files and the stated viewports.
Frequently Asked Questions
What is AI design slop?
AI design slop is generated work that looks polished but does not help a specific visitor complete a specific task. A rounded card or a purple button alone does not prove it; whether a visitor can compare options and act does.
What should a design brief contain so the page is not slop?
The page, the visitor, the decision to support, verified facts in order of importance, one main action and the checks the result must pass. Unknown details are marked as unknown before the agent builds anything.
How do you check the generated page?
Render both versions at the same viewport width and compare the main message, the comparison structure, the primary link and its destination, keyboard order and measured text contrast. The example here was checked at 390 × 844 and 1280 × 844.
Does a design skill replace the brief?
No. A design skill gives the agent words for critique, audit and polish, but the product facts and the decision about the rendered page stay with you.
Comments
Post a Comment