Frontend design

Frontend Design

Scope gate — decide before you design

Check the request against both columns before doing any design work. This gate is the whole point of this skill: it decides where the design actually gets made, not just how it's described.

Signal	Light — design inline	Heavy — hand off to the browser
Surface	One component, one page section, a targeted visual fix	A new page, a new flow, a whole product surface
Anchor	An existing design system / token set to extend	No system to anchor to, or the brief asks to establish one
Brief clarity	User already named the look, or it follows an established pattern	Ambiguous or exploratory ("make it look better", "redesign the dashboard")
Iteration need	One good pass is enough; cheap to tweak inline afterward	User will want to compare directions, see it live, iterate visually

Any single "heavy" signal is usually enough to route heavy — visual exploration degrades badly in a terminal loop, and a wrong guess there costs more than the handoff.

Light path: design inline

Work this loop: ground it in the subject, apply the design principles below, cut the AI tells, explore a couple of concrete directions, then self-critique before you call it done.

Ground it in the subject

If the request doesn't pin down what's being designed, pin it yourself: name the concrete surface, its audience, and the one job it does — then state that choice rather than silently assuming it. Read the surrounding codebase first: existing components, tokens, and patterns are the anchor for a light change, not a blank page. A surgical change that ignores the system around it isn't surgical.

Design principles

• One clear focal point. Every surface earns one thing the eye lands on first — a heading, a key number, a primary action. Don't spread emphasis evenly; that reads as "no decision was made."
• Typography is a design decision, not a default. Pick a type scale and weight relationship on purpose; don't inherit whatever the last component used without checking it still fits.
• Structure should mean something. Dividers, numbering, and labels should encode a real property of the content (an actual sequence, an actual grouping) — not decorate an arbitrary list.
• Motion is optional, not default. Add it only where it clarifies state change (a loading state, a reveal, a hover affordance); unmotivated animation reads as noise, not polish.
• Match effort to ambition. A minimal direction needs precise spacing and restraint; a bolder direction needs the follow-through to execute it fully. Half of either looks unfinished.
• Copy is part of the design. Interface text is read by the person using it, not by the system that built it — name things by what the user controls, use active voice, and keep error/empty states specific about what happened and what to do next.

Cut the AI tells

A concrete anti-tell floor that subtracts the marks of generated design. These remove recognizable tells; they don't prescribe a house look (a fixed "anti-slop" style just trades one sameness for another). Apply them while building and judge by eye — they're defaults that yield to real content, accessibility, and the surface's purpose, not a blocking checklist.

• Real assets, not fakes. No <div>-built "fake screenshots" of product UI and no hand-rolled decorative SVG illustrations as a default; use real or generated imagery, or leave an explicit TODO placeholder.
• No invented telemetry or chrome. Drop fake version labels (BETA, v0.6), section-number eyebrows (00 / INDEX), scroll cues, and locale/weather strips unless they encode real state.
• Vary the section rhythm. Don't reuse one section layout family down the page, and don't stack more than two image-and-text split sections in a row — a page where every band is the same shape reads as generated.
• Hero discipline. One focal hero: aim for a headline of one or two lines and, where the surface has one, a primary CTA visible without scrolling; avoid a kitchen-sink stack of taglines, trust strips, and avatar rows above the fold. (Real content, localization, and accessibility win over the line count — don't truncate meaning or invent a CTA to hit it.)
• Grids fit their content. N items means N cells — reshape the grid rather than padding it with an empty tile.
• One coherent theme per surface. No light/dark flips mid-page — while still designing both light and dark where the surface is theme-aware.

Explore

Sketch 2–3 concrete variations of the specific decision at hand (not a whole redesign) — a component's layout, a palette choice, a copy treatment — before committing to one. State which you picked and why in one line; don't silently default to the first idea.

Self-critique

Before calling it done, check the result against the trap of templated defaults: would this exact choice be your answer to almost any similar brief, regardless of subject? If yes, revise the part that's generic. Then check the accessibility floor that never gets cut for speed: responsive down to mobile width, visible keyboard focus, and color contrast that holds up — these are cheap to get right the first time and expensive to retrofit.

Heavy path: hand off to Claude Design in the browser

Do not design a wide-sweeping or highly-detailed surface blind, inline, in a back-and-forth text loop — visual work like this is genuinely better iterated where it can be seen and steered live. If the claude-design skill is installed, use it for the best-in-class brief (Anthropic's official goal/layout/content/audience framework) and the option to drive Claude Design from Claude Code (/design, /design-sync); otherwise hand the brief below. Tell the user directly, then hand them a brief they can paste straight in:

This reads as a wide-sweeping / highly-detailed design rather than a surgical tweak — better iterated visually in Claude Design (claude.ai, in the browser) than designed blind here. Here's a paste-ready brief to carry the context over:

Fill in every field you can from what's already known (the codebase, the conversation, an existing design system); leave the rest as an explicit placeholder rather than inventing detail that wasn't given. Emit exactly this shape:

# Design brief: <feature>
**Goal / job-to-be-done:** …
**Users & context:** …
**Constraints:** (brand, platform, a11y, perf) …
**Screens / components:** …
**Existing patterns to match:** …
**References / inspiration:** …

Stop there on this path — don't also produce inline mockups or code for the same surface; that duplicates the work Claude Design is about to do and drifts out of sync with whatever the user actually lands on in the browser.