Web Design

This skill guides the creation of distinctive frontend interfaces. Implement real working code with exceptional attention to aesthetic details.

The user provides design requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.

Scope this to the ask. What follows assumes an interface designed from scratch. Trim it to the actual request — a single component inside an existing system inherits that system's type, palette, and spacing, and needs none of the page-level structure guidance. Sections that are narrower say so.

The user's request outranks the taste rules here. An explicit instruction, an existing brand, or an established design system overrides every aesthetic prohibition in this file, including the ones written as "never" — the purple gradient, pure #000, emoji icons, a centered hero above three cards, Inter. Comply, then name the tension once in the handoff. Arguing with the brief, or quietly delivering something other than what was asked for, is the worse failure.

It does not override the pass/fail gates in Verification — keyboard access, visible focus, contrast, a form that doesn't destroy what was typed, content that isn't fabricated. Those are correctness, not preference, and "make it cleaner" is not a request to remove them. Where an instruction genuinely can't be met without breaking one, say which one and offer the nearest version that holds.

Verification scales with the change, but never to zero. Every handoff runs the core checks in Verification; anything page-sized runs all of them. State plainly what you could not check.

Design Thinking

Before coding, understand the direction the user wants to take with the design and commit to it:

• Purpose: Who uses this interface and what problem does it solve? What is the context of the design?

• Kind: Does this page argue (marketing, editorial, campaign), transact (checkout, signup, booking), or operate (dashboard, admin, settings, internal tool)? The kind sets how much novelty is appropriate before anything else does. A page that argues has to be memorable or it has failed. A page that operates mostly has to disappear into the task, and "boring, correct, fast" is a legitimate and often superior answer there — most of the page-level structure guidance below is written for the first kind.

• Tone: Pick a style: minimalist, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, etc. Use these for inspiration but design one that is true to the user's direction. Tone covers the writing as much as the visuals — decide how the page is written in the same breath as how it looks: terse or expansive, plain or ornate, dry or warm, formal or direct. A page whose type is severe and whose copy is chatty has two directions and reads as neither.

• Constraints: Technical requirements (framework, performance, accessibility).

• Differentiation: What is the one thing someone will remember after leaving the page? Name it before you build, then give it disproportionate weight — the first screen, the largest type, the only place motion does real work, whatever it takes to make it the thing the page is about. A page where every section got equal effort has no answer to this question. On an argue-kind page, being correct but unmemorable is a failure, not a safe result.

• CRITICAL: Choose a clear conceptual direction that aligns with the user's vision and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity. Elegance comes from executing the direction well rather than from adding more, so match implementation complexity to what the interface actually requires, not to how elaborate the aesthetic sounds. When the direction calls for density, keep it organized chaos — visually busy but clearly structured. When it calls for restraint, restraint is the bold choice.

Familiar is not the same as generic. Generic means unchosen, not common. A convention is a usability asset — a checkout that behaves like a checkout, a table that sorts the way tables sort, navigation where the eye already expects it — and breaking one costs the user real effort, which the design has to be worth. So set a novelty budget: decide where this interface is unusual and where it stays ordinary, and spend the budget on the few places that carry the direction — the type, the composition, the way the core content is displayed, the voice. Deciding which parts are conventional is part of the design, not a failure to design them.

If the brief is thin, do not stall on questions. Pick a direction, state it in one line, and build. Ask the user to clarify — ideally with examples of what they like and dislike — only when two readings of the brief would produce materially different work.

Deriving the direction. Every notable choice should trace back to something specific about this project rather than to taste in general — but that test is easy to apply after the fact and useless for generating anything. Work forward from the subject instead, in one pass, and write the chain down so the handoff can state it:

1. Name the subject concretely. Not "a fintech site" but "software that reconciles freight invoices, used by brokers for eight hours a day."
2. Find what it derives from. Look first for a physical or documentary reference: what does this thing already look like in the world? A material, a document, a machine, an environment, an artifact of the trade. Freight brokerage has an obvious one, the paper bill of lading, with its carbon-copy pink and yellow, dot-matrix figures and dense ruled tables. Plenty of subjects have none, and forcing one is where this procedure fails — a reference that doesn't fit produces decoration with a backstory. So work down instead:
   • The verb. What the product does usually has a physical analogue even when the product doesn't. Rate limiting is a valve. Reconciliation is matching two columns. Scheduling across time zones is a timetable. Deleting an account is a lever with a guard over it.
   • The condition the user is in when they arrive. Every product has one, so this never comes back empty, and it drives density, contrast, motion tolerance and tone more directly than any visual reference does. Mid-incident at 2am. Eight hours a day, five days a week. Deciding whether to spend £14,000. Waiting, bored, on a phone.
   • The constraint that actually shapes the thing — latency, regulation, trust, scale, or the plain fact that nobody wants to be here. A tax product's real constraint is dread, and that is a design brief.
   • Any existing brand asset, which outranks everything above it whenever one exists.
3. Read the specifics off the reference — the writing as well as the look. The carbons give the neutrals: a yellowed paper white, a carbon-smudge near-black. The pink copy gives an accent that is already the trade's own signal color. The ruled tables say hairline rules, not cards. The dot-matrix figures say tabular numerals and a mono reserved for quantities rather than used as decoration. The reference also sets how the page is written: a bill of lading is terse, declarative and numeric — it states quantities and consignees and never sells — so a page derived from one uses short factual sentences and no brochure language. Both come off the reference in the same pass.
4. Edit it against the job. Eight hours a day means desaturating that paper white further and spending the pink only on exceptions instead of on furniture. The reference proposes; the use case decides.

The brand name is not a subject. Deriving from the word is the weakest move on that list and normally produces a pun: it works only when the name happens to describe something the product genuinely does. A web studio called Click can derive from the mechanical click, because engaging and committing is what the work actually is; the same studio called Meridian would get navigational-instrument decoration bearing no relationship to building websites. If the name is all you have, you are missing step 1, not finishing step 2 — go back and describe the subject.

The result of step 4 is the direction, and every choice in it answers "why this?" with something other than "it looked good." Where the reference is silent — motion, density, radius — ask what the subject would do rather than what looks nice.

The literals in this file are shapes, not values. Every hex, ratio, grid declaration, and class string below illustrates the kind of decision being described. Reused verbatim across projects they produce a new house style — this file's — which fails the test above exactly as squarely as the defaults it replaces.

Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is both of the following. Neither one buys you the other, and neither is the safe answer when the work gets hard:

• Production-grade and functional. It works, in every state, for everyone, on every width. A beautiful page whose form eats your input is a broken page.
• Visually striking and memorable, with a clear aesthetic point-of-view. It is worth looking at and hard to forget. A page that is merely correct has failed at the half of the job people actually see — "at least it's accessible" is not a design.
• Written, not filled in. A site expresses as much through its words as through its design, and the copy is the only part that can make a specific claim. Placeholder prose under a considered layout is a half-finished page, not a finished one awaiting content.

Refined in every detail, which is where the two meet: the same care that catches a missing focus ring catches a headline set two points too small.

Output format: Match the project's existing stack — framework, styling approach, file layout. For standalone work with no existing project, prefer a single self-contained file. Confirm before introducing a new dependency the project doesn't already have.

Which libraries to reach for: take capability and correctness, never appearance. A library that supplies a capability you would otherwise have to build — timeline orchestration, SVG morphing, virtualized lists — leaves every design decision yours; nobody can tell which animation engine a page used. A library that supplies correctness — focus management, ARIA wiring, keyboard behavior — is better than what you would hand-roll, and this file's accessibility gates are hard to pass without one. Both are named where they come up below. A library that supplies appearance is the default cascade with a package name: component galleries indexed by effect rather than by function, where the pieces are called things like glass-card, beams-background, or gradient-button. Reading one to see how an effect is built is a good use of an afternoon. Installing one puts a look on the page that has no reason behind it, which is the thing this file exists to prevent.

If you are working on a page that already has an established design, consistency wins by default: reuse its type scale, palette, spacing rhythm, and component vocabulary. Be bold within that vocabulary — through composition, hierarchy, and motion — rather than against it. Introduce a new primitive only when the existing system genuinely cannot express the idea, and say so explicitly when you hand off.

Why interfaces read as AI-generated

Interfaces read as AI-generated because they are generic, not because they are ugly. Inter is a good typeface. rounded-2xl is a reasonable radius. Three feature cards is a functional layout. Nothing below is a mistake — each is the median choice, and the median is invisible. Generic is worse than ugly, because ugly is at least memorable.

What viewers actually register is sameness — "they all look the same" — and only then do they go looking for a reason. They rarely name the purple gradient consciously. This means fixing tells one at a time does not work. Every tell cataloged in this file can be removed and the result can still read as AI, because the underlying problem is the absence of a decision, not the presence of a specific color.

Four mechanisms produce every version of this, including versions not yet cataloged. Counter them at the source:

1. Distributional convergence. The model emits the median of its training data, and the median is by definition unmemorable. Counter: anchor every choice to something specific about this project, so the median is out of reach.
2. The default cascade. Framework defaults — Tailwind's indigo, shadcn's Inter and Lucide, the tutorial card — were over-represented in tutorials and became the baseline. Counter: replace defaults at the config level rather than overriding them per component, so the defaults are already yours.
3. Screenshot bias. Training data shows resting states; everything a user has to trigger is nearly invisible in it. Counter: interaction states and accessibility are part of the deliverable, not a polish pass.
4. The feedback loop. AI output is now training data, so each generation converges harder. The tells get stronger over time, and today's escape hatch becomes tomorrow's tell. Counter: none at the source — unlike the first three, this one cannot be escaped by finding a better answer, because any answer good enough to spread becomes the next median. It can only be survived by deriving again each time. This is why the catalog below has a shelf life and the second-order trap near the end is a permanent condition rather than a list of currently-tired styles.

The derivability test — the one that generalizes: every notable choice — typeface, palette, radius, layout, motion, section order — should trace back to a reason specific to this project: the subject matter, the audience, the actual content, an existing brand, a physical material, a real constraint. A choice that can't be justified is a default, whatever it looks like. If you can't explain why this typeface and not another one, you defaulted. (Deriving the direction, above, is the procedure that produces choices which pass it; everything below only detects choices that don't.)

Where to spend effort first

The strongest tells are all defaults: the color that wasn't picked, the component that wasn't restyled, the layout that wasn't questioned. In rough order of how loudly they register:

1. Framework/component defaults left untouched
2. "AI purple" — the indigo/violet-to-blue gradient
3. Centered hero + three-card row
4. Gradient text on the headline
5. Unprompted neon glow
6. Emoji used as icons

Two corrections to the popular version of this list. Bento grids, glassmorphism, and aurora/mesh backgrounds are weak signals, not fingerprints — they are legitimate techniques and rank far lower in practice than online discourse claims; don't avoid them reflexively. And loud, nameable tells are over-represented because they are easy to articulate. "The spacing is uniform so nothing has hierarchy" has no snappy name but matters more than most of the list. Spacing, hierarchy, and interaction states deserve more attention than their fame suggests.

Color

Never the indigo→violet→blue gradient — #6366F1 → #8B5CF6 → #3B82F6, Tailwind's indigo-500/violet-500/blue-500 — behind hero headlines, on primary CTAs, in background orbs, or on section accents. It is the loudest single tell. Purple there carries no semantic load: it isn't the brand color, it doesn't encode state, it doesn't relate to the product. It is decoration standing where a decision should be. It arrives because Tailwind uses indigo as the accent throughout its own docs, thousands of tutorials copied that verbatim, and models trained on the result predict the most likely token after bg-.

• Replace framework palettes, don't extend them. In a Tailwind project, clear the default color scale and define your own rather than adding alongside it, so indigo-600 is not reachable as a fallback. Express the result as CSS custom properties, so the palette stays one decision instead of fifty scattered literals.
• Never pure #FFFFFF or #000000, and no literal gray borders. Real design systems almost never use pure values — physical white is warm or cool, physical black is brown-black or blue-black. Pure values look like an unconfigured default because that is exactly what they are. Tint neutrals toward the accent hue or a deliberate temperature: #f6f5f1 warm off-white, #1a1814 warm near-black. This single change does more work than almost anything else here. Tint toward this project's reason, though, not toward those two values — warm off-white plus a serif display face plus generous whitespace is itself a house style, and a recognizable one; see the second-order trap below.
• Three hues carry the design; anything past that has to be doing a job. One dominant (60%), one neutral (30%), one sharp accent (~10%), with everything else a tint or shade of those three. The percentages are a rough target rather than something to measure: what matters is that one surface dominates and the accent goes to the single most important action on the page instead of being sprinkled. Color doing semantic or functional work sits outside that budget entirely — chart series, status and severity systems, category coding, wayfinding in a large product, and directions that are deliberately polychrome (maximalist, editorial, children's, games). What the cap prevents is decorative hue accumulation, not color.
• Color in small equal doses everywhere is the failure mode — a colored icon here, a colored badge there, a colored border strip, so nothing dominates. That's risk-averse averaging: no hierarchy, no attention direction. Real design commits.
• Derive the accent from something real: the product's domain, an existing logo, a physical material, a photograph.
• Color is never the only thing encoding a value. Not for chart series, not for status and severity, not for a field that failed validation, not for which item is selected. Roughly one man in twelve cannot separate the two hues you picked, and nobody at all can hear them. Pair every color signal with a second channel — a label, a shape, a position, an icon, a word. This applies wherever data is drawn, not only on dashboards.
• If a flat color "looks plain" and the instinct is to reach for a gradient, the flatness isn't the problem — the color choice is.

Typography

Avoid the default set: Inter, Roboto, Poppins, Space Grotesk, Geist, Arial, system-ui — especially at default line-height and default letter-spacing with font-bold on headings as the only hierarchy device. Inter in particular is shadcn/ui's default, so every project scaffolded from it starts there unless someone intervenes, and unchosen Inter signals that no typography decision was made at all.

• The count isn't the decision; choosing is. Two typefaces chosen for tone is the common answer — a display face with character for headings, a workhorse for body — and one face deployed deliberately across a full range of weight, size, and tracking is equally a decision, frequently the better one for applications, dashboards, technical products, and anything multilingual, where glyph coverage and legibility at 13px outrank personality. Inter, Roboto, and system-ui are widely used partly because they are genuinely excellent at UI sizes. What reads as absent is an unconsidered face, not a single one.
• Build hierarchy from a scale, not from bold alone. Pick one mathematical ratio (×1.25 or ×1.333), derive sizes from it, and use weight and spacing as the other two levers.
• Body text ≥16px, measure capped around 60–75 characters.
• Touch the details defaults never touch: negative tracking on large display text, tightened leading on headings, deliberate optical alignment.
• If a project has real reason to use one of the default faces, earn it: an unusual weight, tightened tracking, a distinctive scale.
• Where the project can load a font, choose a real one — a local stack is the fallback, not the default. Typeface does more for a page's character than any other single decision, and when the build can fetch a file the entire catalog is available; assembling a stack out of whatever happens to be installed is a constraint being obeyed, and obeying it when it doesn't apply leaves most of the available character on the table. Decide how it arrives before committing to it, because a webfont that fails to load falls back to a system face — exactly the generic look this file exists to avoid — and it fails silently. Self-host or use a font CDN, always with font-display: swap and a real fallback stack behind it rather than a bare sans-serif, and subset it so the payload is tens of KB rather than hundreds.
• Only where external requests are actually blocked — Claude artifacts, most embedded previews, strict CSP — does that stop working, and there a Google Fonts <link> does nothing at all rather than failing loudly. Either embed a subsetted face as a base64 data: URI, or build the type system from locally available faces and take distinctiveness from scale, weight, tracking, and case instead. Characterful local stacks beat Inter — "Iowan Old Style", "Palatino Linotype", Palatino, Georgia, serif or Futura, "Trebuchet MS", Optima, sans-serif — and always chain to a generic family, since the first choice is platform-dependent.

Skip the decorative tics. A cluster of small moves that were fresh once and are now reflexes:

• One serif-italic word dropped into an otherwise sans headline ("Build beautiful things") — the most reliable of the three
• All-caps letterspaced section labels above every heading. Count this one rather than judging it — each label is defensible alone and the tell exists only in aggregate, which is why it survives every taste review. Roughly one per three sections is the ceiling, with any hero label counting as the first. Over budget, delete the label instead of rewording it: a section's position on the page already says what it is
• Monospace used decoratively for eyebrow text and badges

Each is a recognizable "add sophistication" gesture with no relationship to the content. Use them only when the meaning justifies the emphasis. Test: if the italic word could be swapped for any other word in the sentence without loss, delete the italic.

Layout & page structure

Avoid the centered hero + three cards — the single most stereotyped structure on the web:

        [ small pill badge with sparkle/emoji ]
             Big Centered Headline Here
      One supporting sentence, also centered.
        [ Primary CTA ]  [ Secondary CTA ]
    - - - - - - - - - - - - - - - - - - - - -
   ┌─────────┐   ┌─────────┐   ┌─────────┐
   │  icon   │   │  icon   │   │  icon   │
   │  Title  │   │  Title  │   │  Title  │
   │  desc   │   │  desc   │   │  desc   │
   └─────────┘   └─────────┘   └─────────┘

This is the layout Tailwind tutorials used to demonstrate a grid — pedagogical scaffolding absorbed as a design pattern. The pill badge above the H1 is its most recent addition and now travels with it almost universally. Perfect symmetry is the absence of editorial judgment: real layouts have a dominant element and subordinate ones, not three equal ones. Three is suspicious in itself, since real products rarely have exactly three equally important features — three usually means the grid chose the count, not the content.

• Decide the viewing order first — what the viewer sees first, second, and third — then build the hierarchy to enforce it. Asymmetry, overlap, diagonal flow, grid-breaking elements, generous negative space, and controlled density are the means to that end; deployed without an order to express, they are decoration with extra steps.
• Break symmetry structurally, e.g. grid-template-columns: minmax(2rem, 1fr) minmax(0, 38rem) minmax(0, 1fr); with content in column 2 and art bleeding off the right edge via grid-column: 2 / -1.
• Let counts follow content — 2, 4, 5, or one hero feature plus three minor ones. Vary card weight so one is visually dominant. This governs every repeating set on the page, not only cards: numbered steps, pricing tiers, nav items, benefit bullets, footer columns. Three is the count that arrives by rhythm rather than by content, and a three-step "how it works" is the same failure as three feature cards wearing a list.
• Left-align long-form text. Centered text is for short statements only.

Don't ship the stock skeleton in stock order:

Hero → feature cards → logo cloud ("Trusted by") → how-it-works (numbered 1·2·3) → stats banner → testimonials → pricing tiers (3, middle one highlighted "Most Popular") → FAQ accordion → CTA band → footer

The sections aren't wrong — most are legitimate. Arriving in the same order with the same weight every time is. That's a template being filled, not an argument being made. Decide what this specific page must prove and order sections by that argument, cut anything that can't be filled with real content, and vary treatment down the page — alternate density, background, alignment, rhythm — so the page has a shape rather than a stack.

Dashboards and data-dense UI

Everything above assumes a page that argues. A dashboard reports, and some of it inverts — density is the goal rather than a compromise, and the whitespace that gives a landing page room makes an admin tool feel empty and slow to scan. Hierarchy still comes from spacing, just at a smaller amplitude. The stock skeleton has its own recognizable form:

left sidebar → top bar with search and avatar → row of four KPI stat cards → one wide line chart → one table

• Not every number needs a card. Four bordered, shadowed stat tiles in a row is the dashboard's version of three feature cards. Metrics that are read together belong on one surface, divided by rule lines or spacing — promote the one or two numbers the user opened the page for, and let the rest be a compact list.
• A number without a comparison is decoration. "1,247" tells nobody anything on its own — against what? Give every headline metric a baseline: the previous period, a target, or the same metric elsewhere. A +12% delta with no period attached is furniture in the same sense the floating social-proof badge is, and where down is the good direction, say so rather than leaving it to the arrow.
• The table is the product, not a component sitting beneath it. Right-align numerals in tabular figures so digits stack, left-align text, and give the identifying column more weight than the rest. Sorting, filtering, and pagination are functionality to build, not chrome to draw. Skip zebra striping by default — it treats a row-tracking problem that adequate row height and a row hover state solve better.
• Design against realistic data, not tidy data. Invented rows come out conveniently uniform — eight of them, names that fit their column, no nulls, every number the same digit count — and a layout that has only ever met tidy data breaks on contact with real data. Real data has a 60-character company name, a null in the middle column, one row reading 1 and the next 4,182,993, and forty thousand rows behind the first page. Populate with the longest, emptiest, and largest values the schema permits, and decide what truncation does — ellipsis, wrap, or tooltip — rather than discovering it later.
• Charts get the same palette discipline as everything else. Eight bright categorical hues is the charting-library default and looks like it. Use one accent with tints for series in the same family, and reserve a second hue for genuine contrast.
• A real zero and a broken pipeline look the same. The empty-state rules under Behavior & interaction apply here with the stakes raised: nobody merely reads a dashboard, they make a call on it, so an unlabeled empty chart is a decision taken on data that may not exist. Distinguish the two every time.

Spacing

Uniform spacing is a hierarchy failure that hides in plain sight. Identical padding on every element (24px is the common value), identical gaps between every section, no density variation. Whitespace is a hierarchy tool; uniform whitespace means hierarchy was never expressed, and the page reads flat even when every individual element is fine.

Use an 8pt grid (4 as a half-step) but vary within it: tight grouping for related items, generous separation between sections.

The squint test: shrink the page to a thumbnail. Structure should still be visible. If it's an even gray field, the spacing is doing no work.

Components & surfaces

Restyle the primitives before building anything. Change the radius scale, the shadow definition, and the padding baseline in the config itself. Overriding at the component level leaves stock values reachable, and they resurface.

Restyle the appearance; do not hand-roll the behavior. A combobox, a menu, a tab set, a date picker and a dialog are each a week of edge cases wearing a simple shape: type-ahead, roving focus, aria-activedescendant, the arrow keys, the escape hatch, what happens on mobile. Hand-written versions of them are where the keyboard rules in Verification actually break, and they break invisibly, because everything looks right. Headless libraries solve exactly this and impose no appearance — <dialog> for the case it covers, then Radix Primitives in React, Ark UI where the project isn't React, or React Aria when the accessibility bar is the point and you want hooks-level control. They ship behavior with no styles at all, so the entire visual argument stays yours and you are only spared the part that was never a design decision.

• Avoid stock card values — rounded-2xl shadow-lg p-6 untouched is the most-cited tell of all. (Worth getting right: that exact trio is the Tailwind tutorial and marketing-page idiom rather than shadcn's actual Card, which uses a tighter radius and a hairline ring in place of the shadow. Two separate default sources feed the same tell and models emit both. Either way they are stock values, trivially recognizable to anyone who has read the docs.)
• Radius is a scale, not a setting. rounded-2xl/rounded-3xl on cards, buttons, inputs, images, badges, and avatars at one uniform value (commonly 16px) flattens hierarchy — a radius that says "soft, friendly" on a card says nothing when it's also on the input, the image, and the tooltip. Build steps tied to meaning (e.g. 2px inputs / 6px cards / 999px pills), or try removing radius entirely: sharp corners are an instant differentiator precisely because soft is the default. Match the temperament — brutalist and editorial want sharp, consumer and playful want soft.
• Escalate separation, stop at the first step that works — starting with whether the thing needs a container at all. Boxing is the reflex default: content gets wrapped because a wrapper was available, not because anything needed dividing, and a page of nested panels reads as assembled rather than composed. Then: (1) whitespace — usually sufficient; (2) a background shift of 3–5% against the page; (3) soft elevation; (4) a border. Most surfaces need step 1 or 2. Every card getting a 1px gray border and a soft shadow is separation solved with the most literal tool available; it produces visual noise and a "dashboard component gallery" feel. Same for the colored 3–4px left-border strip and cards nested inside cards.
• No floating social-proof badges — small blurred, glowing pills near the hero at jaunty angles with a drop shadow ("★★★★★ 4.9 from 2,000+ teams", "Backed by…", "#1 Product of the Day"). They are decorative furniture that appears whether or not the proof exists, arranged ornamentally rather than informationally. Include social proof only when it's real, and present it as information.

Effects

• No gradient text on headlines. background-clip: text with a purple/blue gradient across the H1, sometimes with an added blur glow behind it. It appears unprompted, on every project, regardless of brand, and it usually hurts legibility and contrast. Solid color at the right weight and size is stronger. Use it only when specifically requested or genuinely part of an established brand system.
• No unprompted neon glow — outer glows on buttons, glowing card borders, cyan/violet neon on dark backgrounds, radial glow blooms behind hero content. Nobody asked for it; it's generic "make it look premium/futuristic" seasoning with no relationship to the subject matter. Start from zero glow and add back only what serves a purpose, such as a focus state or one genuine emphasis.
• Glassmorphism and bento grids are fine when deliberate. They read as AI only when applied uniformly and without cause — frosted glass on everything including elements with nothing behind them to blur, or a bento grid whose cell sizes don't correspond to content importance. For a bento grid specifically, cell size must encode importance; if the sizes are arbitrary it's just a grid with extra steps.
• Texture is a decision like every other one here. Geometric patterns, layered transparency, decorative rules and borders, treated photography, and shadow used as a deliberate device rather than as default elevation all build atmosphere where the direction calls for it — and a flat surface is a perfectly good answer where it doesn't. Grain, noise, and gradient mesh belong on that list too, but they are also the second-order defaults described below, so reach for them because this particular design calls for them and not to add texture in general.
• Dark mode is a decision, not a reflex. Dark-by-default with no light mode, chosen without being asked, is the corpus's "sophisticated" default — and it frequently ships broken, with thin text failing contrast and colors picked for light backgrounds simply inverted. Ship dark when the context earns it (developer tools, media, night use), design it as its own system, and check contrast against the values you actually chose — the WCAG 2 ratio formula under-reports on dark backgrounds, so text that passes comfortably can still read as thin and glaring, and weight it up rather than down. A design that must render in a viewer-controlled theme, such as an artifact, is not a choice between the two at all — style it for both.

Icons & imagery

• Never emoji as icons. 🚀 ⚡ 🎯 ✨ 🔒 as feature-card icons, section markers, or bullet points. They're text tokens — free for a model to emit, no asset pipeline, no import — which is exactly why they show up. They render differently per platform, don't inherit brand color, can't be sized precisely, and read as informal in contexts that aren't. A rocket next to "Fast deployment" is the visual equivalent of a filler word. Use a real icon set styled to the system's stroke weight and color, or no icons at all — a well-set feature list often doesn't need them.
• Apply the swap test to every icon. If it could be exchanged for another without changing the meaning — a shield, a zap, and a gear that are interchangeable between features — it is decoration, not information. Cut it.
• Don't ship a default icon set at default settings. Lucide at default stroke and size, oversized and centered above card text, arrives with the shadcn scaffold rather than being chosen. Adjust stroke weight and size to fit the type it sits beside — an icon whose stroke is heavier than the text next to it reads as a sticker.
• Pick the set for a property, not for having heard of it. Sets differ in ways that matter once you look: Phosphor carries six weights from thin to filled, so icon weight can be matched to type weight rather than accepted; Material Symbols exposes weight, fill, grade and optical size as variable axes, making it the most tunable if its geometry suits the work; Radix Icons are drawn on a 15px grid for dense interfaces, where 24px sets look clumsy; Tabler and Iconoir cover breadth and a more distinctive line respectively. Any of them beats the scaffold default, because any of them was chosen. Drawing your own is a bigger job than it looks — consistent optical weight, alignment, and corner treatment across a set is most of what an icon designer does — so hand-draw only the one or two marks that are genuinely specific to this product, and take the rest from a set.
• Avoid the two default hero images: (a) diverse groups of people looking at laptops in impossibly well-lit offices, and (b) abstract 3D blobs, gradient orbs, and floating glass shapes in space. Both are content-free and occupy the position where a product screenshot, a diagram, or a real photograph belongs. Prefer evidence over filler: a screenshot of the real interface, a diagram of how the thing works, a photograph of the actual object. Where the product doesn't exist yet, isn't visual, or is genuinely an idea rather than a screen, a deliberately conceptual image is evidence of the idea and the abstract render is still filler — the distinction is whether it carries information about this specific thing. If there's nothing to show, show nothing; a strong typographic hero beats filler.
• Process any generated imagery. The crude giveaways (malformed hands, garbled background text) are largely fixed; the current tell is tonal — uncanny smoothness, a plastic sheen, consistent lighting with no source, the absence of any imperfection. If using it, treat it as a deliberate style choice: add grain, crop unconventionally, push the color, break the symmetry. Untreated model output is the tell.

Behavior & interaction

• Motion comes in three registers. Name which one you're in before writing it.
  • Informational — what changed, where it came from, what state something is in. A drawer sliding from the edge it belongs to, a row collapsing into the place it went, a value counting to its new number. Always earns its place; this is the register an operational interface should mostly stay in.
  • Expressive — the motion is the experience: parallax depth, scroll-driven scenes, typography that assembles, hover choreography, a transition that makes two pages feel like one surface. It carries no information and it is not decoration either. It is legitimate whenever the direction is expressive, and on an argue-kind page it is frequently the thing people remember. It has to be built rather than sprinkled — see below.
  • Reflex — the identical fade-up on every section, card, and heading at the same duration and easing, because sections are supposed to fade up. Carries nothing, delays content, and reads as a template.
• The deletion test sorts them. Take the animation out and look at what's left: informational motion leaves a gap in meaning, expressive motion leaves the page without the thing it was for, and reflex motion leaves no gap at all — so it stays deleted. If you can't say which register something is in, it's reflex.
• Everything non-essential goes inside @media (prefers-reduced-motion: reduce), cut to a near-instant fade or nothing. The page has to be complete and fully usable with motion off — never gate content behind a scroll reveal, since a reader who has motion disabled, a crawler, and anyone who lands mid-page all need the text to be simply present.
• Design every state a component actually has: rest, hover, focus, active, disabled, loading, empty, error. Applies to anything interactive or stateful, which is the part that gets skipped — not to a static heading, a decorative image, or a paragraph, none of which have most of these and none of which should be given them. Go through the

…(truncated)