frontend-design

This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.

Use this decision order before reaching for effects:

CRITICAL: Hierarchy beats decoration. Systems beat one-off tweaking. Restraint beats trend-chasing.

Design skills produce generic output without project context. You MUST have confirmed design context before doing any design work.

Required context — every design skill needs at minimum:

Individual skills may require additional context — check the skill's preparation section for specifics.

CRITICAL: You cannot infer this context by reading the codebase. Code tells you what was built, not who it's for or what it should feel like. Only the creator can provide this context.

This skill library is intentionally framework-agnostic and library-agnostic.

When implementation details matter, follow this precedence:

The full precedence order, framework-default matrix, problem shorthand, and caveats live in framework defaults. Use that reference whenever you need to decide styling, component libraries, form architecture, table architecture, or virtualization defaults.

When the project uses a specific frontend framework or meta-framework, consult framework official docs before making framework-specific implementation decisions.

For Next.js specifically, if the project includes bundled version-matched docs at , read the relevant local Next.js doc there before coding. Treat those bundled docs as the source of truth for the installed version instead of relying on stale memory.

When React-based fallback defaults are relevant, use component and block strategy to decide when to compose from primitives, when blocks are an appropriate accelerator, and how to avoid shipping generic library output unchanged. Use react shadcn accelerators when the request maps to a curated community component such as theme controls, consent, text motion, testimonial patterns, wheel pickers, or slide actions.

When the project does not have a mature component library and you need to build or refine primitives from scratch, use component anatomy for practical anatomy guidance on custom components such as buttons, cards, checkboxes, dropdowns, tabs, textareas, toasts, toggles, tooltips, accordions, avatars, badges, borders, breadcrumbs, iconography, lists, and submit actions.

The more focused component-pattern references in this folder — such as accordion, breadcrumb, carousel, slider, date input, date-time picker, navigation menu, feature comparison, configurator, and complex table guidance — follow the same default. They are primarily for custom primitives, headless compositions, or plain HTML / CSS / JavaScript implementations. If a mature component library already owns the primitive well, use those references mainly to decide whether the pattern fits, how it should be composed, what defaults and states it needs, and how it should behave responsively around the library component instead of rewriting strong upstream anatomy, semantics, or accessibility behavior.

Treat design direction as a deliberate constraint system, not a vague tone adjective.

Follow design directions when choosing or preserving a style.

That reference defines the approved website directions for this library, how to choose among them, where louder styles should stay selective, and which styles this library should not generate.

Use these rules by default:

Apply a little pessimism up front:

Use design process when the request is still fuzzy, when layout and flow decisions need to be clarified before polish, or when you need a cleaner progression from wireframe to styleguide to prototype. Use design principles when the team needs clearer shared defaults, stronger product values, or a more durable decision-making point of view that explains both what to do and what to avoid. Use ux strategy when the work needs clearer user-segment focus, priorities, high-value UX actions, feasibility framing, or risk-aware alignment with product and business goals before screen-level execution. Use audience-sensitive design when the audience itself changes the UX — for example when designing for Gen Z, children, parents, older adults, or any audience with distinct device habits, trust patterns, or accessibility needs.

CRITICAL: Choose a clear conceptual direction and execute it with precision. Intentionality beats intensity. Typography, spacing, hierarchy, and content structure should still work even if decorative effects are temporarily removed.

Then implement working code that is:

→ Consult typography reference for scales, pairing, loading strategies, and font-selection heuristics. Use text hierarchy and readability for line length, line-height, baseline alignment, label/value treatment, link emphasis, numeric alignment, and semantic vs visual hierarchy.

Choose fonts that are beautiful, unique, and interesting. Pair a distinctive display font with a refined body font.

DO: Use a constrained, hand-crafted type scale; use modular ratios as inspiration, not as a prison DO: Build hierarchy with weight, color, and spacing — not size alone DO: Align mixed font sizes by their baseline when they appear on the same line DO: Tighten headlines carefully and add letter-spacing to all-caps text when readability benefits DO: When a hero or display headline wraps to multiple lines, reduce the size before crushing the leading; keep enough line-height and block padding that ascenders and descenders never clip DON'T: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults DON'T: Use monospace typography as lazy shorthand for "technical/developer" vibes DON'T: Use -based type scales for nested UI — they drift off-system fast DON'T: Center long-form text; center works for short statements, not dense reading DON'T: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

→ Consult color reference for OKLCH, palettes, and dark mode. Use colorblindness UX when semantic states, charts, active states, or category colors must remain distinguishable under color-vision deficiencies. Use color ramp workflow when building or repairing ramps. Use semantic color when color is carrying status, alerts, or meaning. Use data visualization when presenting data through charts, graphs, or plots.

Commit to a cohesive palette. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.

DO: Start in grayscale, then layer color on top of an already-clear hierarchy DO: Use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes DO: Define shades up front — greys need a real scale, primary and accent colors need multiple usable stops DO: Tint your neutrals toward your brand hue—even a subtle hint creates subconscious cohesion DO: Prefer dark text on light tinted surfaces when you need accessible, lower-emphasis colored panels DON'T: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead DON'T: Blindly or your way into 35 nearly identical shades DON'T: Use pure black (#000) or pure white (#fff)—always tint; pure black/white never appears in nature DON'T: Use the AI color palette: cyan-on-dark, purple-to-blue gradients, neon accents on dark backgrounds DON'T: Use gradient text for "impact"—especially on metrics or headings; it's decorative rather than meaningful DON'T: Default to dark mode with glowing accents—it looks "cool" without requiring actual design decisions

→ Consult spatial reference for grids, rhythm, and container queries. Use spacing system and hierarchy checklist when composition or grouping is weak.

Create visual rhythm through varied spacing—not the same padding everywhere. Embrace asymmetry and unexpected compositions. Break the grid intentionally for emphasis.

DO: Start with more white space than feels necessary, then remove it until the design feels balanced DO: Create visual rhythm through varied spacing—tight groupings, generous separations DO: Use fluid spacing with clamp() that breathes on larger screens DO: Use asymmetry and unexpected compositions; break the grid intentionally for emphasis DO: Keep more space around groups than within them to avoid ambiguous spacing DO: Break long pages into clear logical blocks; equal-weight sections should usually keep consistent outer spacing and shared backgrounds should wrap the whole related block, not just a narrow heading strip DO: Give components the width they actually need; fixed widths are often better than fluid widths for sidebars, forms, and cards DON'T: Wrap everything in cards—not everything needs a container DON'T: Nest cards inside cards—visual noise, flatten the hierarchy DON'T: Use identical card grids—same-sized cards with icon + heading + text, repeated endlessly DON'T: Use the hero metric layout template—big number, small label, supporting stats, gradient accent DON'T: Center everything—left-aligned text with asymmetric layouts feels more designed DON'T: Stretch every section just because the viewport is wide DON'T: Use the same spacing everywhere—without rhythm, layouts feel monotonous

→ Consult elevation system for shadow levels, raised/inset logic, and depth mapping. Use surface separation when deciding between spacing, borders, shadows, overlap, and background shifts. Use finishing touches for tasteful default upgrades, accent borders, and decorative backgrounds. Use personality levers when the tone feels vague. Use ai slop detection when the design risks looking generic or trend-chasing.

DO: Use intentional, purposeful decorative elements that reinforce brand DO: Create a small elevation system; shadows should communicate z-depth, not exist as default garnish DO: Use background shifts, spacing, and subtle shadows before reaching for borders everywhere DO: Treat louder style treatments such as glass, soft UI, clay, brutalist accents, or 3D elements as selective tools unless the chosen direction genuinely supports broad use DON'T: Use glassmorphism everywhere—blur effects, glass cards, glow borders used decoratively rather than purposefully DON'T: Use rounded elements with thick colored border on one side—a lazy accent that almost never looks intentional DON'T: Use sparklines as decoration—tiny charts that look sophisticated but convey nothing meaningful DON'T: Use rounded rectangles with generic drop shadows—safe, forgettable, could be any AI output DON'T: Add realism or depth effects that don't clarify elevation or interaction DON'T: Mix multiple loud style families at once without a clear hierarchy of what is primary versus supporting DON'T: Use modals unless there's truly no better alternative—modals are lazy

→ Consult image treatment when working with photos, screenshots, icons, illustrations, user-uploaded media, overlays, and image readability. Use hero sections UX when above-the-fold visuals, homepage openings, or landing-page first impressions need stronger clarity, proof, performance discipline, or a decision about whether a hero image should exist at all. Use aspect ratio and card orientation when media proportions, crop rules, browse-vs-evaluate card layouts, or responsive card/media rhythm materially affect clarity and flow.

DO: Treat image contrast problems as image-treatment problems first, not typography failures DO: Keep screenshots large or focused enough to communicate something useful DO: Keep icons close to the scale they were designed for unless they were made to scale illustratively DO: Place hero copy in a visually quiet part of the image and keep it off faces, product details, or other meaningful focal points DO: Force user-uploaded media into controlled shapes and predictable containers DON'T: Scale screenshots down until they become eye tests DON'T: Blow tiny icons up into chunky placeholders for real illustration DON'T: Let user-uploaded images dictate layout shape or bleed into the background

→ Consult motion reference for timing, easing, and reduced motion.

Focus on high-impact moments: one well-orchestrated page load with staggered reveals creates more delight than scattered micro-interactions.

DO: Use motion to convey state changes—entrances, exits, feedback DO: Use exponential easing (ease-out-quart/quint/expo) for natural deceleration DO: For height animations, use grid-template-rows transitions instead of animating height directly DON'T: Animate layout properties (width, height, padding, margin)—use transform and opacity only DON'T: Use bounce or elastic easing—they feel dated and tacky; real objects decelerate smoothly

→ Consult interaction design for forms, focus, loading patterns, Jakob's Law, and Fitts's Law.

Use action hierarchy when deciding which controls should lead, recede, disappear, or escalate in destructive confirmations.

Use for zero-data surface design. Use for broader activation strategy, aha moments, tours, and first-run education. Use when frequent interactions feel sluggish or break flow. Use when permissions, destructive actions, automation, or admin power need stronger safeguards.

Make interactions feel fast. Use optimistic UI—update immediately, sync later.

DO: Use progressive disclosure—start simple, reveal sophistication through interaction (basic options first, advanced behind expandable sections; hover states that reveal secondary actions) DO: Use familiar patterns for familiar tasks—navigation, search, tabs, dropdowns, tables, filters, forms, pagination, and settings should behave the way strong products already taught users to expect DO: Use the least interruptive status pattern that still works—inline validation, quiet indicators, inboxes, summaries, and toasts should not all compete for the same urgency DO: Build on existing workflow knowledge before proposing a big-bang rewrite of a legacy system; hybrid coexistence and staged migration are often the more honest design problem DO: Design empty states that teach the interface, not just say "nothing here" DO: Make every interactive surface feel intentional and responsive DO: Design actions in a real hierarchy — one primary action, a few secondary actions, and quiet tertiary actions DO: Make common actions easy to hit — generous targets, whole-row labels where appropriate, and close placement to the content being acted on DO: Give users control over noisy systems with calm defaults, digest modes, mute paths, snooze options, or quiet hours when notification volume could become disruptive DON'T: Repeat the same information—redundant headers, intros that restate the heading DON'T: Invent custom interaction models for standard controls unless the gain is obvious and significant DON'T: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters DON'T: Treat every status update like a warning, toast, push notification, or growth prompt just because the system can send one DON'T: Assume replacing a legacy surface from scratch is automatically safer than documenting workflows, reducing seam pain, and migrating incrementally with users

→ Consult responsive reference for narrow-first strategy, fluid design, natural widths, column rebalancing, and container queries.

DO: Use container queries (@container) for component-level responsiveness DO: Adapt the interface for different contexts—don't just shrink it DON'T: Hide critical functionality in narrow layouts—adapt the interface, don't amputate it

→ Consult ux-writing reference for labels, errors, and empty states. Use interface honesty when wording, progress cues, consent, unsubscribe/cancel flows, or upgrade prompts risk sounding evasive, manipulative, or faux-friendly. Use error recovery when the problem is not just message wording, but how users discover, understand, and fix errors in context. Use marketing copywriting when the task involves headlines, landing pages, product positioning, onboarding promises, lifecycle messages, marketplace listings, or CTA strategy. Use social proof patterns when the copy depends on testimonial framing, case-study proof, certifications, or the placement of credibility signals near claims and CTAs. Use copy editing sweeps when improving existing copy through focused passes instead of rewriting blindly. Pair those with pricing and packaging and paywalls and upgrade flows when the copy needs to explain plans, billing, renewals, upgrades, or value without sliding into pressure tactics.

DO: Make every word earn its place DON'T: Repeat information users can already see

Use for zero-data surface design. Use for broader activation strategy, first-run learning, aha moments, tours, and adoption planning.

When tradeoffs appear, default to this order:

Do not sacrifice the top of the list just to improve the bottom.

The interface must not rely on confusion, obstruction, guilt, concealment, or misleading hierarchy to drive product-favoring outcomes.

DO:

DON'T:

Critical quality check: If you showed this interface to someone and said "AI made this," would they believe you immediately? If yes, that's the problem.

A distinctive interface should make someone ask "how was this made?" not "which AI made this?"

Review the DON'T guidelines above—they are the fingerprints of AI-generated work from 2024-2025.

Consult ai slop detection for the consolidated anti-pattern list.

Match implementation complexity to the aesthetic vision. Heavier styles such as glass, soft UI, clay, 3D, or other custom-surface treatments increase CSS complexity, state design work, accessibility risk, and performance tuning cost. Restrained directions still need precision, not less effort.

Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices across generations.

Remember these quality checks while implementing:

Remember: GPT is capable of extraordinary creative work. Don't hold back—show what can truly be created when thinking outside the box and committing fully to a distinctive vision.