Antislop UI

antislop-ui

Anti Slop: Rules for AI Coding Agents. UI & Visual skill

Part of the antislop system. Read together with antislop.md (the core). This skill deep-dives the UI/visual concern: color, layout, components, decoration, structural flow, and motion. It references core rules by number and never duplicates or renumbers them. Load it when the task builds or edits a website, web app, or any interface.

How to use this skill

• Load together with antislop.md whenever the task is UI or visual work. The core holds the mechanism (the purpose test, the three tiers, the Delivery Gate); this skill holds UI-specific depth.
• Every entry has the same shape: Tell (the pattern), Why (why it reads as slop), Fix (what to do instead), with the governing core rule cited as R-XX.
• The Delivery Gate in the core remains the gate. The "UI Skill Checklist" at the end of this file is the UI-specific supplement to run alongside it.

Visual & Color

Generic Blue-Purple Gradient

• Tell: blue-to-purple, blue-to-cyan, or purple-to-pink gradients used as the primary color treatment, or a full-page colored glow.
• Why: the most over-represented color treatment in training data. It signals "no brand identity", not "our palette", and marks the design as AI-generated at a glance.
• Fix: pull the palette from DESIGN.md or the product's own identity. Keep a gradient only as a hierarchy function with the reason written down (R-01). A gradient separating one level from another is craft; the same gradient on every section is a default.
• The same default family: harsh or rainbow gradients, purple-and-black schemes, neon or pastel palettes, and blurred radial orbs behind the hero. They are the same tell wearing different clothes: color from the model's default, not from the brand. All of them are FORBIDDEN as defaults without purpose (R-01).

Excessive Glassmorphism

• Tell: blur/backdrop-filter on the navbar, cards, modals, and sidebar at the same time.
• Why: blur removes texture and sits every surface in the same frosted layer, flattening hierarchy. When every surface is glass, nothing is foreground.
• Fix: treat glass as an accent, not a character trait. Dose cap: at most 1-2 elements (R-10). The surface that needs the attention gets the glass; everything else stays solid.

Excessive Border Radius

• Tell: every element is pill-shaped: buttons, inputs, cards, badges, modals.
• Why: uniform pill shapes erase the visual language of "this is an input, this is a card". Radius becomes decoration instead of a hierarchy tool.
• Fix: set a small set of radii in the design system and apply them deliberately (R-11). One generous radius on the primary CTA reads as intentional; the same radius on every element reads as a default.

Overly Soft Shadows

• Tell: every component carries a large shadow, so the whole page feels like it is floating.
• Why: when everything is elevated, elevation communicates nothing. The page loses its ground plane and becomes generic softness.
• Fix: use shadow as an elevation marker only, and write the elevation reason down (R-12). Most elements should sit flat; the one or two that need to lift above the page carry the shadow.

Glow Everywhere

• Tell: glow on cards, buttons, icons, badges, backgrounds, and borders simultaneously.
• Why: glow is an attention amplifier. Applied everywhere it amplifies nothing, and it is one of the fastest ways to look "made by AI".
• Fix: reserve glow for a maximum of 1-2 important elements as a focus accent (R-13). Everything else stays matte.

Background Grid

• Tell: grid squares, blueprint lines, graph paper, dot grids, or thin repeating lines behind content.
• Why: it is a default way to make a flat page feel "technical" without doing any real work. It reads as texture without intent.
• Fix: use texture or pattern only when it genuinely supports the product's identity, with the reason written down (R-07). A real identity motif (core Part 3) beats a stock grid every time.

Dark Mode Default for No Reason

• Tell: the whole page is dark simply because it looks "tech", with no branding consideration.
• Why: dark is a decision, not a default. Forcing it reads as following a trend, not serving the product.
• Fix: choose the theme from brand identity, product type, and audience (R-21). Developer and creative tools have legitimate reasons for dark; a content-first product usually does not. If there is no strong reason for a fixed theme, build a working light/dark toggle.

Too Many Colors in the Palette

• Tell: 5-7 different colors on one page with no clear design system.
• Why: a scattered palette has no hierarchy. When every element can be any color, nothing is distinguished.
• Fix: cap the active palette at 2-3 core colors + 1 accent (R-29), and let one of the cores be the neutral base. Restraint is what makes the accent land.

Excessive Accent Color

• Tell: one accent color on buttons, icons, badges, links, lines, backgrounds, and glows at once.
• Why: the accent stops being an accent the moment it is everywhere. It becomes just another color, and the design loses its focal point.
• Fix: the accent belongs at the key moment only (one deliberate accent, core Part 3). Zero accents is sterile; an accent everywhere is slop. Choose the one or two places it matters.

Sterile Default

• Tell: flat white or near-white, thin grey borders, small radius, no texture, generic font, no identity.
• Why: this is the "safe" result of over-filtering without direction. It is not slop, but it is not design either: it is a void where a design should be.
• Fix: this is a direction problem, not a filter problem. Add DESIGN.md or resolve the Design Read (core Part 3), then raise the liveliness dials. The fix is never more bans; it is state the purpose and add energy.

Layout & Components

Monotonous Template Layout

• Tell: hero, subtitle, 2 CTAs, screenshot, feature grid, testimonials, FAQ, CTA, footer, in that order, every time.
• Why: the order is the training-data default, not the product's narrative. Sections appear because the template has them, not because the content needs them.
• Fix: build the structure around actual content needs (R-05, C-3). If the product has no testimonials, there is no testimonials section. Section order follows the product's story. Match the RHYTHM dial: if it is 3, sections visibly vary.

Copy-Paste Feature Cards

• Tell: identical size, height, icon, layout, and padding across all feature cards.
• Why: uniform cards flatten the content. When every feature is a card with an icon, the features with real weight and the ones without look the same.
• Fix: create variation that reflects content hierarchy, with the reason written down (R-14). Not every feature needs to be a card. The flagship feature may deserve a full-width treatment, the supporting ones a list.

Bento Grid

• Tell: a section made of a mosaic of differently-sized cards, some spanning two columns or two rows, filling the space like a tiled dashboard.
• Why: it is the default "app-like" landing layout of the last few years, so it signals nothing about the product. When every section could be a bento, the layout is a template, not a decision.
• Fix: use a bento grid only when the content genuinely has elements of different sizes to show (R-05). If every cell is roughly the same, a simple grid or list is more honest. The RHYTHM dial decides whether sections vary at all.

Uniform Spacing

• Tell: padding, margin, and gaps are identical across every section.
• Why: rhythm is a tool, and a single spacing value removes it. Sections stop relating to each other; the page reads as one flat strip.
• Fix: use whitespace as structure (core Part 3) and vary it with the RHYTHM dial. Establish a spacing scale, then use different levels to separate and connect. Uniform rhythm is a deliberate choice only when the dial says so (R-05).

"How It Works" Always 3 Steps

• Tell: round icon + number 1, 2, 3 + short text, always three steps, always the same shape.
• Why: the product's real process is rarely a tidy three-step list. The template forces the process into its shape, not the other way around.
• Fix: present the process as it actually is (R-05). Three steps with round icons is fine if that is genuinely the process; otherwise use whatever shape the real workflow takes, including two steps or five.

"Trusted By" Logo Bar

• Tell: a row of generic company logos directly below the hero.
• Why: it is a trust claim with no evidence: generic logos, no real customers named, no proof of use.
• Fix: only show real, verifiable logos (R-18, R-36, C-5). If the product has no such customers yet, do not fabricate a logo bar. Real social proof beats a generic one every time.

"Most Popular" Pricing Card

• Tell: the middle pricing tier always highlighted with a capsule badge.
• Why: it is the default pattern, which means it is not a decision. When every pricing section does it, the highlighted tier stops meaning anything.
• Fix: highlight the tier that actually serves the product's goals, and write why (R-31). If no tier deserves emphasis, highlight none.
• Three columns is part of the tell: pricing shown as three tiers whatever the real structure, the middle one highlighted. That shape is the default, so it is not a decision (R-05). Use as many tiers as the product really has, and highlight the one that serves it.

Demo Without a Product

• Tell: the page sells a product that is never shown working: no real demo, no Terms of Service, no Privacy Policy, just promises.
• Why: it is a demo wearing a product's clothes. Every claim is trust with nothing behind it, and the missing legal pages are the quiet tell that nothing real exists yet.
• Fix: show the real product working, or say honestly that it is not shipped yet (R-38, C-5). If the page asks for signups or payment, the Terms of Service and Privacy Policy must exist. An honest "coming soon" beats a convincing demo.

4-Column Template Footer

• Tell: Product / Company / Resources / Legal columns with no variation.
• Why: the columns exist because templates have them, not because the site has that many link groups.
• Fix: structure the footer around what the product actually links to (R-05). A single column of links can be more useful than four half-empty ones.

Uniform Section Rhythm

• Tell: every section is centered title + subtitle + identical card grid, with no variation.
• Why: identical composition makes sections blur together, and the page feels repetitive and flat.
• Fix: vary composition with the RHYTHM dial (R-05). Alternate text-heavy and visual sections, asymmetric and symmetric layouts. A page where every section follows the same template is a page designed by a template.

Decorative Elements

Generic AI Icons

• Tell: sparkle, star, magic, lightning, diamond, cube, robot, or AI orb as feature icons.
• Why: these glyphs are the generic vocabulary of "AI product". They communicate nothing about the specific feature.
• Fix: use icons genuinely relevant to the content, with the relevance written down when the glyph is generic (R-04). If no appropriate icon exists, use none. The feature label does the work.

Lucide Icons

• Tell: every icon comes from the same thin-stroke, rounded-corner library (Lucide or a visual clone), so all icons share one recognizable look.
• Why: a single default icon library makes every AI site's icons identical, so the icons stop telling you anything about the product. The glyphs may be relevant; the uniform library look is the tell.
• Fix: the icon set is a visual choice, not a default (R-04). Pick icons for relevance first; then decide whether the library's weight and stroke suit the product's character. Two icons that look "same-ish" can still read as yours if the set is a decision, not an import.

Emoji as Decoration

• Tell: literal emoji scattered through the copy, headings, badges, and buttons: 🚀 in a headline, ✅ beside every feature bullet, 🔥 on a CTA, 📈 above a chart title.
• Why: emoji is the loudest shorthand for "this was generated, not written". In a UI it competes with the content for attention and flattens the product's voice into the same cheerful default as every other AI site.
• Fix: remove emoji from UI text. If a concept needs a mark, use a real, relevant icon with the reason written down (R-04), or no mark at all. The copy carries the meaning; the emoji adds nothing.

Small Arrows on Every Button

• Tell: → or ↗ placed on almost every button as pure decoration.
• Why: the arrow becomes a pattern, not a signal. When every CTA has one, none of them point anywhere specific.
• Fix: arrows are not the default identity for buttons (R-08). Keep them for the action that genuinely benefits from a direction cue, sized proportionally, with the purpose written down.

Colored Left Stripe

• Tell: a thin colored vertical bar on the left edge of cards, list rows, or section headers, used as decoration.
• Why: the stripe adds color without adding meaning. It is the cheapest way to make a card "look designed", so it appears everywhere and says nothing.
• Fix: the stripe is decoration; it must carry information or go (R-01, R-31). A left edge that marks real state (active, warning, new) is a signal. A stripe that exists to look designed is a default.

AI Capsule Badges

• Tell: pill shape, thin border, glow, small dot, uppercase, containing "AI Powered", "Beta", "New".
• Why: the capsule-plus-glow-plus-dot combination is a self-referential badge that says "made by AI, about being made by AI". It adds noise, not information.
• Fix: badges only when functionally needed, with the need written down, and never the full combination (R-09). A real status label is fine; a decorative "AI Powered" pill is not.

Eyebrow Badge Above the Headline

• Tell: a small pill sitting directly above the H1, often with a dot and a thin border, holding a category label ("Aplikasi Tagihan UKM", "The platform for teams") that the headline beneath it already says.
• Why: the badge duplicates the headline, so it adds a line of reading without adding a fact. It lands in the same spot on every generated page, which is why it reads as a template rather than a decision. When it carries a dot as well, it borrows status-indicator language for a label that marks no state.
• Fix: cut it and let the headline do the work. If the label carries information the headline does not, fold it into the headline or the subheadline, where it reads as content instead of ornament. A badge above the fold needs a written reason like any other badge (R-09), and a dot inside it needs a real state to mark (R-31).

Decorative Status Dot

• Tell: a small colored dot beside a heading, eyebrow, nav item, or label, usually glowing and pulsing on a loop, that marks nothing. It borrows the visual language of a live or recording indicator for a page where nothing is live.
• Why: the dot is an attention grab with nothing behind it: a glow plus an endless pulse is a double bid for the eye over a fact that does not exist. It reads as AI because generated pages reach for system-status vocabulary as decoration, and the same dot lands in the same place on every one of them.
• Fix: a dot must mark a real state (active, live, recording, warning). If it does, keep one dot, drop the glow, and drop the endless pulse (R-19). If it marks nothing, remove it: a heading needs no indicator to be a heading (R-31).