Frontend Design

This skill provides the shared design and implementation foundation for frontend work. Implement real working code with strong aesthetic judgment, accessibility, responsiveness, and attention to project constraints.

Skill Composition

Apply skills in this order of precedence:

1. User requirements
2. Existing brand, functionality, accessibility, and project conventions
3. redesign preservation and migration constraints, when applicable
4. This skill's shared implementation principles
5. taste marketing-specific heuristics, when applicable

Invoke taste when the visual design of a landing page, portfolio, editorial page, or other brand-heavy marketing surface is in scope. Invoke redesign when the request is to materially redesign an existing interface, not for small corrections inside it. Do not duplicate their specialist audits here.

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

Surface Mode

Classify the requested surface by what the user needs to accomplish. The mode controls how expressive or restrained the design should be.

• Persuade: The visitor decides and acts. Landing pages, campaigns, pricing, and conversion surfaces can use stronger narrative, imagery, and visual emphasis. Pair with taste.
• Operate: The user completes a task. Dashboards, settings, editors, admin tools, and authenticated product UI prioritize familiarity, scanability, consistency, and speed.
• Read: The user needs to understand information. Documentation, articles, guides, and help surfaces prioritize structure, typography, navigation, and comprehension. Apply taste only when brand expression is central.
• Experience: The interface presents work or creates an immersive journey. Portfolios, galleries, showcases, and interactive stories can let composition and motion play a larger role. Pair with taste.

Choose the mode from the individual surface, not the overall product. A product dashboard is Operate while its public landing page is Persuade. A local component inside an established surface inherits that surface's mode and design system.

Design Thinking

Before coding, understand the context and commit to a clear, mode-appropriate aesthetic direction:

• Purpose: What problem does this interface solve? Who uses it?
• Tone: Choose a distinct direction appropriate to the mode and audience: brutally minimal, maximalist chaos, luxury/refined, lo-fi/zine, dark/moody, soft/pastel, editorial/magazine, brutalist/raw, retro-futuristic, handcrafted/artisanal, organic/natural, art deco/geometric, playful/whimsical, industrial/utilitarian, or another grounded direction. The final design should feel cohesive, with every detail serving that direction.
• Constraints: Technical requirements, framework conventions, performance, accessibility, and existing design-system boundaries.
• Differentiation: Decide what should be memorable. In Operate mode, this may be clarity and precision rather than spectacle.

CRITICAL: Choose a clear conceptual direction and execute it consistently. Intentionality matters more than intensity.

Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:

• Production-grade, functional, and responsive
• Appropriate to the surface mode and usage context
• Cohesive with a clear aesthetic point of view
• Carefully refined in spacing, typography, states, and behavior

When modifying an existing product, preserve its design system, typography, interaction conventions, and component library unless redesign is requested. For new designs, choose an aesthetic appropriate to the audience and task. Usability and accessibility take precedence over novelty.

Operate Mode Discipline

For task-oriented product UI:

• Prefer established interaction patterns over novel controls. Familiarity is a feature when users are trying to complete work.
• Use one consistent component, icon, typography, and form-control vocabulary across the surface.
• Keep typography compact and legible. Display fonts and dramatic scale changes rarely belong in controls, labels, or dense data.
• Use color primarily for actions, selection, status, warnings, and hierarchy rather than decoration.
• Use motion to communicate feedback, state changes, loading, or spatial relationships. Avoid cinematic page-load sequences and decorative perpetual animation.
• Provide every applicable component state: default, hover, focus, active, selected, disabled, loading, empty, error, and permission-limited.
• Let users enter the task quickly. Decoration must not delay, obscure, or compete with the primary workflow.

Frontend Aesthetics Guidelines

Focus on:

• Typography: Typography carries the design's voice. Choose fonts with personality when the mode supports it. Skip Arial, Inter, Roboto, and system stacks as reflexive defaults, but keep them when they serve the product, performance constraints, established design system, or Operate mode. Display type may be expressive; body and control text must remain legible. Use size, weight, case, and spacing to establish hierarchy.
• Color & Theme: Commit to a cohesive palette appropriate to the surface. Lead with clear hierarchy and use CSS variables or existing tokens for consistency. Do not force a dramatic palette onto an established or task-oriented product.
• Motion: Add motion only when it communicates hierarchy, feedback, state, or narrative. Prefer CSS for simple effects and use an existing animation library when available. Respect prefers-reduced-motion; motion must not be required to understand or operate the interface.
• Spatial Composition: Match composition to the mode. Persuade and Experience may use asymmetry, overlap, dramatic scale, or full-bleed moments. Operate and Read should favor predictable structure and efficient scanning while avoiding unnecessary sameness.
• Backgrounds & Visual Details: Create atmosphere when the surface benefits from it. Use textures, layered transparency, shadows, patterns, or other effects only when they support the chosen direction and remain performant and accessible.

Do not add a font or animation dependency without first checking existing dependencies and project conventions.

Avoid context-free defaults such as reflexively choosing common fonts, purple gradients, predictable marketing layouts, or cookie-cutter components. A common choice is acceptable when it fits the product, brand, constraints, mode, or existing design system.

Build creatively on the user's intent, but do not confuse novelty with quality. Match implementation complexity to the aesthetic vision and use the least complexity needed to express it.

UI Resilience

Design and verify the interface against realistic conditions, not only ideal sample data:

• Test empty, minimal, typical, long, and large-volume content.
• Check long translations, RTL direction, CJK text, emoji, locale-specific dates and numbers, and text zoom where relevant.
• Prefer flexible layout and logical CSS properties. Avoid widths and directional assumptions that only work for short English text.
• Define loading, offline, timeout, validation, authentication, permission, rate-limit, and server-error behavior where the product can encounter them.
• Preserve user input after recoverable errors and prevent accidental duplicate submissions.
• Ensure large collections use pagination, incremental loading, virtualization, search, or filtering appropriate to their size.
• For custom gestures, handle pointer cancellation, lost capture, release outside the control, window blur, touch scrolling, and the next interaction after interruption.
• Validate untrusted input on the server. Client validation exists for feedback, not as the security boundary.

Test only conditions relevant to the changed surface. Do not add speculative infrastructure or unsupported behavior merely to satisfy a checklist.

Bounded Visual Verification

Scale verification to the size of the change:

• New surface or meaningful layout, state, or interaction change: run the full pass below.
• Narrow patch inside an established surface: inspect only the affected component at the widths where it could plausibly break. One pass; a confirmation pass is needed only if defects were found and fixed.
• Change with no rendered effect (e.g. logic inside a UI file): skip browser inspection entirely and rely on tests, linting, and type checks.

Full pass:

1. Inspect representative desktop and mobile widths together in one visual pass. Include other shipped device classes when relevant.
2. Combine observed defects into one correction batch rather than repeatedly tweaking one issue at a time.
3. Run one confirmation pass after corrections.
4. Stop polishing after the confirmation pass unless defects remain, required verification failed, or the user asks for another iteration.

Also run the project's relevant tests, linting, type checks, and build. Visual inspection complements behavioral verification; it does not replace it.