anti-slop-ui

Anti-Slop UI

The rule

Every color, effect, badge, animation, and line of text on a screen must tell the person using it something they need on that screen. If it is there because generated UI usually has it, it is slop: the default output of a model with no vision for this product. People recognize it at a glance and trust the product less.

"Make it modern and polished" means restraint: fewer colors, flat surfaces, clear type, and plain words. It never means more effects.

Follow the project first

Before you write any style, look for the project's own design language: design tokens, a theme file, a Tailwind config, a component library, existing CSS variables, an icon package, a font already loaded. If one exists, use it, and apply this skill only to what you add. If the project's language itself uses a thing this skill calls a tell (a brand gradient, a glass effect), keep it where the project uses it and do not spread it further.

If the user explicitly asks for one of the tells ("add a gradient to the hero"), do what they asked, once, where they asked. Their request is the reason the element exists.

Build it in this order

Decide these before writing the first rule of CSS, and write the decisions as variables or tokens at the top, so nothing downstream invents a new value.

1. Palette: 60–30–10. One neutral family for about 60–70% of the surface (backgrounds, body text), one secondary for about 20–30% (panels, borders, secondary text), and one accent for at most 10% — the primary action and the one thing that needs attention. Red, amber, and green appear only for real status (an error, a warning, a success the user caused). Name each token for what it does (--color-action, --color-danger, --color-text-muted), never for its hue or position (--purple, --gradient-start); a color you cannot name by its job does not belong. No color literal appears outside the token block. More than two hues besides status colors needs a reason you can state.
2. Surfaces: flat. Solid fills and one-pixel borders. No gradient backgrounds, no radial "glow" blobs behind the page, no gradient buttons or text. A gradient is allowed only when it depicts a range of values (a heat scale, a progress fill between two meaningful ends).
3. Shape: one radius scale, no fingernails. One or two radius values, small on controls (around 4–8px). Group content with spacing, headings, and dividers first; draw a box around it only when it is a separate object the user acts on. Do not put a thick colored stripe down one edge of a rounded card (border-left: 4px solid plus border-radius, which curves the stripe into a fingernail). A colored edge is allowed only when its color encodes a state that differs from card to card, such as overdue against on time, and then it follows the badge rule in step 7.
4. Type: chosen, not defaulted. A font the user named or the project already loads wins, whatever it is. With neither, do not pick silently: recommend two or three options that fit this product (a single family, or a display face for headings paired with a readable body face), each with a one-line reason (its tone, its legibility at the sizes this screen uses, how it loads — self-hosted, a font service, or already on the user's machine), and let the user choose. The system stack (system-ui, sans-serif) is one option among them, not the answer. If you must proceed before the user answers, use your first recommendation and say in your report that the font is open. Do not reach for Inter or JetBrains Mono only because the product is technical. Use monospace only for code, paths, commands, and values the user copies — never for a whole page. No //, >_, $, blinking cursors, or macOS window dots as decoration. Use sentence case: no uppercase or small-caps labels sprinkled over the page, no small letter-spaced label above each heading, and no section numbers ("01", "02") on sections that are not steps in an order. Separate items with layout (a gap, a column, a line break), not a row of middle dots (·).
5. Icons: real icons or none. The project's icon set, or inline SVG with a viewBox that matches its drawn size. Never emoji in the interface itself (labels, buttons, headings, list markers, empty states). Emoji belong only in content the user wrote.
6. Copy: for the user's task, not from the chat. Write every string from what the person on this screen needs to do or know. The brief, the client's reasons, the business story ("we merged three apps"), and the stack or editor the author uses are context for you, never text for them. Headings are plain nouns ("Timetable", "Machines"). On a page that must sell, a headline says what this product does in words its founder would say out loud; if it could sit on any other product's page ("Scale without limits", "Your all-in-one platform"), rewrite it. No tagline, no grey subtitle under every heading, no "Welcome back, Jordan ✨". A working screen is a tool, not a landing page. Build only the sections you have real content for: no FAQ without answers, no testimonials, stats, or feature grids you invented to fill the page, and no "Lorem" or "Coming soon" left in shipped markup.
7. Badges and motion: only for state that changes. A badge or status dot must stand for a state that can differ — between two items in the list, or between two moments the viewer will see. A student ID shown only to logged-in students cannot be "inactive"; an ID card does not need "verified" on it. Animation is only for two things: something in progress right now (syncing, uploading, a live connection being established), and brief feedback to the user's own action (a button's hover, press, and focus, an input's focus, a toggle switching). Nothing settled pulses, glows, or blinks. Content does not fade or slide in as the user scrolls, carousels do not rotate content on their own, and the page never takes over the scroll wheel.
8. Effects: none by default. No glassmorphism (backdrop-filter: blur, translucent panels over blobs) and no brutalism as a default style. Both predate generated UI and both can be right on purpose; the tell is reaching for them with no reason. Use a shadow only to show that something floats above the page (a menu, a dialog).
9. Hierarchy: one thing first. Decide the one element the user came to this screen for and make it bigger, heavier, or closer to the top than the rest; let secondary elements recede in size and color. Consistent tokens do not mean equal weight: cards take the height their content needs, and not every section gets the same padding and the same treatment. Show what the user needs now and put the rest one step away (a disclosure, a tab, a detail view, a menu) instead of every panel, filter, and export at once.
10. States: empty, loading, and error too. Every view that shows data also has an empty state (what this is and the one action that fills it), a loading state, and an error state in plain language that says what happened and what to do. Build them in the same pass as the full view; they are invisible in a screenshot and the first thing a new user sees.