Frontend Design Guidelines

7 core rules for building polished, professional frontends.

When to Use

• Building React/Next.js/Tailwind UI
• Reviewing frontend code for design quality
• Need quick reference on design principles

Rule 1: Mobile-First Layouts

• Design for mobile first, then expand
• Use Tailwind responsive prefixes: sm:, md:, lg:
• Touch targets: minimum 44x44px
• Stack vertically on mobile, grid on desktop

Rule 2: Distinctive Typography

• Max 2 font families (1 heading, 1 body)
• Use Tailwind's type scale: text-sm → text-6xl
• Line height: 1.5 for body, 1.2 for headings
• Letter spacing: slightly tight for headings

Rule 3: Purposeful Color (70-20-10 Rule)

• 70% — Background/neutral (white, gray, dark)
• 20% — Secondary (cards, borders, subtle elements)
• 10% — Accent/CTA (buttons, links, highlights)
• Use CSS custom properties for theme consistency

Rule 4: Interaction Feedback

• Every clickable element needs hover/active states
• Loading states for async actions
• Success/error feedback (toast, inline, color change)
• Transitions: 150-300ms for UI elements

Rule 5: Accessibility

• Semantic HTML (<nav>, <main>, <article>)
• ARIA labels on interactive elements
• Keyboard navigation support
• Color contrast: 4.5:1 minimum (WCAG AA)
• Focus indicators visible

Rule 6: Performance Targets

• LCP (Largest Contentful Paint): < 2.5s
• CLS (Cumulative Layout Shift): < 0.1
• Use next/image for automatic optimization
• Lazy load below-fold content
• Prefetch critical routes

Rule 7: One Memorable Element

• Each page needs ONE distinctive visual element
• Could be: animation, illustration, gradient, unique layout
• Avoid generic bootstrap-looking pages
• Make it look intentional, not template-derived

Quick Tailwind Patterns

// Responsive card grid
<div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">

// Glass morphism card
<div className="backdrop-blur-md bg-white/10 rounded-xl border border-white/20">

// Gradient text
<h1 className="bg-gradient-to-r from-blue-600 to-purple-600 bg-clip-text text-transparent">

// Smooth hover
<button className="transition-all duration-200 hover:scale-105 hover:shadow-lg">

When NOT to Use

• Backend-only or CLI tooling — these rules are frontend-specific and irrelevant
• Rapid prototyping where the goal is to test logic, not polish UI
• Projects using a different stack (Vue, Svelte, plain CSS) — Tailwind-specific patterns won't apply directly
• When a strict design system already governs the project — don't override established tokens with ad-hoc Tailwind classes

Pitfalls

• 70-20-10 applied per component instead of per page — the ratio is a page-level balance; forcing it at component level creates incoherent local palettes
• Forgetting dark mode — hardcoded bg-white breaks dark mode; use bg-background or dark: variants from the start, not as a retrofit
• Smooth-hover scale on large elements — hover:scale-105 on a full-width card causes layout reflow and CLS spikes; use hover:shadow instead
• Accessibility as an afterthought — adding ARIA labels after build is error-prone; semantic HTML must be set at initial markup time
• One memorable element becomes three — scope creep on Rule 7 produces visual noise; commit to one and remove the others

Verification

• Run Lighthouse (Chrome DevTools) — LCP < 2.5s, CLS < 0.1, Accessibility score ≥ 90
• Tab through the entire page — every interactive element must receive visible focus and be activatable by keyboard
• Resize viewport from 320px to 1440px — no horizontal scroll, no overlapping elements at any breakpoint
• Check color contrast with the axe browser extension — all text passes WCAG AA (4.5:1)