Slides 👇

Recording 👇

Your Users Can Smell AI Slop From a Mile Away

Merriam-Webster picked "slop" as one of its defining terms of 2025, and if you've spent any time on a startup landing page lately, you already know why. Harsh purple-to-blue gradients. A bento grid stacked with icons that all came from the same free set. Copy that reads like it was generated to fill space rather than say something. None of it is broken, exactly. It just feels off, and users have gotten remarkably good at naming what "off" means.

That was the topic of our August Design XP community call: AI slop, what it actually looks like in a product, and how designers can keep using AI without letting it make their decisions for them.

What AI slop actually looks like

AI slop isn't one bad choice. It's a cluster of default choices, all made by the same tool, all showing up in the same place. On the call, we walked through the visual markers that tend to give it away:

• Harsh, oversaturated gradients used as a background instead of an accent

• Lucid-style icon sets applied uniformly, regardless of whether they fit the product

• Pure black or pure white backgrounds with no tonal variation

• Emoji used as a substitute for iconography or hierarchy

• Bento box grids applied to content that doesn't actually have bento-shaped relationships

• The same handful of "grotesque" typefaces showing up everywhere, at every weight

  
  

Individually, none of these are design sins. A bento grid can be the right call. So can a bold sans-serif. The problem shows up in combination and repetition without a reason. When five of these markers land on one screen, it's usually because a model defaulted to its training data instead of a person making a call about this product, for this audience.

We also spent time in a tool called Impeccable, a Chrome extension built to flag these patterns (soft glows, overused drop shadows, telltale color palettes) on live sites. It's less about shaming any one site and more about training your eye. Once you've seen the pattern named a dozen times, you start catching it in your own Figma file before a client does.

Why it costs you more than you'd think

Good design is supposed to be close to invisible: the user completes their task and doesn't think much about how. AI slop breaks that. When an interface visibly announces "an AI made this," it adds friction that has nothing to do with usability. The user starts wondering if the product itself was thrown together as quickly as the screen looks like it was.

That reaction came up repeatedly from the group. Several designers on the call associated generic AI interfaces with a lack of empathy for the end user, not because the AI can't produce functional layouts, but because functional isn't the same as considered. For an early-stage product trying to earn trust, that gap is expensive. It's the difference between "this feels like a company I'd give my email to" and "this feels like a template."

A framework for balancing speed and quality

None of this argues against using AI in your process. It argues for using it on purpose. The framework we use at Design XP is cupcakes, birthday cakes, and wedding cakes: not every project needs the same level of craft, and knowing which one you're baking changes what you're willing to automate.

A cupcake is a quick internal tool or a one-off prototype, where AI-generated scaffolding is often fine. A wedding cake is a flagship product experience, or anything customer-facing that's meant to differentiate you competitively. That's where AI output needs real guardrails: a "forbidden patterns" markdown file the model has to respect, a moodboard that defines the actual visual direction, and a critique process before anything ships.

The guardrails matter because AI is genuinely useful for early iteration; it's fast at generating options. The risk isn't the tool. It's skipping the step where a person decides which options are worth keeping.

Build the manual foundation first

The clearest example from the call came from student work. Apprentices who spent time on manual foundational work, like research synthesis, wireframes reasoned through by hand, and a documented rationale for layout decisions, consistently produced stronger final screens than those who jumped straight into a tool like Figma Make and generated a polished-looking interface on the first try.

The gap wasn't visual polish. It was explainability. A designer who built the foundation themselves can walk you through why a button is secondary instead of primary, or why a form is one column instead of two. A designer who generated the screen can usually only tell you it looked right. In a portfolio review or a client meeting, that difference shows up fast. It's the whole reason Design XP's case study reviews go line by line, letter by letter, asking "why" until the answer holds up.

Deciding what to outsource

The honest answer to "is this AI use slop, or is it fine" isn't binary. It depends on the product and what you're actually trying to communicate. What separates deliberate AI use from slop is whether you set the criteria before you started: which parts of this project can a model help with, and which parts need to stay entirely in your hands because they're where the product's actual differentiation lives. Decide that up front, and "using AI" stops being a synonym for "outsourcing judgment."

When stakeholders want it fast

This is usually where the conversation gets real: a founder or client wants something shipped now, and "let's do more discovery first" sounds like the opposite of speed. The reframe that came up on the call is to position planning (a short workshop, a prioritization pass on use cases) as the thing that prevents design debt, not the thing that delays the launch. Time spent agreeing on what actually matters to the user tends to be repaid many times over once you're not rebuilding a feature nobody asked for. Framed that way, moving fast and being intentional stop being in tension.

We closed the session by pulling up a handful of live sites and picking out the tells together: neon palettes with no restraint, container layouts with no real structure, button hierarchies that don't match what the product actually needs users to do. It's a useful exercise to run on your own work, too. Pull up your last shipped screen and ask what a stranger would flag first.

If you want to go deeper on any of this, the forbidden-patterns approach, structuring a real design critique, or getting that kind of line-by-line feedback on your own case study, that's most of what we do inside the Design XP apprenticeship. Recordings, slides, and the Impeccable link from this session are also up in the community Discord.