frontend-design

name	frontend-design
description	Create clear, production-grade frontend interfaces with high design quality. Use when building web components, pages, or applications that need polished, professional UI. Focuses on clarity, consistency, and functional beauty over flashiness.

Adapted from Impeccable by Paul Bakaus (Apache 2.0 license). Modified for dashboard/tool UI: emphasis shifted from bold creative expression to clarity, information density, scanability, and consistent design systems.

This skill guides creation of polished, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with careful attention to design details and intentional choices.

Design Direction

Establish a clear design direction before writing code:

• Purpose: What problem does this interface solve? Who uses it? What data matters most?
• Tone: Choose an appropriate aesthetic — refined minimal, utilitarian, editorial, industrial, soft neutral, etc. Match the tone to the tool's purpose. A trading dashboard and a documentation site need very different treatments.
• Constraints: Technical requirements (framework, performance, accessibility).
• Consistency: Define a design system early — tokens, patterns, component conventions. Reuse relentlessly. Every one-off choice is technical debt.

CRITICAL: Choose a clear direction and execute it with precision. The key is intentionality: every color, spacing value, and typographic choice should trace back to a deliberate decision, not a default.

Then implement working code that is:

• Production-grade and functional
• Visually clear and scannable
• Cohesive with a consistent design system
• Meticulously refined in every detail

Frontend Aesthetics Guidelines

Typography

→ Consult typography reference for scales, pairing, and loading strategies.

Choose fonts appropriate to the interface's purpose. For data-heavy tools, readability and numeric clarity matter more than personality.

DO: Use a modular type scale with fluid sizing (clamp) DO: Vary font weights and sizes to create clear visual hierarchy DO: Use font-variant-numeric: tabular-nums for data columns DON'T: Use overused fonts—Inter, Roboto, Arial, Open Sans, system defaults — unless they genuinely serve the purpose (system fonts are fine for tools) DON'T: Use monospace typography as lazy shorthand for "technical/developer" vibes DON'T: Put large icons with rounded corners above every heading—they rarely add value and make sites look templated

Color & Theme

→ Consult color reference for OKLCH, palettes, and dark mode.

Commit to a cohesive palette with clear semantic roles. In data-dense UIs, color discipline is even more critical — every color should mean something specific.

DO: Use modern CSS color functions (oklch, color-mix, light-dark) for perceptually uniform, maintainable palettes DO: Tint your neutrals toward your brand hue—even a subtle hint creates subconscious cohesion DO: Define semantic color tokens (positive, negative, warning, info, neutral) and enforce strict usage DON'T: Use gray text on colored backgrounds—it looks washed out; use a shade of the background color instead 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 DON'T: Reuse semantic colors (green/red) for unrelated meanings — green for "profit" AND "enabled" AND "fresh" creates confusion

Layout & Space

→ Consult spatial reference for grids, rhythm, and container queries.

Create visual rhythm through varied spacing. In dense UIs, consistent spacing systems are even more important — they prevent the "wall of data" effect.

DO: Create visual rhythm through varied spacing—tight groupings, generous separations DO: Use fluid spacing with clamp() that breathes on larger screens DO: Use a consistent spacing scale (4pt base: 4, 8, 12, 16, 24, 32, 48, 64) 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: Use the same spacing everywhere—without rhythm, layouts feel monotonous

Visual Details

DO: Use intentional, purposeful decorative elements that reinforce the interface's identity DO: Use subtle elevation differences to create depth hierarchy on dark themes 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: Use modals unless there's truly no better alternative—modals are lazy

Motion

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

In tool UIs, motion should be functional — communicating state changes and providing feedback, not creating spectacle.

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

Interaction

→ Consult interaction reference for forms, focus, and loading patterns.

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: Design empty states that teach the interface, not just say "nothing here" DO: Make every interactive surface feel intentional and responsive DON'T: Repeat the same information—redundant headers, intros that restate the heading DON'T: Make every button primary—use ghost buttons, text links, secondary styles; hierarchy matters

Responsive

→ Consult responsive reference for mobile-first, fluid design, 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 on mobile—adapt the interface, don't amputate it

UX Writing

→ Consult ux-writing reference for labels, errors, and empty states.

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

---

The AI Slop Test

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 well-designed interface should make someone ask "how was this made?" not "which AI made this?"

Common AI fingerprints to avoid — review the DON'T guidelines above. They are the telltale signs of AI-generated work from 2024-2025:

• Cyan-on-dark color schemes
• Purple-to-blue gradients
• Glassmorphism and glow effects everywhere
• Hero metric templates (big number, small label, gradient accent)
• Identical card grids
• Gradient text on headings
• Rounded rectangles with generic shadows

---

Implementation Principles

Match implementation complexity to the design's needs. Data-heavy tools need precise alignment, consistent token usage, and clear information hierarchy. Every CSS value should reference a token. Every color should have a semantic role.

Build design systems, not pages. Components should be consistent, composable, and token-driven so theming and iteration are cheap.