Design Taste

Generic, not ugly, is the failure mode now. Left alone, a model produces the statistical median of the web: a sans set in Inter, an indigo gradient, a centered hero over three icon cards, rounded-2xl on everything, and a fade-up on every section. Told to avoid that, it drifts to the next median: cream, an italic serif, and a terracotta accent. This skill forces a decision before any code is written. You ground the design in its subject, commit to a direction with observable values, compare the plan against the default you would have produced anyway, then build and critique with screenshots. The outcome it protects is a UI that belongs to its subject: swap in a competitor's logo and it should no longer fit.

Before you start

If .agents/project-context.md exists (or .claude/project-context.md), read it first and treat it as ground truth for stack, platforms, scale, design system, and constraints. Only ask for what it does not cover. If it does not exist and the task is larger than a quick fix, suggest running the project-context skill — but never block on it.

Also look for DESIGN.md, token files, a Tailwind @theme block, or an existing component library. If one exists, the direction has already been chosen. Your job is to extend it, not to invent a new one.

Core principles

1. Decide before you draw. Write the direction plan before any markup. The median shows up wherever nothing was decided.
2. Derive choices from the subject, not the category. The subject's materials, vernacular, users, and use scene produce distinctive choices. "Fintech = blue" and "dev tool = dark + mono" are category defaults.
3. The brief's own words win. If the user names a look, even one from the slop list, build it well. Use your own freedom only on the axes the brief leaves open.
4. Spend boldness in one place. Pick one signature move and keep everything around it quiet. Before shipping, remove one accessory.
5. Structure encodes information. Numbers, eyebrows, borders, dividers, and mono labels appear only when they carry a real sequence, category, or data.
6. Real content, or clearly labeled placeholders. Never fabricate testimonials, logos, metrics, or reviews. Fake specifics are both a slop tell and a lie.
7. Verify with your eyes, in bounded rounds. Screenshot, critique, and fix in one batch. Stop after two rounds.

Workflow

• Read what exists: the context file, DESIGN.md, tokens, and current screens. If a system exists, skip to "Build" and follow it, using design-foundations for the details.
• State the Design Read in one line: Reading this as: <surface> for <audience> whose job is <job>; direction <X> because <subject reason>. Ask at most one question, and only when the read is genuinely ambiguous (for example an unknown brand for a public launch). Otherwise proceed and list your assumptions.
• Name the surface mode (table below) and write one use-scene sentence: who uses it, where, and in what light. That sentence decides light or dark. The category never does.
• Choose a direction (preset table below), a color strategy, and one signature move. You may blend two presets, but one must dominate.
• Write the token plan: 4–6 named colors (OKLCH + hex, each with a role), typefaces and their roles, scale ratio, radius set, density, motion budget, and a layout concept as ASCII wireframes with the alignment stated. Add 2–4 principles specific to this brief.
• Run the default check. In 3 lines, write what you would have produced for a similar prompt by reflex, then compare it with your plan. Revise every part that matches, and say what changed and why. Then scan references/slop-catalog.md.
• Build to the design-foundations floor with real content. For placeholders, use plausible values and tell the user which ones are placeholders.
• Self-critique with the protocol below. Fix everything in one batch, re-check once, then stop.
• Persist the direction in DESIGN.md (see design-systems) so the next session extends it instead of starting over.

Surface modes

Choose the mode per surface, not per product. A dev tool's landing page is Persuade; its settings page is Operate.

Visual directions (presets)

These are starting points with observable values. They are not moods. Full specs, signature moves, and what each looks like when done badly are in references/directions.md.

If the product already runs on an official system (GOV.UK Frontend, USWDS, Material, Fluent, Carbon, Polaris, Primer), use that system's package instead of imitating it.

Color strategy

Pick the strategy before any hex values.

The hue comes from product meaning. By 2026 the OKLCH band from about 250 to 320 (indigo to violet) is the AI default for accents, so pick it only when the brand already owns it. Color commits at page scale: fields that own regions, not accents sprinkled everywhere.

Choosing typefaces

1. Write 3–5 personality adjectives from the brief, plus one "never".
2. Pick a class for each role (display, body, optional mono) from the subject's world, never from a stereotype like "books want a serif".
3. Draft 3 candidates per role from different foundries or sources. Reject any that sits on the dated overused-defaults list in references/fonts.md, unless the brief or brand earns it.
4. Test the candidates with the real headline and a real paragraph at display and body sizes. Check legibility at 14px, the numerals, and the italic.
5. Use one family or two. If two, make them clearly distinct; two near-identical grotesks read as mud.
6. Record the choice and the reason in DESIGN.md. Across projects, rotate: every "alternative" list turns into the next monoculture.

Operate surfaces may use a system stack or a workhorse UI face on purpose. That counts as a choice when it is stated and the rest of the system carries the identity.

Signature move

Choose exactly one and name it in the plan:

• A type treatment: extreme scale contrast, variable-width display, or a set headline that works as the image.
• A color field: one drenched section, or a committed brand color that owns the page.
• A layout device: an asymmetric editorial grid, or an unequal bento where each cell holds a real product artefact.
• The subject's own artefact as the hero: a live demo, a real photo, a real data visualization, a code sample.
• One orchestrated motion moment, such as a page-load sequence or a scroll-told explanation of the mechanism.
• A material or texture grounded in the subject: grain, print registration, paper.

Everything else supports it quietly. If two elements compete for "the memorable thing", demote one.

The anti-slop test

For every visible decision ask: "Is this the most probable output for this category, or a choice made for this brief?" Then run two more tests:

• Swap test: replace the logo with a competitor's. If the page still fits, it has no point of view.
• Memory test: what would a visitor describe an hour later? If the answer is "a clean SaaS page", revise the signature move.

The highest-frequency tells as of 2026-09 (the full dated catalog with detection hints is in references/slop-catalog.md):

• First-order: indigo/violet gradients and gradient text; Inter or Roboto as the display voice; centered hero → logo strip → 3 icon cards → testimonials → pricing as the whole page; identical cards with the same rgba(0,0,0,.1) shadow; a thick colored left border on cards; emoji as icons; glow blobs and decorative glass; a fade-up on every section.
• Second-order (what models do after hearing "no purple, no Inter"): cream background + high-contrast serif + terracotta accent; near-black + a single acid-green or vermilion accent; broadsheet hairlines with zero radius everywhere; Geist, Space Grotesk, or Instrument Serif by reflex; a tracked all-caps eyebrow above every heading; A · B · C meta strings; → on every link; mono small labels as costume; one italic or colored word in the headline; the big-number-plus-gradient "hero metric".

Each of these is legitimate when the brief earns it. The tell is reaching for it when the axis was free.

Redesigning an existing UI

First decide the mode. Refine keeps the current look and improves it. Overhaul replaces it. Never split the difference by polishing a look you are about to discard. Audit before you touch anything: brand tokens, information architecture, content, patterns to keep, accessibility wins, the SEO baseline, and analytics events. Never silently change URLs, nav labels, form field names or order, the logo, or legal copy. Apply the levers in order: typography → spacing → color → states → motion → hero recomposition → block replacement. The first four give most of the value at a fraction of the risk. The full procedure is in references/redesign.md.

Self-critique protocol

1. Capture desktop at 1440px and mobile at 390px, plus dark mode if it exists and a view at 200% zoom. Use Playwright or the browser tool if you have one. If you cannot render, review the code and report "Not checked visually".
2. Squint test: blur your eyes or the image. The primary element, the secondary elements, and the major groups should still read in order.
3. Slop scan against references/slop-catalog.md, then the swap and memory tests.
4. Restraint pass: remove one accessory, whether a decoration, a label, a border, or an animation, that the page does not need.
5. Floor check: contrast, focus-visible, states, reduced motion, and real copy (see design-foundations).
6. Fix everything in one batch. Confirm with at most one more round, then stop and report what remains.

Gotchas

• Imitating a real design system instead of using it. When the brief names Material, Carbon, Polaris, Primer, GOV.UK, USWDS, or Fluent, install the official package and follow its guidance; a look-alike built from scratch misses the behavior, accessibility work, and updates. Say so when you can only approximate a look (for example a brand's marketing site).
• Replacing one default with the next. Swapping Inter for Geist or Space Grotesk, or purple for cream + terracotta, is not a decision. Run the default check on the new plan too.
• Blanket bans instead of judgment. Nothing in the catalog is illegal. A serif is right for a law firm's editorial site, and near-black is right when it is tokenized and chosen for the use scene. Justify the choice in one line.
• Eyebrows, numbered markers, and mono labels as decoration. Use 01 / 02 / 03 only for a real sequence. Use an eyebrow only for a real category the heading does not already show. Never put one on every section.
• Dark mode picked by category. "It's a dev tool, so dark" is a reflex. Write the use-scene sentence.
• Premium by accumulation. Gradients, glass, glows, and more animation make a page louder, not better. Premium reads as considered states, tight type, and leaving things out.
• Fabricated proof. Invented "10,000+ teams", "99.9% uptime", testimonials from "Sarah Chen, CEO", and fake logo walls. Use labeled placeholders and list them for the user.
• Div-drawn fake product UI. A hand-built fake dashboard or terminal in the hero reads as slop. Use a real screenshot, a real component in demo mode, or a labeled image slot.
• Motion everywhere. Fade-up on every section and hover lift on every card is the default. Use one authored moment. Keyboard actions and actions repeated 100 times a day get no animation (see motion-design).
• Landing-page rules applied to product UI. Huge display type, 160px sections, and scroll choreography inside an app hurt repeat use. Check the surface mode.
• Imitating a famous brand. "Make it look like Linear/Stripe" should give you principles (restraint, one owned accent, crafted states), never their exact palette, logo-like marks, or copy.
• Persuasion by deception. Fake countdowns, invented scarcity ("3 people viewing"), confirmshaming opt-outs, and a visually buried "reject" button are dark patterns, not bold design. Never build them. Persuade by removing friction and uncertainty (see conversion-ux).
• Unbounded polishing. Endless screenshot loops burn time and drift the design. Two rounds, then ship and list the leftovers.

Output format

Before building, show the plan:

Design Read: <surface> for <audience>; job: <job>; mode: <Persuade|Operate|Read|Experience>
Use scene: <who, where, light> → <light|dark|both>
Direction: <preset (+ secondary)> — because <subject reason>
Signature move: <one thing>
Color (<strategy>): <Name> oklch(...) / #hex — role; … (4–6)
Type: display <face> · body <face> · mono <face or none> · ratio <r> · weights <n>
Shape/density/motion: radius <set> · spacing base <n> · motion <budget>
Layout: <one sentence> + ASCII wireframe(s), alignment <left|center|mixed>
Principles: 2–4 brief-specific rules
Default check: reflex version was <…>; changed <…> because <…>
Placeholders: <list of anything not real>

After building, end with Done / Verified (screenshots, checks) / Not checked / Placeholders to replace.

References

Related skills

• design-foundations — once the direction is set, for exact type scales, spacing, color ramps, contrast, and elevation.
• design-systems — to turn the plan into tokens and a DESIGN.md that persists.
• motion-design — when the signature move is motion, or to set the motion budget.
• conversion-ux — when the surface is a landing, pricing, signup, or checkout page.
• design-review — to score and audit the finished UI.
• design-resources — for fonts, icon sets, component libraries, and inspiration galleries.