Frontend Design Review

Frontend Design Review

Overview

This skill provides expert guidance for conducting thorough frontend design reviews, covering UI/UX design quality, design system consistency, accessibility compliance, and responsive design patterns. The skill helps identify design issues early in the development lifecycle, ensuring designs meet quality standards, accessibility requirements, and business objectives before implementation.

Core Capabilities

1. UI/UX Design Quality Review

• Visual design assessment (typography, color, spacing, layout, visual hierarchy)
• User experience evaluation (flows, interactions, navigation, usability)
• Design consistency verification across screens and journeys
• Brand alignment and visual identity validation
• Cognitive load analysis

2. Design System Validation

• Component library review (design, variants, states, reusability)
• Design tokens validation (colors, typography, spacing)
• Pattern library assessment for consistency
• Documentation quality evaluation
• Design system governance assessment

3. Accessibility Compliance

• WCAG 2.1 AA compliance verification
• Color contrast validation (4.5:1 text, 3:1 UI components)
• Keyboard navigation and focus management
• Screen reader support validation
• Accessible interaction patterns review

4. Responsive Design Review

• Breakpoint strategy evaluation
• Mobile-first approach assessment
• Touch target sizing verification (44x44px minimum)
• Content adaptation across viewports
• Performance considerations

5. Component Architecture Assessment

• Component hierarchy and composition patterns
• Reusability and flexibility evaluation
• State management review (default, hover, active, disabled, error, loading)
• Component variants and customization patterns
• Component documentation quality

Workflow

Phase 1: Pre-Review Preparation

1. Gather Design Assets

• Collect Figma/Sketch files, design specifications, mockups
• Obtain design system documentation and component library
• Review brand guidelines and style guides
• Gather user research findings and personas

2. Understand Context

• Review project requirements and business objectives
• Understand target users and use cases
• Identify key user journeys and critical flows
• Note technical constraints and platform requirements

3. Define Review Scope

• Identify screens/flows to review
• Determine review depth (high-level vs. detailed)
• Set priorities based on importance
• Establish timeline and deliverables

Phase 2: Conduct Design Review

Step 1: Visual Design Review

• Assess typography (font selection, type scale, line heights, consistency)
• Evaluate color system (palette, contrast, semantic usage, tokens)
• Review spacing and layout (grid system, whitespace, alignment)
• Check visual hierarchy (size, color, position, emphasis)
• Validate iconography (style, size, clarity, consistency)
• Assess imagery and media (quality, aspect ratios, optimization)

Step 2: Design System Compliance

• Verify component usage matches design system
• Check for design token usage (no hard-coded values)
• Identify deviations from established patterns
• Validate component variants and states
• Review custom components vs. system components

Step 3: Accessibility Audit

• Test color contrast ratios for all text and UI elements
• Verify keyboard navigation and tab order
• Check focus indicators visibility and clarity
• Validate ARIA labels and semantic structure
• Review alternative text for images
• Assess form label associations
• Test interactive element accessibility

Step 4: Responsive Design Evaluation

• Review breakpoint strategy (mobile, tablet, desktop)
• Check content adaptation at different viewports
• Verify touch target sizes on mobile
• Assess navigation patterns for mobile
• Review image responsiveness and optimization
• Validate typography scaling across devices

Step 5: Component Architecture Analysis

• Evaluate component organization and hierarchy
• Review component reusability and composition
• Check component state coverage
• Assess variant design and flexibility
• Validate component props and customization

Step 6: User Experience Assessment

• Analyze user flows and task completion paths
• Evaluate navigation structure and findability
• Check interaction patterns and feedback
• Assess error states and error handling
• Review empty states and loading states
• Validate form design and validation patterns

Phase 3: Document Findings

1. Categorize Issues by Severity

• Critical: Blocking issues, must fix before launch
• High: Significant usability/accessibility issues
• Medium: Issues with workarounds, should fix soon
• Low: Minor polish, nice-to-haves

2. Create Detailed Findings Report See design-review-report-template.md for comprehensive report structure

Include:

• Executive summary with key statistics
• Review scope documentation
• Findings by category with specific examples
• Severity-rated issue list
• Positive observations (what's working well)
• Actionable recommendations with priorities
• Action items with owners and timelines

3. Provide Visual Examples

• Screenshot issues with annotations
• Show before/after for recommendations
• Include contrast ratio measurements
• Document component state issues visually

Phase 4: Collaborate on Solutions

1. Prioritize Fixes

• Separate must-fix from nice-to-have
• Consider implementation effort
• Balance user impact with development cost

2. Create Action Plan

• Assign owners (design team vs. development team)
• Set realistic timelines
• Schedule follow-up review

3. Document Decisions

• Record accepted risks or trade-offs
• Note items deferred to future work
• Update design system if patterns change

Severity Level Guidelines

Critical (Blocking)

• Violates WCAG AA requirements (legal risk)
• Completely blocks core user tasks
• Causes data loss or security issues
• Severely damages brand or user trust

High Priority

• Significantly degrades user experience
• Impacts large number of users
• Creates major accessibility barriers
• Inconsistent with design system causing confusion

Medium Priority

• Negatively impacts experience but has workarounds
• Affects subset of users
• Minor accessibility issues (WCAG AAA)
• Design inconsistencies that are noticeable

Low Priority

• Polish and optimization items
• Edge case issues
• Minor visual refinements
• Nice-to-have enhancements

Accessibility Quick Reference

WCAG 2.1 AA Requirements:

• Color contrast: 4.5:1 for normal text, 3:1 for large text (18pt+ or 14pt+ bold)
• UI component contrast: 3:1 minimum
• Keyboard accessible: All functionality available via keyboard
• Focus visible: Clear focus indicators on interactive elements
• Text alternatives: All images have appropriate alt text
• Form labels: All inputs have associated labels
• Semantic HTML: Proper heading hierarchy and landmarks
• Touch targets: 44x44 CSS pixels minimum

Testing Tools:

• Color contrast: WebAIM Contrast Checker, Stark plugin
• Keyboard nav: Manual testing with Tab/Shift+Tab
• Screen reader: Test with VoiceOver (Mac), NVDA (Windows)

Design System Review Checklist

Component Usage:

• [ ] All components sourced from design system
• [ ] No one-off custom variations without justification
• [ ] Component variants used appropriately
• [ ] All component states designed (default, hover, active, disabled, error, loading)

Design Tokens:

• [ ] Colors use token references (not hex values)
• [ ] Typography uses token references (not hard-coded sizes)
• [ ] Spacing uses token references (8px grid system)
• [ ] Shadows and effects use token references

Patterns:

• [ ] Navigation patterns consistent with system
• [ ] Form patterns follow system conventions
• [ ] Modal/dialog patterns match system
• [ ] Empty states use system patterns
• [ ] Error handling follows system patterns

Reference Files

Load these references based on specific review needs:

• [best-practices-for-design-reviews.md](references/best-practices-for-design-reviews.md) - Review methodology, tools, and techniques for effective design reviews

• [common-design-issues-to-watch-for.md](references/common-design-issues-to-watch-for.md) - Frequently encountered design problems and red flags to identify during reviews

• [design-review-process.md](references/design-review-process.md) - Comprehensive step-by-step process with detailed checklists for each review phase

• [design-system-patterns.md](references/design-system-patterns.md) - Design system validation criteria, component patterns, and token usage guidelines

• [responsive-design-patterns.md](references/responsive-design-patterns.md) - Breakpoint strategies, mobile-first patterns, and responsive design best practices

• [accessibility-guidelines.md](references/accessibility-guidelines.md) - Detailed WCAG 2.1 AA compliance guidelines, testing procedures, and accessibility patterns

• [severity-levels.md](references/severity-levels.md) - Detailed severity level definitions and criteria for categorizing design issues

• [design-review-report-template.md](references/design-review-report-template.md) - Complete report template with all sections for documenting review findings

Example Review Flow

Scenario: Reviewing a new checkout flow design in Figma

1. Preparation (30 min)

• Review checkout requirements and success metrics
• Identify 5 screens in checkout flow
• Gather payment compliance requirements
• Review design system component library

2. Visual Design Review (45 min)

• Check typography consistency across all 5 screens
• Verify color contrast on CTA buttons (found 2 issues)
• Validate spacing follows 8px grid
• Review visual hierarchy on payment screen

3. Accessibility Audit (60 min)

• Test color contrast: 3 text elements fail (4.2:1, need 4.5:1)
• Check keyboard flow: Tab order jumps incorrectly on screen 3
• Verify ARIA labels: Payment input missing label association
• Review error states: Error messages lack semantic markup

4. Responsive Review (30 min)

• Check mobile breakpoint: Form inputs too small (38px height)
• Verify tablet layout: Good adaptation
• Test content reflow: Success

5. Design System Check (20 min)

• Found custom button variant not in system
• Spacing uses hard-coded values instead of tokens
• Form patterns match system conventions ✅

6. Document Findings (45 min)

• 3 Critical issues: Contrast failures, touch target sizes
• 5 High issues: Keyboard navigation, missing labels
• 4 Medium issues: Design token usage, custom components
• Create report using template with visual examples

7. Deliverables

• Design review report with 12 findings
• Annotated Figma comments on specific issues
• Prioritized action items with owners
• Schedule follow-up review in 1 week

Total Time: ~3.5 hours for comprehensive review

Tips for Effective Reviews

Be Specific: Don't say "improve contrast". Say "Body text on blue background has 3.8:1 contrast, needs 4.5:1. Darken text to #1a1a1a or lighten background."

Show Examples: Include screenshots with annotations. Show the issue and suggest visual fixes.

Prioritize: Clearly separate must-fix from nice-to-have. Focus on user impact.

Provide Context: Explain why an issue matters. "This contrast failure affects 8% of users with low vision."

Be Constructive: Acknowledge what works well. Balance criticism with recognition.

Collaborate: Review findings with designers before finalizing. Get their input on solutions.

Follow Up: Schedule re-review to verify fixes. Track issues to completion.

Accessibility Guidelines Reference

This document provides comprehensive guidance on evaluating web accessibility during frontend design reviews, covering WCAG 2.1 AA compliance, assistive technology support, and inclusive design principles.

Table of Contents

1. WCAG 2.1 Principles 2. Perceivable Guidelines 3. Operable Guidelines 4. Understandable Guidelines 5. Robust Guidelines 6. Common Accessibility Issues 7. Testing Accessibility 8. Assistive Technology Support

---

WCAG 2.1 Principles

The Web Content Accessibility Guidelines (WCAG) 2.1 are organized around four principles, often abbreviated as POUR:

1. Perceivable

Information and user interface components must be presentable to users in ways they can perceive.

2. Operable

User interface components and navigation must be operable.

3. Understandable

Information and the operation of the user interface must be understandable.

4. Robust

Content must be robust enough to be interpreted reliably by a wide variety of user agents, including assistive technologies.

Conformance Levels

• Level A: Minimum level of conformance
• Level AA: Recommended level (addresses most common barriers)
• Level AAA: Highest level (not required for all content)

Target for Most Projects: WCAG 2.1 AA compliance

---

Perceivable Guidelines

1.1 Text Alternatives (Level A)

Guideline: Provide text alternatives for non-text content.

1.1.1 Non-text Content (Level A)

Requirements:

• All images must have appropriate alt text
• Decorative images must have empty alt attribute (alt="")
• Functional images (buttons, links) must describe function
• Complex images (charts, diagrams) need detailed descriptions

Review Checklist:

• [ ] All informative images have descriptive alt text
• [ ] Alt text concise and meaningful (not "image of...")
• [ ] Decorative images marked with alt=""
• [ ] Icons paired with accessible labels
• [ ] Charts/graphs have text alternatives or data tables
• [ ] Logo alt text includes company name
• [ ] Image buttons describe action, not appearance

Examples:

✅ Good:

<img src="profile.jpg" alt="Sarah Johnson, CEO">
<img src="chart.png" alt="Sales increased 25% from Q1 to Q2">
<img src="decorative-line.png" alt="">
<button><img src="search-icon.svg" alt="Search"></button>

❌ Bad:

<img src="profile.jpg" alt="image">
<img src="chart.png" alt="chart">
<img src="decorative-line.png" alt="decorative line">
<button><img src="search-icon.svg" alt="magnifying glass icon"></button>

Common Patterns:

1.3 Adaptable (Level A)

Guideline: Create content that can be presented in different ways without losing information.

1.3.1 Info and Relationships (Level A)

Requirements:

• Information conveyed through visual layout must be available programmatically
• Use proper semantic HTML elements
• Form labels associated with inputs
• Headings properly nested (h1 → h2 → h3)

Review Checklist:

• [ ] Semantic HTML used (header, nav, main, article, section, aside, footer)
• [ ] Headings create logical document outline
• [ ] Lists use <ul>, <ol>, or <dl> elements
• [ ] Tables use <th> for headers with proper scope
• [ ] Form labels use <label> element with for attribute
• [ ] Related form fields grouped with <fieldset> and <legend>
• [ ] ARIA landmarks used when semantic HTML insufficient

1.3.2 Meaningful Sequence (Level A)

Requirements:

• Reading order makes sense when linearized
• Tab order follows logical sequence
• CSS positioning doesn't break content order

Review Checklist:

• [ ] DOM order matches visual order
• [ ] Tab order logical and predictable
• [ ] CSS absolute/fixed positioning doesn't break flow
• [ ] Two-column layouts maintain logical reading order
• [ ] Modals/dialogs inserted at logical point in DOM

1.3.3 Sensory Characteristics (Level A)

Requirements:

• Instructions don't rely solely on sensory characteristics
• Don't use only shape, size, location, or sound to convey information

Review Checklist:

• [ ] Instructions don't say "click the round button" (include text label)
• [ ] Don't say "see the sidebar on the right" (use heading or label)
• [ ] Color not the only indicator (use icons, text, patterns)
• [ ] Sound cues supplemented with visual alternatives

Examples:

❌ Bad:

• "Click the green button to continue"
• "Required fields are marked in red"
• "See the panel on the right for details"

✅ Good:

• "Click the green Continue button"
• "Required fields are marked with an asterisk (*) in red"
• "See the Related Articles section for details"

1.4 Distinguishable (Level AA)

Guideline: Make it easier for users to see and hear content.

1.4.3 Contrast (Minimum) (Level AA)

Requirements:

• Normal text: Minimum 4.5:1 contrast ratio
• Large text (18pt+ or 14pt+ bold): Minimum 3:1 contrast ratio
• UI components and graphical objects: Minimum 3:1 contrast ratio

Review Checklist:

• [ ] Body text meets 4.5:1 contrast ratio
• [ ] Heading text meets 4.5:1 or 3:1 (if large)
• [ ] Link text meets 4.5:1 contrast ratio
• [ ] Button text meets 4.5:1 contrast ratio
• [ ] Button borders meet 3:1 contrast ratio
• [ ] Form field borders meet 3:1 contrast ratio
• [ ] Icon colors meet 3:1 contrast ratio
• [ ] Focus indicators meet 3:1 contrast ratio
• [ ] Disabled state text may have lower contrast (not required to meet ratio)

Testing Tools:

• Chrome DevTools: Inspect element → Contrast ratio shown in color picker
• WebAIM Contrast Checker: <https://webaim.org/resources/contrastchecker/>
• Figma plugins: Stark, A11y - Color Contrast Checker

Common Issues:

• Light gray text on white background (#999 on #FFF = 2.8:1 ❌)
• White text on light blue background
• Placeholder text too light
• Disabled buttons with insufficient contrast

Color Contrast Quick Reference:

1.4.4 Resize Text (Level AA)

Requirements:

• Text can be resized up to 200% without loss of content or functionality
• Users can zoom browser without horizontal scrolling (at 1280px viewport)

Review Checklist:

• [ ] Text sizes use relative units (rem, em, %)
• [ ] Layouts don't break at 200% zoom
• [ ] No horizontal scrolling at 200% zoom (1280px viewport)
• [ ] Touch targets remain accessible when zoomed
• [ ] Fixed pixel sizes avoided for text

1.4.10 Reflow (Level AA, WCAG 2.1)

Requirements:

• Content reflows without horizontal scrolling at 320px width (mobile)
• Content reflows without vertical scrolling at 256px height (for horizontal content)

Review Checklist:

• [ ] No horizontal scrolling on mobile (320px width)
• [ ] Responsive design adapts to narrow viewports
• [ ] Data tables may scroll horizontally (exception allowed)
• [ ] Images scale appropriately

1.4.11 Non-text Contrast (Level AA, WCAG 2.1)

Requirements:

• UI components must have 3:1 contrast against adjacent colors
• Graphical objects must have 3:1 contrast

Review Checklist:

• [ ] Button borders meet 3:1 contrast
• [ ] Form input borders meet 3:1 contrast
• [ ] Focus indicators meet 3:1 contrast
• [ ] Icon colors meet 3:1 contrast against background
• [ ] Chart elements distinguishable with 3:1 contrast
• [ ] Active/selected states meet 3:1 contrast

1.4.12 Text Spacing (Level AA, WCAG 2.1)

Requirements:

• Content must be readable when user overrides spacing:
• Line height: At least 1.5x font size
• Paragraph spacing: At least 2x font size
• Letter spacing: At least 0.12x font size
• Word spacing: At least 0.16x font size

Review Checklist:

• [ ] Designs accommodate increased line height
• [ ] Text doesn't overlap with increased spacing
• [ ] Buttons/components don't break with increased spacing
• [ ] Content remains readable and functional

1.4.13 Content on Hover or Focus (Level AA, WCAG 2.1)

Requirements:

• Tooltips and popovers must be:
• Dismissible: Can be closed without moving pointer/focus
• Hoverable: User can move pointer over tooltip content
• Persistent: Remains visible until dismissed or no longer relevant

Review Checklist:

• [ ] Tooltips dismissible with Escape key
• [ ] User can move mouse over tooltip without it disappearing
• [ ] Tooltip doesn't disappear on accidental mouse movement
• [ ] Focus-triggered content remains until focus moves
• [ ] Tooltip timeout sufficient (at least 5 seconds)

---

Operable Guidelines

2.1 Keyboard Accessible (Level A)

Guideline: Make all functionality available from a keyboard.

2.1.1 Keyboard (Level A)

Requirements:

• All interactive elements operable via keyboard
• No keyboard traps
• Keyboard shortcuts documented

Review Checklist:

• [ ] All buttons keyboard accessible (Enter/Space activates)
• [ ] All links keyboard accessible (Enter activates)
• [ ] Form fields keyboard accessible (Tab navigates, arrows select)
• [ ] Dropdowns keyboard accessible (arrows navigate options)
• [ ] Modals keyboard accessible (Tab cycles through, Escape closes)
• [ ] Custom controls have keyboard support
• [ ] No keyboard traps (can always escape)

Common Keyboard Patterns:

2.1.2 No Keyboard Trap (Level A)

Requirements:

• Focus can always move away from any component
• If focus trapped (modal), Escape key provides exit

Review Checklist:

• [ ] Can Tab out of all components
• [ ] Modals provide Escape key to close
• [ ] Infinite scrolling allows keyboard exit
• [ ] Media players allow keyboard escape
• [ ] Custom widgets allow focus to move away

2.1.4 Character Key Shortcuts (Level A, WCAG 2.1)

Requirements:

• Single character shortcuts can be turned off, remapped, or only active when component focused

Review Checklist:

• [ ] Single-key shortcuts (like "s" for search) can be disabled
• [ ] Shortcuts require modifier key (Ctrl, Alt, Cmd)
• [ ] Shortcuts only active when component has focus
• [ ] Users can customize keyboard shortcuts

2.2 Enough Time (Level A)

Guideline: Provide users enough time to read and use content.

2.2.1 Timing Adjustable (Level A)

Requirements:

• Users can turn off, adjust, or extend time limits
• Exceptions: Real-time events, essential timing, 20+ hour time limits

Review Checklist:

• [ ] Session timeouts can be extended (warning before expiration)
• [ ] Auto-advancing carousels can be paused
• [ ] Timed quizzes allow time extension
• [ ] Warning provided before timeout (at least 20 seconds to respond)

2.2.2 Pause, Stop, Hide (Level A)

Requirements:

• Users can pause, stop, or hide moving, blinking, or auto-updating content

Review Checklist:

• [ ] Carousels have pause button
• [ ] Auto-playing videos have pause control
• [ ] Animations can be paused
• [ ] Auto-updating content can be paused
• [ ] No content blinks more than 3 times per second

2.3 Seizures and Physical Reactions (Level A)

Guideline: Do not design content that could cause seizures.

2.3.1 Three Flashes or Below Threshold (Level A)

Requirements:

• No content flashes more than 3 times per second
• Or flashes are below general flash and red flash thresholds

Review Checklist:

• [ ] Animations don't flash rapidly
• [ ] GIFs checked for flash rate
• [ ] Strobe effects avoided
• [ ] Transitions smooth, not flashy

2.4 Navigable (Level AA)

Guideline: Provide ways to help users navigate, find content, and determine where they are.

2.4.1 Bypass Blocks (Level A)

Requirements:

• Skip links to bypass repeated navigation
• Landmarks allow screen readers to jump to sections

Review Checklist:

• [ ] "Skip to main content" link at top of page
• [ ] Skip link visible on keyboard focus
• [ ] Landmarks defined (header, nav, main, aside, footer)
• [ ] Heading structure allows section navigation

2.4.2 Page Titled (Level A)

Requirements:

• Every page has descriptive, unique title

Review Checklist:

• [ ] Page title describes page content
• [ ] Page title unique across site
• [ ] Page title format consistent (e.g., "Page Name | Site Name")
• [ ] Page title changes on SPA navigation

2.4.3 Focus Order (Level A)

Requirements:

• Tab order follows logical, intuitive sequence

Review Checklist:

• [ ] Tab order matches visual order
• [ ] Tab order follows reading order (left-to-right, top-to-bottom)
• [ ] Hidden elements not in tab order
• [ ] Modal/dialog content in logical tab order
• [ ] Avoid positive tabindex values

2.4.4 Link Purpose (In Context) (Level A)

Requirements:

• Purpose of each link clear from link text or context

Review Checklist:

• [ ] Link text describes destination ("Read more about accessibility" not "Click here")
• [ ] Duplicate link texts lead to same destination
• [ ] Icon-only links have aria-label
• [ ] Links distinct from surrounding text (underline, color + another indicator)

Examples:

❌ Bad:

<a href="/article-1">Click here</a>
<a href="/article-2">Read more</a>
<a href="/docs"><img src="icon.svg" alt="icon"></a>

✅ Good:

<a href="/article-1">Read our accessibility guide</a>
<a href="/article-2">Read more about WCAG 2.1</a>
<a href="/docs" aria-label="Documentation"><img src="icon.svg" aria-hidden="true"></a>

2.4.5 Multiple Ways (Level AA)

Requirements:

• Multiple ways to locate pages (menu, search, sitemap)

Review Checklist:

• [ ] Primary navigation menu present
• [ ] Search functionality available
• [ ] Sitemap or breadcrumbs provided
• [ ] Related links on pages

2.4.6 Headings and Labels (Level AA)

Requirements:

• Headings and labels descriptive

Review Checklist:

• [ ] Headings describe topic or purpose
• [ ] Form labels clearly describe field purpose
• [ ] Button labels describe action
• [ ] Section labels clear

2.4.7 Focus Visible (Level AA)

Requirements:

• Keyboard focus indicator clearly visible

Review Checklist:

• [ ] Focus indicator visible on all interactive elements
• [ ] Focus indicator has sufficient contrast (3:1 against background)
• [ ] Focus indicator not removed with CSS (outline: none without alternative)
• [ ] Focus indicator visible against all backgrounds
• [ ] Focus indicator style consistent across site

Common Focus Indicator Styles:

• Outline (default browser style)
• Border change (thicker, different color)
• Background color change
• Glow/shadow effect
• Combination of above

Minimum Requirements:

• Visible change when element receives focus
• At least 3:1 contrast ratio against background
• Doesn't obscure the focused element

2.5 Input Modalities (Level AA, WCAG 2.1)

Guideline: Make it easier for users to operate functionality through various inputs.

2.5.1 Pointer Gestures (Level A)

Requirements:

• All multipoint or path-based gestures have single-pointer alternative

Review Checklist:

• [ ] Pinch-to-zoom has +/- buttons alternative
• [ ] Swipe gestures have button alternatives
• [ ] Drag-and-drop has keyboard alternative
• [ ] Two-finger gestures have single-pointer alternative

2.5.2 Pointer Cancellation (Level A)

Requirements:

• Actions triggered on up-event (not down-event)
• Allows user to abort action by moving away before release

Review Checklist:

• [ ] Click actions complete on mouseup (not mousedown)
• [ ] Touch actions complete on touchend (not touchstart)
• [ ] User can cancel by moving pointer away before release

2.5.3 Label in Name (Level A)

Requirements:

• Visible label text included in accessible name

Review Checklist:

• [ ] Button visible text matches aria-label (if aria-label used)
• [ ] Link visible text matches aria-label (if aria-label used)
• [ ] Voice control users can activate by saying visible label

2.5.4 Motion Actuation (Level A)

Requirements:

• Functions triggered by device motion (shake, tilt) have UI alternative

Review Checklist:

• [ ] Shake-to-undo has button alternative
• [ ] Tilt controls have button alternatives
• [ ] Motion can be disabled in settings

2.5.5 Target Size (Level AAA, but recommended)

Recommended (not AA):

• Touch targets at least 44x44 CSS pixels

Review Checklist:

• [ ] Buttons at least 44x44px
• [ ] Links have adequate clickable area
• [ ] Form controls at least 44px tall
• [ ] Icon buttons at least 44x44px
• [ ] Spacing between targets prevents misclicks

---

Understandable Guidelines

3.1 Readable (Level AA)

Guideline: Make text content readable and understandable.

3.1.1 Language of Page (Level A)

Requirements:

• Default language of page programmatically determined

Review Checklist:

• [ ] <html lang="en"> attribute set
• [ ] Correct language code used (en, es, fr, etc.)

3.1.2 Language of Parts (Level AA)

Requirements:

• Language changes indicated programmatically

Review Checklist:

• [ ] Foreign phrases marked with lang attribute
• [ ] Example: <span lang="fr">Bonjour</span>

3.2 Predictable (Level AA)

Guideline: Make web pages appear and operate in predictable ways.

3.2.1 On Focus (Level A)

Requirements:

• Focus doesn't trigger context change

Review Checklist:

• [ ] Focusing input doesn't submit form
• [ ] Focusing link doesn't navigate
• [ ] Focus doesn't open modals
• [ ] Focus doesn't change page content unexpectedly

3.2.2 On Input (Level A)

Requirements:

• Changing input doesn't automatically trigger context change

Review Checklist:

• [ ] Typing in search doesn't auto-submit (wait for Enter or button)
• [ ] Selecting radio button doesn't auto-submit form
• [ ] Checkbox change doesn't navigate away
• [ ] Dropdown selection doesn't change page (unless warned)

3.2.3 Consistent Navigation (Level AA)

Requirements:

• Navigation consistent across pages

Review Checklist:

• [ ] Navigation menu same location on all pages
• [ ] Navigation items same order across pages
• [ ] Breadcrumbs consistent across pages
• [ ] Footer links consistent

3.2.4 Consistent Identification (Level AA)

Requirements:

• Components with same functionality labeled consistently

Review Checklist:

• [ ] Submit buttons always labeled "Submit" (not "Submit" on one page, "Send" on another)
• [ ] Icons used consistently (same icon = same function)
• [ ] Error messages formatted consistently

3.3 Input Assistance (Level AA)

Guideline: Help users avoid and correct mistakes.

3.3.1 Error Identification (Level A)

Requirements:

• Input errors identified and described to user

Review Checklist:

• [ ] Required field errors clearly stated
• [ ] Invalid format errors explain expected format
• [ ] Errors announced to screen readers
• [ ] Error styling clear (not just color)

3.3.2 Labels or Instructions (Level A)

Requirements:

• Labels or instructions provided for user input

Review Checklist:

• [ ] All form fields have labels
• [ ] Required fields clearly marked
• [ ] Expected format explained (e.g., "MM/DD/YYYY")
• [ ] Helpful examples provided
• [ ] Complex inputs have instructions

3.3.3 Error Suggestion (Level AA)

Requirements:

• Suggestions provided for fixing input errors

Review Checklist:

• [ ] Error messages explain how to fix
• [ ] Suggestions specific and actionable
• [ ] Examples provided for correct format
• [ ] Alternative options suggested

Examples:

❌ Bad:

• "Invalid email"
• "Error in date field"

✅ Good:

• "Email address must include @ symbol. For example: <user@example.com>"
• "Date must be in MM/DD/YYYY format. For example: 12/31/2025"

3.3.4 Error Prevention (Legal, Financial, Data) (Level AA)

Requirements:

• Submissions reversible, checked, or confirmed for legal, financial, or data transactions

Review Checklist:

• [ ] Confirmation page before finalizing purchase
• [ ] Review step before submitting important data
• [ ] Ability to edit before final submission
• [ ] Confirmation checkbox for critical actions
• [ ] Delete actions have confirmation dialog

---

Robust Guidelines

4.1 Compatible (Level A)

Guideline: Maximize compatibility with current and future user agents, including assistive technologies.

4.1.1 Parsing (Level A, deprecated in WCAG 2.2)

Requirements:

• HTML validates (no duplicate IDs, proper nesting)

Review Checklist:

• [ ] No duplicate IDs
• [ ] Elements properly nested
• [ ] Closing tags present
• [ ] Attributes quoted properly

4.1.2 Name, Role, Value (Level A)

Requirements:

• UI components have accessible name, role, and state

Review Checklist:

• [ ] Custom controls have ARIA roles
• [ ] Interactive elements have accessible names
• [ ] State changes announced (checked, expanded, selected)
• [ ] Dynamic content updates announced

ARIA Roles for Custom Controls:

4.1.3 Status Messages (Level AA, WCAG 2.1)

Requirements:

• Status messages announced to screen readers without focus change

Review Checklist:

• [ ] Success messages use role="status" or aria-live="polite"
• [ ] Error messages use role="alert" or aria-live="assertive"
• [ ] Loading states announced
• [ ] Search results count announced
• [ ] Form submission feedback announced

ARIA Live Regions:

<!-- Polite announcement (waits for pause) -->
<div role="status" aria-live="polite">
  3 results found
</div>

<!-- Assertive announcement (immediate) -->
<div role="alert" aria-live="assertive">
  Error: Form submission failed
</div>

---

Common Accessibility Issues

1. Missing Alt Text

Impact: Screen reader users can't understand images Fix: Add descriptive alt text to all images

2. Low Color Contrast

Impact: Users with low vision can't read text Fix: Ensure 4.5:1 contrast for text, 3:1 for UI components

3. No Keyboard Access

Impact: Keyboard users can't interact with custom controls Fix: Make all interactive elements keyboard accessible

4. Missing Focus Indicators

Impact: Keyboard users can't see where focus is Fix: Ensure visible focus indicators on all interactive elements

5. No Form Labels

Impact: Screen reader users don't know field purpose Fix: Use <label> element for all form inputs

6. Poor Heading Structure

Impact: Screen reader users can't navigate by headings Fix: Use proper heading hierarchy (h1 → h2 → h3)

7. Non-descriptive Link Text

Impact: Screen reader users hear "click here" without context Fix: Use descriptive link text that explains destination

8. Auto-playing Media

Impact: Distracts users, especially those with cognitive disabilities Fix: Don't auto-play, or provide pause control

9. Tiny Touch Targets

Impact: Mobile users, especially those with motor disabilities, can't tap accurately Fix: Ensure 44x44px minimum touch target size

10. Inaccessible Modals

Impact: Keyboard users trapped, screen reader users confused Fix: Trap focus within modal, provide Escape key to close

---

Testing Accessibility

Automated Testing Tools

Browser Extensions:

• axe DevTools: Comprehensive automated testing
• WAVE: Visual feedback on accessibility issues
• Lighthouse: Built into Chrome DevTools

Limitations:

• Automated tools catch only ~30% of issues
• Manual testing required for full coverage

Manual Testing

Keyboard Testing:

1. Unplug mouse 2. Tab through entire page 3. Verify all interactive elements accessible 4. Check focus indicators visible 5. Ensure no keyboard traps

Screen Reader Testing:

• macOS: VoiceOver (Cmd+F5)
• Windows: NVDA (free) or JAWS
• Mobile: iOS VoiceOver, Android TalkBack

Screen Reader Test Checklist:

• [ ] All content announced
• [ ] Images have alt text
• [ ] Headings navigable
• [ ] Landmarks present
• [ ] Form labels associated
• [ ] Buttons/links clearly identified
• [ ] Dynamic content updates announced

Color Contrast Testing

Tools:

• WebAIM Contrast Checker
• Chrome DevTools color picker
• Figma plugins (Stark, A11y - Color Contrast Checker)

Process:

1. Check all text against background 2. Check all UI components against adjacent colors 3. Check focus indicators 4. Test in dark mode (if applicable)

Zoom Testing

Process:

1. Zoom browser to 200% 2. Verify no horizontal scrolling 3. Verify content remains readable 4. Verify interactive elements remain accessible

Mobile Accessibility Testing

Process:

1. Test on real devices (iOS, Android) 2. Enable screen reader (VoiceOver, TalkBack) 3. Verify touch target sizes (44x44px minimum) 4. Test landscape and portrait orientations 5. Test with assistive touch enabled

---

Assistive Technology Support

Screen Readers

Popular Screen Readers:

• NVDA (Windows, free)
• JAWS (Windows, commercial)
• VoiceOver (macOS, iOS, built-in)
• TalkBack (Android, built-in)
• Narrator (Windows, built-in)

Screen Reader Considerations:

• Semantic HTML crucial for proper announcement
• ARIA labels supplement visual labels
• Live regions announce dynamic content
• Focus management critical for SPAs

Voice Control

Voice Control Software:

• Dragon NaturallySpeaking
• iOS Voice Control
• Android Voice Access

Voice Control Considerations:

• Visible labels match accessible names
• Interactive elements labeled clearly
• Links and buttons distinguishable
• Form fields clearly labeled

Switch Control

Switch Control Users:

• Users with motor disabilities
• May use single switch, sip-and-puff, head pointer

Switch Control Considerations:

• All functionality keyboard accessible
• No time limits or can be extended
• Grouped actions accessible
• Large touch targets

Screen Magnification

Screen Magnifier Software:

• ZoomText (Windows)
• macOS Zoom
• Windows Magnifier

Screen Magnification Considerations:

• Content doesn't break when zoomed
• Focus indicators visible when magnified
• Important info not hidden off-screen
• Horizontal scrolling minimized

---

Accessibility Review Checklist Summary

Critical (Must Fix)

• [ ] Color Contrast: All text meets 4.5:1 (normal) or 3:1 (large), UI components meet 3:1
• [ ] Keyboard Access: All interactive elements keyboard accessible, no keyboard traps
• [ ] Focus Indicators: Visible focus indicators on all interactive elements (3:1 contrast)
• [ ] Alt Text: All images have appropriate alt text or empty alt for decorative
• [ ] Form Labels: All form inputs have associated labels
• [ ] Heading Structure: Proper heading hierarchy (h1 → h2 → h3)
• [ ] Touch Targets: Minimum 44x44px on mobile

High Priority (Should Fix)

• [ ] Link Text: Descriptive link text (not "click here")
• [ ] Error Messages: Specific, actionable error messages
• [ ] ARIA Labels: Custom controls have proper ARIA roles and labels
• [ ] Skip Links: Skip navigation link present
• [ ] Page Titles: Unique, descriptive page titles
• [ ] Language: HTML lang attribute set
• [ ] Live Regions: Dynamic content changes announced

Medium Priority (Recommended)

• [ ] Consistent Navigation: Navigation consistent across pages
• [ ] Landmarks: Semantic HTML landmarks (header, nav, main, footer)
• [ ] Button Labels: Clear, action-oriented button labels
• [ ] Text Spacing: Designs accommodate increased text spacing
• [ ] Reflow: No horizontal scrolling at 320px width
• [ ] Multiple Navigation: Multiple ways to find content (menu, search, breadcrumbs)

---

Resources

Official Guidelines

• WCAG 2.1: <https://www.w3.org/WAI/WCAG21/quickref/>
• WAI-ARIA Practices: <https://www.w3.org/WAI/ARIA/apg/>

Testing Tools

• axe DevTools: <https://www.deque.com/axe/devtools/>
• WAVE: <https://wave.webaim.org/>
• WebAIM Contrast Checker: <https://webaim.org/resources/contrastchecker/>

Learning Resources

• WebAIM: <https://webaim.org/>
• A11y Project: <https://www.a11yproject.com/>
• Inclusive Components: <https://inclusive-components.design/>

Best Practices for Design Reviews

1. Be Objective and Evidence-Based

• Base feedback on established principles (WCAG, usability heuristics, design system rules)
• Provide specific examples and screenshots
• Avoid subjective opinions without rationale
• Reference guidelines and standards

2. Be Constructive and Solution-Oriented

• Focus on problems and solutions, not personal preferences
• Provide specific, actionable recommendations
• Offer alternatives when criticizing designs
• Balance critique with recognition of strengths

3. Consider Context

• Understand business constraints and priorities
• Consider technical feasibility
• Respect timeline and resource limitations
• Align feedback with project goals

4. Prioritize User Impact

• Focus first on issues affecting real users
• Prioritize accessibility and usability over aesthetics
• Consider different user types and scenarios
• Think about edge cases and error states

5. Collaborate with Designers

• Involve designers in the review process
• Encourage discussion and questions
• Be open to designer perspectives
• Work together to find best solutions

6. Document Thoroughly

• Capture all findings with clear descriptions
• Include visual examples for clarity
• Provide specific locations in design files
• Track recommendations and their status

7. Follow Up

• Schedule review of design iterations
• Verify critical issues resolved
• Track progress on recommendations
• Celebrate improvements

Common Design Issues to Watch For

Visual Design

• Inconsistent typography scales
• Insufficient color contrast
• Spacing not following system
• Poor visual hierarchy
• Inconsistent icon styles
• Misaligned elements
• Inconsistent border radius
• Overuse of colors or styles

User Experience

• Unclear navigation structure
• Missing feedback for actions
• Confusing user flows
• Too many clicks to complete tasks
• Missing error states
• No loading indicators
• Unclear form validation
• Poor error messages

Design System

• Duplicating existing components
• Not using design tokens
• Inventing one-off styles
• Ignoring pattern library
• Poor component documentation
• Inconsistent naming conventions

Accessibility

• Insufficient color contrast
• Missing alt text on images
• No keyboard navigation support
• Tiny touch targets (< 44px)
• Color-only information conveyance
• Missing form labels
• Poor focus indicators
• Inaccessible custom controls

Responsive Design

• Fixed widths breaking layouts
• Horizontal scrolling on mobile
• Tiny text requiring zoom
• Touch targets too small
• Poor breakpoint choices
• Desktop-only features on mobile
• Poor mobile navigation

Component Architecture

• Overly complex components
• Too many variants
• Missing common states
• Poor prop design
• Unclear component boundaries
• Tight coupling between components

Design Review Process

Phase 1: Pre-Review Preparation

Activities:

1. Gather Design Assets

• Collect Figma/Sketch files, design specifications, and mockups
• Obtain design system documentation and component library
• Review brand guidelines and style guides
• Gather user research findings and personas

2. Understand Context

• Review project requirements and business objectives
• Understand target users and use cases
• Identify key user journeys and critical flows
• Note technical constraints and platform requirements

3. Define Review Scope

• Identify screens/flows to review
• Determine review depth (high-level vs. detailed)
• Set review priorities based on importance
• Establish timeline and deliverables

Deliverables:

• Review scope document
• Asset inventory
• Context summary

Phase 2: Visual Design Review

Review Areas:

Typography Assessment:

• [ ] Font selection appropriate for brand and platform
• [ ] Type scale follows consistent progression (1.2x, 1.5x, etc.)
• [ ] Line heights optimal for readability (1.4-1.6 for body text)
• [ ] Letter spacing appropriate for font size
• [ ] Font weights used consistently across hierarchy levels
• [ ] Text truncation and overflow handled properly
• [ ] Typography responsive behavior defined

Color System Review:

• [ ] Color palette aligned with brand guidelines
• [ ] Sufficient color contrast for accessibility (WCAG AA)
• [ ] Color usage semantic and consistent (success=green, error=red)
• [ ] Dark mode support if required
• [ ] Color tokens defined and documented
• [ ] Color combinations tested for color blindness
• [ ] Gradient usage appropriate and consistent

Spacing & Layout:

• [ ] Spacing system follows consistent scale (4px, 8px, 16px, 24px, 32px, etc.)
• [ ] Margins and padding applied consistently
• [ ] Grid system used appropriately
• [ ] White space usage enhances readability
• [ ] Alignment precise and consistent
• [ ] Layout adapts well to different content lengths

Visual Hierarchy:

• [ ] Important elements stand out clearly
• [ ] Heading levels create clear information structure
• [ ] Visual weight guides user attention appropriately
• [ ] Related content grouped visually
• [ ] Consistent visual patterns across screens

Severity Ratings:

• 🔴 Critical: Severe visual issues affecting usability or brand
• 🟠 High: Significant inconsistencies or quality problems
• 🟡 Medium: Minor visual issues or improvement opportunities
• 🟢 Low: Polish suggestions or nice-to-have improvements

Phase 3: User Experience Review

Review Areas:

User Flows:

• [ ] Primary user journeys clearly defined
• [ ] Flow steps logical and efficient
• [ ] Decision points clear and well-labeled
• [ ] Error paths and edge cases considered
• [ ] Exit points and escape hatches available
• [ ] Success states celebrated appropriately

Navigation:

• [ ] Navigation structure clear and intuitive
• [ ] Current location always clear to users
• [ ] Navigation consistent across sections
• [ ] Deep linking supported where appropriate
• [ ] Breadcrumbs used for complex hierarchies
• [ ] Back button behavior predictable

Interaction Patterns:

• [ ] Interactions follow platform conventions
• [ ] Feedback immediate for all actions
• [ ] Loading states designed for all async operations
• [ ] Error messages helpful and actionable
• [ ] Form validation inline and clear
• [ ] Confirmation dialogs for destructive actions

Information Architecture:

• [ ] Content organized logically
• [ ] Labels clear and understandable
• [ ] Search functionality accessible if needed
• [ ] Filters and sorting options appropriate
• [ ] Content density appropriate for use case

Cognitive Load:

• [ ] Information presented in digestible chunks
• [ ] Progressive disclosure used appropriately
• [ ] Defaults sensible and commonly used
• [ ] Choices limited to prevent decision paralysis
• [ ] Complex tasks broken into steps

Phase 4: Design System Compliance

Review Areas:

Component Usage:

• [ ] Existing components used where appropriate
• [ ] No duplicate components created unnecessarily
• [ ] Component usage follows documentation
• [ ] Custom components justified and documented
• [ ] Component composition patterns followed

Design Tokens:

• [ ] Colors reference design tokens, not hardcoded values
• [ ] Spacing uses token values consistently
• [ ] Typography references token values
• [ ] Border radius, shadows use tokens
• [ ] Tokens applied correctly in all contexts

Pattern Consistency:

• [ ] Common patterns used consistently (cards, lists, modals)
• [ ] Form patterns follow established conventions
• [ ] Data display patterns consistent (tables, charts)
• [ ] Navigation patterns uniform across app
• [ ] Feedback patterns applied consistently

Documentation Quality:

• [ ] New components documented with usage guidelines
• [ ] Props/variants clearly specified
• [ ] Examples provided for common use cases
• [ ] Do's and don'ts documented
• [ ] Accessibility notes included

Phase 5: Accessibility Audit

Review Areas:

WCAG 2.1 AA Compliance:

Perceivable:

• [ ] All images have alt text or are decorative
• [ ] Color not the only means of conveying information
• [ ] Text contrast meets 4.5:1 ratio (normal text) or 3:1 (large text)
• [ ] UI components meet 3:1 contrast ratio
• [ ] Content structured with proper headings
• [ ] Content readable and understandable without CSS

Operable:

• [ ] All functionality available via keyboard
• [ ] No keyboard traps exist
• [ ] Tab order logical and intuitive
• [ ] Focus indicators clearly visible
• [ ] Skip links provided for main content
• [ ] No time limits on interactions (or can be extended)
• [ ] No content flashes more than 3 times per second

Understandable:

• [ ] Language of page specified
• [ ] Navigation consistent across pages
• [ ] Labels and instructions clear
• [ ] Error messages specific and helpful
• [ ] Form fields have visible labels
• [ ] Required fields clearly indicated

Robust:

• [ ] Semantic HTML elements used appropriately
• [ ] ARIA labels used where needed
• [ ] Status messages announced to screen readers
• [ ] Custom controls have proper roles and states

Touch Target Sizing:

• [ ] Interactive elements minimum 44x44px
• [ ] Adequate spacing between touch targets
• [ ] Touch targets don't overlap

Phase 6: Responsive Design Assessment

Review Areas:

Mobile Design (320px - 767px):

• [ ] Critical content prioritized and visible
• [ ] Touch targets appropriately sized (44x44px minimum)
• [ ] Forms optimized for mobile input
• [ ] Navigation collapsed appropriately (hamburger menu)
• [ ] Images optimized for mobile bandwidth
• [ ] Horizontal scrolling avoided
• [ ] Typography readable without zooming

Tablet Design (768px - 1023px):

• [ ] Layout takes advantage of medium screen size
• [ ] Navigation appropriate for tablet interaction
• [ ] Touch and mouse interactions supported
• [ ] Content density balanced for tablet viewing
• [ ] Portrait and landscape orientations considered

Desktop Design (1024px+):

• [ ] Layout scales appropriately for large screens
• [ ] Line lengths optimal for readability (45-75 characters)
• [ ] Hover states designed for mouse interaction
• [ ] Multiple columns used effectively
• [ ] Whitespace prevents content sprawl on wide screens

Breakpoint Strategy:

• [ ] Breakpoints chosen based on content, not devices
• [ ] Major layout shifts at appropriate breakpoints
• [ ] Smooth transitions between breakpoints
• [ ] Content readable at all viewport sizes
• [ ] No unnecessary breakpoints

Phase 7: Component Architecture Review

Review Areas:

Component Structure:

• [ ] Components atomic, focused, single-purpose
• [ ] Component hierarchy clear and logical
• [ ] Composition preferred over inheritance
• [ ] Props interface intuitive and complete
• [ ] Component naming clear and consistent

Component States:

• [ ] Default state clearly defined
• [ ] Hover state provides visual feedback
• [ ] Active/pressed state distinct from hover
• [ ] Focus state highly visible for keyboard users
• [ ] Disabled state clearly indicates unavailability
• [ ] Loading state shown for async operations
• [ ] Error state visible and actionable
• [ ] Success state celebrates completion

Component Variants:

• [ ] Variants serve clear purposes
• [ ] Size variants follow consistent scale (sm, md, lg)
• [ ] Style variants limited and purposeful
• [ ] Variant combinations tested and supported
• [ ] Default variant appropriate for most use cases

Component Documentation:

• [ ] Component purpose clearly described
• [ ] All props documented with types
• [ ] Usage examples provided
• [ ] Accessibility considerations noted
• [ ] Related components cross-referenced

Phase 8: Reporting & Recommendations

Activities:

1. Consolidate Findings

• Categorize issues by severity and area
• Document each finding with screenshots
• Provide specific locations in design files
• Estimate effort required to address

2. Prioritize Recommendations

• Critical issues must be fixed before launch
• High-priority issues should be fixed soon
• Medium issues addressed in next iteration
• Low issues tracked for future improvements

3. Create Action Items

• Assign ownership for each issue
• Set realistic timelines for fixes
• Track progress on recommendations
• Schedule follow-up review

Design Review Report Template

Use this comprehensive template for frontend design review reports.

Report Structure

# Frontend Design Review Report

## Executive Summary

**Project**: [Project Name]  
**Review Date**: [Date]  
**Reviewer**: [Reviewer Name/Team]  
**Design Files**: [Links to Figma/Sketch/Adobe XD files]  
**Overall Assessment**: [Brief 2-3 sentence summary of design quality]

**Key Statistics:**
- Total screens reviewed: [number]
- Critical issues found: [number]
- High priority issues: [number]
- Medium priority issues: [number]
- Low priority issues: [number]
- Accessibility violations: [number]

**Summary**: [1-2 paragraph overview of review findings, major concerns, and recommendations]

---

## Review Scope

## Included in Review
- [List of screens/flows reviewed]
- [Design components evaluated]
- [Specific aspects covered: accessibility, responsive design, etc.]

### Excluded from Review
- [Items not included in scope]
- [Future work to be reviewed separately]

### Review Focus Areas
- [ ] UI/UX Design Quality
- [ ] Design System Consistency
- [ ] Accessibility Compliance (WCAG 2.1 AA)
- [ ] Responsive Design Patterns
- [ ] Component Architecture
- [ ] Visual Design Consistency

---

## Findings Summary

### Critical Issues (Blocking)
[Issues that must be fixed before launch]

| ID | Issue | Screen/Component | Severity | Impact |
| ---- | ------- |------------------|----------|---------|
| C-01 | [Issue description] | [Location] | Critical | [Impact description] |

### High Priority Issues
[Issues that significantly impact usability or accessibility]

| ID | Issue | Screen/Component | Severity | Impact |
| ---- | ------- |------------------|----------|---------|
| H-01 | [Issue description] | [Location] | High | [Impact description] |

### Medium Priority Issues
[Issues that affect experience but aren't blocking]

| ID | Issue | Screen/Component | Severity | Impact |
| ---- | ------- |------------------|----------|---------|
| M-01 | [Issue description] | [Location] | Medium | [Impact description] |

### Low Priority Issues
[Minor improvements and polish items]

| ID | Issue | Screen/Component | Severity | Impact |
| ---- | ------- |------------------|----------|---------|
| L-01 | [Issue description] | [Location] | Low | [Impact description] |

---

## Detailed Findings

### 1. UI/UX Design Quality

#### Typography
**Status**: ✅ Pass | ⚠️ Issues Found | ❌ Major Issues

**Findings:**
- [Finding 1 with specific examples]
- [Finding 2 with specific examples]

**Recommendations:**
- [Specific actionable recommendation]

#### Color System
**Status**: ✅ Pass | ⚠️ Issues Found | ❌ Major Issues

**Findings:**
- [Finding 1 with contrast ratios]
- [Finding 2 with color usage issues]

**Recommendations:**
- [Specific actionable recommendation]

#### Layout & Spacing
**Status**: ✅ Pass | ⚠️ Issues Found | ❌ Major Issues

**Findings:**
- [Finding 1]
- [Finding 2]

**Recommendations:**
- [Specific actionable recommendation]

#### Visual Hierarchy
**Status**: ✅ Pass | ⚠️ Issues Found | ❌ Major Issues

**Findings:**
- [Finding 1]
- [Finding 2]

**Recommendations:**
- [Specific actionable recommendation]

### 2. Design System Consistency

#### Component Usage
**Status**: ✅ Pass | ⚠️ Issues Found | ❌ Major Issues

**Findings:**
- [Deviations from design system]
- [Custom components that should use system components]

**Recommendations:**
- [Specific actionable recommendation]

#### Design Tokens
**Status**: ✅ Pass | ⚠️ Issues Found | ❌ Major Issues

**Findings:**
- [Hard-coded values found]
- [Token misuse]

**Recommendations:**
- [Specific actionable recommendation]

### 3. Accessibility Compliance

#### WCAG 2.1 AA Compliance
**Status**: ✅ Compliant | ⚠️ Partial | ❌ Non-Compliant

**Color Contrast:**
- [Pass/Fail for each text element with ratios]
- Example: Body text on white: 4.8:1 ✅ (meets 4.5:1 requirement)

**Keyboard Navigation:**
- [Tab order issues]
- [Focus indicators missing/unclear]

**Screen Reader Support:**
- [Missing ARIA labels]
- [Semantic structure issues]

**Recommendations:**
- [Specific actionable accessibility fixes]

### 4. Responsive Design

#### Breakpoint Strategy
**Status**: ✅ Pass | ⚠️ Issues Found | ❌ Major Issues

**Findings:**
- [Breakpoint analysis]
- [Content adaptation issues]

**Recommendations:**
- [Specific actionable recommendation]

#### Mobile Experience
**Status**: ✅ Pass | ⚠️ Issues Found | ❌ Major Issues

**Findings:**
- [Touch target sizing issues]
- [Mobile-specific usability problems]

**Recommendations:**
- [Specific actionable recommendation]

### 5. Component Architecture

#### Component Design
**Status**: ✅ Pass | ⚠️ Issues Found | ❌ Major Issues

**Findings:**
- [Component reusability issues]
- [Missing component states]
- [Variant design problems]

**Recommendations:**
- [Specific actionable recommendation]

---

## Positive Observations

[Highlight what's working well in the design]

- ✅ **[Strength 1]**: [Description of what's done well]
- ✅ **[Strength 2]**: [Description of what's done well]
- ✅ **[Strength 3]**: [Description of what's done well]

---

## Recommendations Summary

### Immediate Actions (Before Development)
1. **[Critical fix 1]**
   - Impact: [Description]
   - Effort: [Low/Medium/High]
   - Owner: [Design/Development]

2. **[Critical fix 2]**
   - Impact: [Description]
   - Effort: [Low/Medium/High]
   - Owner: [Design/Development]

### Short-Term Improvements (Next Sprint)
1. **[High priority improvement 1]**
   - Impact: [Description]
   - Effort: [Low/Medium/High]

2. **[High priority improvement 2]**
   - Impact: [Description]
   - Effort: [Low/Medium/High]

### Long-Term Enhancements (Backlog)
1. **[Medium/Low priority item 1]**
   - Impact: [Description]
   - Effort: [Low/Medium/High]

---

## Action Items

| Priority | Action | Owner | Due Date | Status |
| ---------- | -------- |-------|----------|--------|
| Critical | [Action item] | [Name] | [Date] | Not Started |
| High | [Action item] | [Name] | [Date] | Not Started |
| Medium | [Action item] | [Name] | [Date] | Not Started |

---

## Next Steps

1. **Design Team Actions:**
   - [Specific design revisions needed]
   - [Design system updates required]

2. **Development Team Actions:**
   - [Implementation considerations]
   - [Technical feasibility review needed]

3. **Stakeholder Review:**
   - [Items requiring business/stakeholder input]
   - [Decision points needed]

4. **Follow-up Review:**
   - Schedule: [Date for re-review]
   - Focus areas: [Specific areas to re-evaluate]

---

## Appendix

### A. Severity Level Definitions

**Critical**: Issues that must be fixed before launch. Block user tasks or violate legal requirements (accessibility laws).

**High**: Significant usability or accessibility issues that severely degrade experience but don't completely block tasks.

**Medium**: Issues that negatively impact user experience but have workarounds. Should be fixed soon.

**Low**: Minor polish items, nice-to-haves, and optimizations that can be addressed over time.

### B. Accessibility Standards Reference

- **WCAG 2.1 AA**: Web Content Accessibility Guidelines Level AA
- **Minimum Contrast Ratios**: 
  - Normal text: 4.5:1
  - Large text (18pt+ or 14pt+ bold): 3:1
  - UI components: 3:1
- **Minimum Touch Targets**: 44x44 CSS pixels

### C. Design Files & Resources

- Design files: [Links]
- Design system documentation: [Links]
- Brand guidelines: [Links]
- Previous review reports: [Links]

### D. Review Methodology

**Tools Used:**
- Figma/Sketch inspection
- Color contrast checkers (e.g., WebAIM, Stark)
- Accessibility evaluation (manual inspection)
- Responsive design analysis

**Standards Applied:**
- WCAG 2.1 AA
- Company design system guidelines
- Platform-specific design guidelines (iOS HIG, Material Design, etc.)
- Industry best practices

Usage Notes

When to use this template:

• Formal design reviews before development
• Accessibility audits
• Design system compliance checks
• Pre-release design validation

Customization:

• Remove sections not relevant to your review scope
• Add project-specific sections as needed
• Adjust severity levels to match your team's definitions
• Include visual examples/screenshots where helpful

Report delivery tips:

• Export as PDF for formal documentation
• Create Figma/Sketch comments linking to specific findings
• Schedule walkthrough meeting to discuss findings
• Prioritize findings collaboratively with team

Design System Patterns Reference

This document provides comprehensive guidance on evaluating and validating design system patterns, component libraries, design tokens, and design system governance during frontend design reviews.

Table of Contents

1. Design Tokens 2. Component Patterns 3. Layout Patterns 4. Navigation Patterns 5. Form Patterns 6. Feedback Patterns 7. Data Display Patterns 8. Design System Governance

---

Design Tokens

Design tokens are the visual design atoms of a design system—specifically, they are named entities that store visual design attributes. They ensure consistency across products and platforms.

Color Tokens

Token Structure:

# Semantic color tokens (preferred)
color:
  brand:
    primary: '#0066CC'
    secondary: '#6B46C1'
  feedback:
    success: '#10B981'
    warning: '#F59E0B'
    error: '#EF4444'
    info: '#3B82F6'
  text:
    primary: '#1F2937'
    secondary: '#6B7280'
    tertiary: '#9CA3AF'
    inverse: '#FFFFFF'
  background:
    primary: '#FFFFFF'
    secondary: '#F9FAFB'
    tertiary: '#F3F4F6'
  border:
    default: '#E5E7EB'
    strong: '#D1D5DB'

Review Checklist:

• [ ] Semantic naming used (not colors like "blue-500")
• [ ] Sufficient contrast ratios for accessibility
• [ ] Dark mode tokens defined if applicable
• [ ] Consistent color usage across designs
• [ ] Colors mapped to design tokens, not hardcoded
• [ ] Limited color palette prevents color chaos
• [ ] Color tokens documented with usage guidelines

Common Issues:

• ❌ Hardcoded hex values instead of token references
• ❌ Too many color variations (e.g., 15 shades of blue)
• ❌ Inconsistent semantic naming (success vs. positive)
• ❌ Missing dark mode color tokens
• ❌ Poor contrast ratios not caught in token definition

Typography Tokens

Token Structure:

typography:
  font-family:
    primary: 'Inter, system-ui, sans-serif'
    mono: 'Fira Code, Consolas, monospace'
  
  font-size:
    xs: '0.75rem'    # 12px
    sm: '0.875rem'   # 14px
    base: '1rem'     # 16px
    lg: '1.125rem'   # 18px
    xl: '1.25rem'    # 20px
    2xl: '1.5rem'    # 24px
    3xl: '1.875rem'  # 30px
    4xl: '2.25rem'   # 36px
  
  font-weight:
    normal: 400
    medium: 500
    semibold: 600
    bold: 700
  
  line-height:
    tight: 1.25
    normal: 1.5
    relaxed: 1.75
  
  letter-spacing:
    tight: '-0.025em'
    normal: '0'
    wide: '0.025em'

Review Checklist:

• [ ] Type scale follows consistent ratio (1.2x, 1.25x, 1.5x)
• [ ] Line heights appropriate for font sizes
• [ ] Font weights available and used consistently
• [ ] Limited number of font sizes (6-8 typically sufficient)
• [ ] Responsive typography strategy defined
• [ ] Font loading strategy considered
• [ ] Fallback fonts specified

Spacing Tokens

Token Structure:

spacing:
  0: '0'
  1: '0.25rem'   # 4px
  2: '0.5rem'    # 8px
  3: '0.75rem'   # 12px
  4: '1rem'      # 16px
  5: '1.25rem'   # 20px
  6: '1.5rem'    # 24px
  8: '2rem'      # 32px
  10: '2.5rem'   # 40px
  12: '3rem'     # 48px
  16: '4rem'     # 64px
  20: '5rem'     # 80px

Review Checklist:

• [ ] Spacing scale follows consistent progression (typically 4px base)
• [ ] Limited number of spacing values
• [ ] Spacing tokens used for margins, padding, gaps
• [ ] Optical adjustments documented where needed
• [ ] Consistent spacing between related elements
• [ ] Spacing scales appropriately at different breakpoints

Shadow Tokens

Token Structure:

shadow:
  sm: '0 1px 2px 0 rgba(0, 0, 0, 0.05)'
  base: '0 1px 3px 0 rgba(0, 0, 0, 0.1), 0 1px 2px 0 rgba(0, 0, 0, 0.06)'
  md: '0 4px 6px -1px rgba(0, 0, 0, 0.1), 0 2px 4px -1px rgba(0, 0, 0, 0.06)'
  lg: '0 10px 15px -3px rgba(0, 0, 0, 0.1), 0 4px 6px -2px rgba(0, 0, 0, 0.05)'
  xl: '0 20px 25px -5px rgba(0, 0, 0, 0.1), 0 10px 10px -5px rgba(0, 0, 0, 0.04)'

Review Checklist:

• [ ] Shadow scale indicates elevation hierarchy
• [ ] Consistent shadow usage across similar components
• [ ] Shadows subtle and not distracting
• [ ] Dark mode shadow variants defined

Border Radius Tokens

Token Structure:

border-radius:
  none: '0'
  sm: '0.125rem'   # 2px
  base: '0.25rem'  # 4px
  md: '0.375rem'   # 6px
  lg: '0.5rem'     # 8px
  xl: '0.75rem'    # 12px
  2xl: '1rem'      # 16px
  full: '9999px'   # Pill shape

Review Checklist:

• [ ] Consistent border radius usage
• [ ] Limited number of radius values
• [ ] Border radius appropriate for component size
• [ ] Consistent across similar components

---

Component Patterns

Button Component

States Required:

• Default (rest state)
• Hover
• Active/Pressed
• Focus (keyboard)
• Disabled
• Loading

Variants:

• Style: Primary, Secondary, Tertiary, Danger, Ghost
• Size: Small, Medium, Large
• Icon: Icon left, Icon right, Icon only

Review Checklist:

• [ ] All states designed and visually distinct
• [ ] Focus indicator clearly visible (3px outline minimum)
• [ ] Disabled state clearly indicates unavailability (reduced opacity, no hover)
• [ ] Loading state shows spinner or loading indicator
• [ ] Minimum touch target 44x44px on mobile
• [ ] Icon alignment consistent across sizes
• [ ] Text truncation handled for long labels
• [ ] Variants limited and purposeful
• [ ] Destructive actions use danger variant

Example Specifications:

Button:
  sizes:
    sm:
      height: 32px
      padding-x: 12px
      font-size: 14px
    md:
      height: 40px
      padding-x: 16px
      font-size: 16px
    lg:
      height: 48px
      padding-x: 20px
      font-size: 18px
  
  variants:
    primary:
      background: color.brand.primary
      text: color.text.inverse
      hover-background: color.brand.primary-dark
    
    secondary:
      background: color.background.secondary
      text: color.text.primary
      border: 1px solid color.border.default

Input Field Component

States Required:

• Empty (placeholder visible)
• Filled (user entered text)
• Focus
• Disabled
• Error
• Success
• Read-only

Elements:

• Label (required)
• Input field
• Helper text
• Error message
• Success message
• Optional indicator
• Character count (if applicable)

Review Checklist:

• [ ] Label always visible (not using placeholder as label)
• [ ] Placeholder text provides example, not instructions
• [ ] Error messages specific and actionable
• [ ] Error state shows red border and error icon
• [ ] Focus state has clear visual indicator
• [ ] Required fields clearly marked (asterisk or "required" text)
• [ ] Helper text provides useful guidance
• [ ] Disabled state clearly indicates unavailability
• [ ] Touch target includes label area (easier to tap)
• [ ] Input height minimum 44px on mobile

Card Component

Elements:

• Container
• Header (optional)
• Content area
• Footer (optional)
• Image/media (optional)
• Actions (optional)

Review Checklist:

• [ ] Padding consistent across card sections
• [ ] Clickable cards have hover state
• [ ] Shadow or border defines card boundaries
• [ ] Content hierarchy clear within card
• [ ] Responsive behavior defined (stacking, wrapping)
• [ ] Loading state designed if content loads async
• [ ] Empty state designed if content might be missing

Modal/Dialog Component

Elements:

• Backdrop (overlay)
• Container
• Header with title
• Close button
• Content area
• Footer with actions

Review Checklist:

• [ ] Backdrop dims background content
• [ ] Modal centered and responsive
• [ ] Close button clearly visible (top-right corner)
• [ ] Focus trapped within modal when open
• [ ] Escape key closes modal
• [ ] Scrollable content area if content long
• [ ] Primary and secondary actions clear
• [ ] Modal width limited (max-width: 600px typical)
• [ ] Animation smooth (fade in/scale up)

Dropdown/Select Component

States:

• Closed
• Open
• Selected
• Hover (on options)
• Focus
• Disabled
• Error

Review Checklist:

• [ ] Current selection clearly visible when closed
• [ ] Dropdown icon indicates interactivity
• [ ] Options list easy to scan (good spacing, typography)
• [ ] Selected option highlighted in open list
• [ ] Keyboard navigation supported (arrow keys)
• [ ] Search functionality for long lists
• [ ] Max height with scrolling for long lists
• [ ] Option grouping if applicable
• [ ] Multi-select uses checkboxes, not just highlighting

---

Layout Patterns

Grid Systems

Common Grid Systems:

• 12-column grid (most flexible)
• 4-column grid mobile, 8-column tablet, 12-column desktop
• Flexbox-based responsive grid
• CSS Grid-based layout system

Review Checklist:

• [ ] Grid system consistent across designs
• [ ] Column count appropriate for breakpoint
• [ ] Gutters (gaps) consistent
• [ ] Content aligned to grid columns
• [ ] Grid adapts logically at breakpoints
• [ ] Maximum content width defined for readability

Example Specifications:

Grid:
  mobile:
    columns: 4
    gutter: 16px
    margin: 16px
  
  tablet:
    columns: 8
    gutter: 24px
    margin: 32px
  
  desktop:
    columns: 12
    gutter: 32px
    margin: 40px
    max-width: 1280px

Container Patterns

Container Types:

• Fluid Container: Full width, adapts to viewport
• Fixed Container: Maximum width with centered content
• Constrained Container: Maximum width with side padding

Review Checklist:

• [ ] Container type appropriate for content
• [ ] Maximum width prevents line length issues
• [ ] Side padding prevents edge collision on mobile
• [ ] Container breakpoints defined
• [ ] Nested containers handled appropriately

Spacing Patterns

Vertical Rhythm:

• Consistent spacing between sections
• Larger spacing between major sections
• Smaller spacing between related elements
• Spacing scales with heading hierarchy

Review Checklist:

• [ ] Vertical spacing consistent throughout design
• [ ] Related content grouped with less spacing
• [ ] Unrelated content separated with more spacing
• [ ] Spacing follows spacing token system
• [ ] Spacing adapts at different breakpoints

---

Navigation Patterns

Primary Navigation

Common Patterns:

• Horizontal Navigation Bar: Links in header, always visible
• Hamburger Menu: Mobile menu, expandable sidebar
• Tab Navigation: Content switching within a page
• Sidebar Navigation: Persistent navigation on left/right

Review Checklist:

• [ ] Current location clearly indicated (active state)
• [ ] Navigation structure logical and intuitive
• [ ] Mobile navigation appropriate (hamburger, bottom nav)
• [ ] Dropdown menus keyboard accessible
• [ ] Logo/home link in top-left corner
• [ ] Important actions accessible (login, CTA)
• [ ] Sticky navigation if scrolling long pages

Breadcrumb Navigation

Review Checklist:

• [ ] Breadcrumbs show hierarchy, not history
• [ ] Current page shown but not clickable
• [ ] Separators clear (/, >, chevron)
• [ ] Truncation handled for long paths
• [ ] Positioned above page content
• [ ] Links to all ancestor pages

Pagination

Patterns:

• Numbered Pages: 1, 2, 3, 4, 5
• Previous/Next: Simple navigation
• Load More: Button to fetch more results
• Infinite Scroll: Automatic loading

Review Checklist:

• [ ] Current page clearly indicated
• [ ] Previous/Next buttons always available
• [ ] Total pages visible
• [ ] Jump to page functionality for long lists
• [ ] Loading state designed
• [ ] Results count shown

---

Form Patterns

Form Layout

Patterns:

• Single Column: Easiest to scan, recommended for most forms
• Two Column: For related fields (first name/last name)
• Multi-step: Complex forms broken into steps
• Inline Editing: Edit in place without form submission

Review Checklist:

• [ ] Single column layout preferred for simplicity
• [ ] Related fields grouped visually
• [ ] Required vs. optional fields clearly marked
• [ ] Field labels always visible (not placeholder-only)
• [ ] Logical tab order
• [ ] Clear submit button

Form Validation

Validation Timing:

• On Submit: Validate when user submits form
• On Blur: Validate when user leaves field
• On Change: Real-time validation (passwords, usernames)
• Progressive: More validation as user progresses

Review Checklist:

• [ ] Inline validation provides immediate feedback
• [ ] Error messages specific and actionable
• [ ] Error styling clear (red border, error icon)
• [ ] Success validation shown (green checkmark)
• [ ] Error summary at top of form
• [ ] Focus moves to first error field
• [ ] Required field validation clear

Form States

Review Checklist:

• [ ] Empty state (placeholders, helper text)
• [ ] Filling state (focus indicators, inline validation)
• [ ] Submitting state (loading spinner, disabled submit)
• [ ] Success state (confirmation message)
• [ ] Error state (error messages, red styling)
• [ ] Disabled state (when form unavailable)

---

Feedback Patterns

Toast/Snackbar Notifications

Properties:

• Duration: 3-5 seconds typically
• Position: Top-right, bottom-center, or top-center
• Types: Success, Error, Warning, Info
• Actions: Optional close button or action button

Review Checklist:

• [ ] Icon indicates message type (✓ success, ✕ error)
• [ ] Color coding semantic (green success, red error)
• [ ] Message concise and understandable
• [ ] Positioned to not block critical content
• [ ] Dismissible with close button
• [ ] Auto-dismiss after appropriate duration
• [ ] Multiple toasts stack appropriately

Loading States

Patterns:

• Spinner: Indeterminate loading (circular or linear)
• Skeleton Screens: Content placeholders showing layout
• Progress Bar: Determinate loading with percentage
• Optimistic UI: Show expected result immediately

Review Checklist:

• [ ] Loading indicator shown for operations > 1 second
• [ ] Loading message provides context ("Loading users...")
• [ ] Skeleton screens match final content layout
• [ ] Progress bar shows accurate progress
• [ ] Cancel option for long operations
• [ ] Spinner appropriate size and position

Empty States

Elements:

• Illustration or icon
• Headline explaining emptiness
• Description text
• Primary action (CTA)

Review Checklist:

• [ ] Friendly and helpful tone
• [ ] Illustration appropriate and not distracting
• [ ] Clear explanation of why state is empty
• [ ] Action provided to populate (if applicable)
• [ ] Helpful suggestions provided

Error States

Review Checklist:

• [ ] Error message explains what went wrong
• [ ] Error message explains how to fix it
• [ ] Technical details hidden (shown in details link)
• [ ] Error styling clear (red color, error icon)
• [ ] Retry action provided if applicable
• [ ] Support contact information for critical errors

---

Data Display Patterns

Table Pattern

Elements:

• Table header
• Sortable columns (with indicators)
• Row selection (checkboxes)
• Row actions (buttons/icons)
• Pagination
• Search/filter

Review Checklist:

• [ ] Column headers clear and concise
• [ ] Sortable columns have indicators
• [ ] Zebra striping or row borders improve scannability
• [ ] Hover state on rows provides feedback
• [ ] Sticky header for long tables
• [ ] Responsive behavior defined (card view on mobile)
• [ ] Row actions accessible and clear
• [ ] Pagination visible and functional
• [ ] Loading state for async data

List Pattern

Types:

• Simple List: Text items only
• List with Avatars: User lists, contact lists
• List with Actions: Buttons or icons per item
• List with Sections: Grouped lists with headers

Review Checklist:

• [ ] List items have adequate spacing
• [ ] Clickable lists show hover state
• [ ] Selected item clearly indicated
• [ ] Loading skeleton matches list layout
• [ ] Empty state designed
• [ ] Section headers distinct from items

Chart/Graph Pattern

Common Charts:

• Line chart (trends over time)
• Bar chart (comparisons)
• Pie/donut chart (proportions)
• Area chart (cumulative values)

Review Checklist:

• [ ] Chart type appropriate for data
• [ ] Axes labeled clearly
• [ ] Legend provided if needed
• [ ] Colors distinguishable (accessible)
• [ ] Interactive tooltips on hover
• [ ] Responsive behavior defined
• [ ] Loading state designed
• [ ] No data state designed

---

Design System Governance

Component Approval Process

Stages:

1. Proposal: Designer proposes new component or variant 2. Review: Design system team reviews for necessity 3. Design: Component designed with all states and variants 4. Documentation: Usage guidelines written 5. Implementation: Component built in code 6. Release: Component added to library

Review Checklist:

• [ ] Clear process for proposing new components
• [ ] Design system team reviews proposals
• [ ] Documentation written before release
• [ ] Component tested across platforms
• [ ] Versioning strategy defined

Documentation Standards

Required Documentation:

• Component Name: Clear, descriptive name
• Description: What the component does and when to use it
• Variants: All size/style variants documented
• States: All interactive states shown
• Props/Options: Configurable properties listed
• Usage Guidelines: Do's and don'ts with examples
• Accessibility Notes: Keyboard support, ARIA labels
• Code Examples: Implementation examples

Review Checklist:

• [ ] Complete documentation for all components
• [ ] Visual examples provided
• [ ] Code examples provided
• [ ] Do's and don'ts section
• [ ] Accessibility guidance included
• [ ] Related components linked
• [ ] Version history tracked

Version Management

Versioning Strategy:

• Major Version (1.0 → 2.0): Breaking changes
• Minor Version (1.0 → 1.1): New features, backward compatible
• Patch Version (1.0.0 → 1.0.1): Bug fixes

Review Checklist:

• [ ] Version number follows semantic versioning
• [ ] Breaking changes clearly documented
• [ ] Migration guide provided for major versions
• [ ] Changelog maintained
• [ ] Deprecated components marked clearly
• [ ] Sunset timeline communicated

Design Token Management

Governance:

• Centralized token repository
• Token naming conventions enforced
• Token change request process
• Impact analysis before token changes
• Versioning for token libraries

Review Checklist:

• [ ] All colors, spacing, typography defined as tokens
• [ ] Token naming follows conventions
• [ ] New tokens justified (not duplicating existing)
• [ ] Token changes impact assessed
• [ ] Dark mode tokens maintained in sync

Component Library Maintenance

Activities:

• Regular audits for unused components
• Deprecation of redundant components
• Updates for accessibility improvements
• Performance optimizations
• Platform consistency checks

Review Checklist:

• [ ] Regular component audits scheduled
• [ ] Unused components identified and removed
• [ ] Accessibility continuously improved
• [ ] Performance monitored
• [ ] Cross-platform consistency maintained

---

Design System Review Checklist

Use this comprehensive checklist when reviewing design system compliance:

Component Library

• [ ] Components follow design system patterns
• [ ] No duplicate components created unnecessarily
• [ ] Component variants purposeful and limited
• [ ] All component states designed
• [ ] Component naming consistent with system
• [ ] New components justified and documented

Design Tokens

• [ ] Colors reference tokens, not hardcoded values
• [ ] Spacing uses token values consistently
• [ ] Typography references token values
• [ ] Border radius, shadows use tokens
• [ ] Semantic token naming followed
• [ ] No one-off values created outside token system

Documentation

• [ ] New components fully documented
• [ ] Usage guidelines clear and helpful
• [ ] Do's and don'ts provided
• [ ] Accessibility notes included
• [ ] Code examples provided
• [ ] Related components cross-referenced

Accessibility

• [ ] WCAG AA compliance verified
• [ ] Keyboard navigation supported
• [ ] Focus indicators visible
• [ ] Color contrast sufficient
• [ ] Semantic HTML used
• [ ] ARIA labels provided where needed

Consistency

• [ ] Visual consistency across all screens
• [ ] Interaction patterns consistent
• [ ] Terminology consistent
• [ ] Spacing consistent
• [ ] Color usage semantic and consistent
• [ ] Typography hierarchy consistent

Governance

• [ ] Changes follow approval process
• [ ] Breaking changes documented
• [ ] Version numbers appropriate
• [ ] Deprecations communicated
• [ ] Migration guides provided
• [ ] Impact assessment completed

---

Summary

Design system patterns ensure consistency, efficiency, and quality across products. When reviewing designs:

1. Verify Token Usage: Ensure all visual attributes use design tokens 2. Check Component Compliance: Confirm components follow established patterns 3. Validate States: Ensure all interaction states are designed 4. Review Documentation: Verify thorough documentation exists 5. Assess Governance: Confirm proper approval and versioning processes 6. Maintain Consistency: Ensure patterns used consistently across designs

A well-governed design system accelerates design and development while ensuring consistent, high-quality user experiences.

Responsive Design Patterns Reference

This document provides comprehensive guidance on evaluating responsive design strategies, breakpoint selection, mobile-first approaches, and adaptive patterns during frontend design reviews.

Table of Contents

1. Responsive Design Principles 2. Breakpoint Strategies 3. Mobile-First Design 4. Layout Patterns 5. Navigation Patterns 6. Typography Patterns 7. Image & Media Patterns 8. Touch & Interaction Patterns 9. Performance Considerations 10. Testing Responsive Designs

---

Responsive Design Principles

Core Principles

1. Fluid Grids: Layouts use relative units (%, rem, em) instead of fixed pixels 2. Flexible Images: Images scale within containing elements 3. Media Queries: CSS adapts to different screen sizes 4. Mobile-First: Design for mobile first, enhance for larger screens 5. Content Priority: Most important content accessible at all sizes

Viewport Meta Tag

Required for Responsive Design:

<meta name="viewport" content="width=device-width, initial-scale=1">

Review Checklist:

• [ ] Viewport meta tag present in HTML head
• [ ] width=device-width ensures proper mobile rendering
• [ ] initial-scale=1 prevents unexpected zooming
• [ ] No user-scalable=no (blocks accessibility)

---

Breakpoint Strategies

Common Breakpoint Ranges

Standard Breakpoints:

/* Mobile (default, no media query) */
/* 320px - 767px */

/* Tablet */
@media (min-width: 768px) { ... }

/* Desktop */
@media (min-width: 1024px) { ... }

/* Large Desktop */
@media (min-width: 1280px) { ... }

/* Extra Large Desktop */
@media (min-width: 1536px) { ... }

Review Checklist:

• [ ] Breakpoints based on content, not devices
• [ ] Consistent breakpoint values across designs
• [ ] Limited number of breakpoints (3-5 typically)
• [ ] Major layout changes at breakpoints
• [ ] Smooth transitions between breakpoints
• [ ] Content readable at all viewport sizes

Device-Based vs. Content-Based Breakpoints

❌ Device-Based (Avoid):

/* iPhone 6 */
@media (width: 375px) { ... }

/* iPad */
@media (width: 768px) { ... }

Issue: Devices constantly change, designs become outdated

✅ Content-Based (Recommended):

/* When navigation wraps uncomfortably */
@media (min-width: 768px) { ... }

/* When line length becomes too long */
@media (min-width: 1024px) { ... }

Benefit: Design adapts to content needs, not device specs

Breakpoint Naming

Approach 1: Size-Based (Recommended)

breakpoints:
  sm: 640px
  md: 768px
  lg: 1024px
  xl: 1280px
  2xl: 1536px

Approach 2: Device-Based (Common)

breakpoints:
  mobile: 0px
  tablet: 768px
  desktop: 1024px
  wide: 1280px

Review Checklist:

• [ ] Naming convention clear and consistent
• [ ] Names don't imply specific devices
• [ ] Documented breakpoint values
• [ ] Team aligned on breakpoint names

---

Mobile-First Design

Mobile-First Approach

Definition: Design for mobile first, then progressively enhance for larger screens.

Benefits:

• Forces content prioritization
• Better performance (load only what's needed)
• Easier to scale up than scale down
• Mobile constraints improve overall design

Mobile-First CSS:

/* Base styles (mobile) */
.container {
  padding: 16px;
  font-size: 16px;
}

/* Enhance for tablet */
@media (min-width: 768px) {
  .container {
    padding: 32px;
    font-size: 18px;
  }
}

/* Enhance for desktop */
@media (min-width: 1024px) {
  .container {
    padding: 40px;
    max-width: 1280px;
    margin: 0 auto;
  }
}

Review Checklist:

• [ ] Base styles optimized for mobile (320px+)
• [ ] Progressive enhancement for larger screens
• [ ] Critical content prioritized on mobile
• [ ] Mobile experience fully functional (not stripped-down)
• [ ] Desktop enhancements add value (not just decorative)

Content Prioritization

Mobile Content Strategy:

1. Primary Actions: Most important CTAs visible 2. Core Content: Essential information accessible 3. Navigation: Simplified, easy to use 4. Optional Content: Hidden or deferred (progressive disclosure)

Review Checklist:

• [ ] Most important content visible on mobile without scrolling
• [ ] Primary CTA prominent and accessible
• [ ] Secondary content accessible but not prioritized
• [ ] Tertiary content collapsed or hidden (expandable)
• [ ] No horizontal scrolling on mobile

Mobile-First Design Patterns

1. Stacked Layout (Mobile) → Multi-Column (Desktop)

Mobile:        Desktop:
[Header]       [Header      ]
[Nav]          [Nav | Content]
[Content]      [Nav | Content]
[Sidebar]      [    | Sidebar]
[Footer]       [Footer      ]

2. Hamburger Menu (Mobile) → Horizontal Nav (Desktop)

Mobile:        Desktop:
[☰ Logo]       [Logo  Nav Nav Nav  Login]

3. Single Column (Mobile) → Grid (Desktop)

Mobile:        Desktop:
[Card 1]       [Card1  Card2  Card3]
[Card 2]       [Card4  Card5  Card6]
[Card 3]

---

Layout Patterns

1. Mostly Fluid Pattern

Description: Multi-column layout that adapts at breakpoints

Mobile (320px+):

• Single column
• Full width content
• Stacked elements

Tablet (768px+):

• Two columns
• Sidebar appears
• Grid layout begins

Desktop (1024px+):

• Three+ columns
• Maximum width constraint
• Margins on wide screens

Review Checklist:

• [ ] Fluid grid scales smoothly
• [ ] Content doesn't break at any size
• [ ] Max-width prevents line length issues
• [ ] Columns reflow at appropriate breakpoints

Example:

Mobile:           Tablet:              Desktop:
[  Content  ]     [Content | Side]     [  Content  |  Side  ]
[  Content  ]     [Content | Side]     [  Content  |  Side  ]
                                        (max-width: 1280px)

2. Column Drop Pattern

Description: Columns stack vertically as screen narrows

Desktop: 3 columns side-by-side Tablet: 2 columns (third drops below) Mobile: 1 column (all stacked)

Review Checklist:

• [ ] Columns drop at logical points
• [ ] Content priority maintained when stacking
• [ ] Smooth transitions between layouts
• [ ] No awkward gaps or overlaps

Example:

Desktop:          Tablet:           Mobile:
[A | B | C]       [A | B]           [A]
                  [  C  ]           [B]
                                    [C]

3. Layout Shifter Pattern

Description: Most responsive pattern with significant layout changes at breakpoints

Characteristics:

• Complete layout rearrangement at breakpoints
• Different visual hierarchy at different sizes
• Most flexible but requires most design work

Review Checklist:

• [ ] Layout changes purposeful and improve UX
• [ ] Content hierarchy logical at each size
• [ ] Transitions smooth and not jarring
• [ ] All layouts fully tested

Example:

Mobile:           Tablet:              Desktop:
[Header]          [Logo | Nav    ]     [Logo | Nav  | Login]
[Nav]             [Content       ]     [Side | Content    ]
[Content]         [Side | Footer ]     [Side | Content    ]
[Sidebar]                              [      | Footer    ]
[Footer]

4. Off-Canvas Pattern

Description: Navigation or sidebar hidden off-screen, slides in when triggered

Mobile:

• Hamburger menu button
• Navigation slides in from left/right
• Overlay dims background

Desktop:

• Navigation always visible
• Or persistent sidebar

Review Checklist:

• [ ] Off-canvas menu keyboard accessible
• [ ] Close button clearly visible
• [ ] Focus trapped within open menu
• [ ] Escape key closes menu
• [ ] Smooth animation

5. Tiny Tweaks Pattern

Description: Minimal changes across breakpoints (simple sites)

Characteristics:

• Single column layout at all sizes
• Font size adjustments
• Padding/margin changes
• Image scaling

Review Checklist:

• [ ] Appropriate for simple content
• [ ] Typography scales readably
• [ ] Spacing adjusts for screen size
• [ ] Images scale proportionally

---

Navigation Patterns

1. Hamburger Menu (Mobile)

Best Practices:

• Use familiar icon (☰ three horizontal lines)
• Label icon with "Menu" text for clarity
• Position in top-left or top-right corner
• Slide-in animation smooth
• Close button visible inside menu
• Backdrop overlay dims main content

Review Checklist:

• [ ] Hamburger icon recognizable
• [ ] Menu slides in smoothly (300ms transition)
• [ ] Close button (X) clearly visible
• [ ] Focus trapped in open menu
• [ ] Escape key closes menu
• [ ] Backdrop dismisses menu on click
• [ ] Current page highlighted in menu
• [ ] Menu scrollable if long

Hamburger Menu States:

Closed:           Open:
[☰ Logo]          [X   Menu     ]
[Content]         [- Home       ] ← overlay
[Content]         [- About      ]
                  [- Services   ]
                  [- Contact    ]

2. Bottom Navigation (Mobile Apps)

Best Practices:

• 3-5 primary navigation items
• Icons with labels
• Fixed at bottom of screen
• Current tab highlighted
• Large touch targets (48px+)

Review Checklist:

• [ ] 3-5 items maximum
• [ ] Icons clear and recognizable
• [ ] Labels visible (not icon-only)
• [ ] Active state clearly distinguished
• [ ] Touch targets minimum 48px tall
• [ ] Fixed position doesn't hide content

3. Tab Navigation

Mobile → Desktop Adaptation:

Mobile:

• Horizontal scrolling tabs
• Or stacked accordion

Desktop:

• All tabs visible
• No scrolling needed

Review Checklist:

• [ ] Tab overflow handled (horizontal scroll or dropdown)
• [ ] Active tab clearly indicated
• [ ] Keyboard accessible (arrow keys switch tabs)
• [ ] Touch-friendly on mobile (48px+ height)

4. Priority+ Navigation

Description: Most important items visible, overflow in "More" menu

Example:

Mobile:
[Logo  Home About  ⋮More]

Desktop:
[Logo  Home About Services Products Contact  ⋮More]

Review Checklist:

• [ ] Most important items always visible
• [ ] "More" menu contains less critical items
• [ ] Responsive prioritization algorithm
• [ ] Overflow menu keyboard accessible

5. Breadcrumb Navigation

Mobile: Collapsed or hidden Desktop: Full breadcrumb trail

Mobile Pattern:

← Back

Desktop Pattern:

Home > Products > Category > Item

Review Checklist:

• [ ] Breadcrumbs simplified on mobile (back button)
• [ ] Full trail visible on desktop
• [ ] Current page not clickable
• [ ] Truncation handled for long paths

---

Typography Patterns

Responsive Typography

Fluid Typography:

/* Base (mobile) */
body {
  font-size: 16px;
  line-height: 1.5;
}

/* Scale up for tablet */
@media (min-width: 768px) {
  body {
    font-size: 18px;
  }
}

/* Scale up for desktop */
@media (min-width: 1024px) {
  body {
    font-size: 18px;
  }
  
  h1 {
    font-size: 3rem; /* 48px */
  }
}

Responsive Type Scale:

Review Checklist:

• [ ] Base font size minimum 16px on mobile
• [ ] Type scales proportionally at breakpoints
• [ ] Line heights optimal for readability (1.4-1.6 body text)
• [ ] Line lengths optimal (45-75 characters)
• [ ] Headings sized appropriately for screen size
• [ ] Text remains readable when zoomed 200%

Line Length Management

Optimal Line Length: 45-75 characters

Strategies:

1. Max-width on containers

.content {
  max-width: 65ch; /* ~65 characters */
}

1. Multi-column on wide screens

@media (min-width: 1280px) {
  .article {
    column-count: 2;
    column-gap: 3rem;
  }
}

Review Checklist:

• [ ] Line length constrained on wide screens
• [ ] No lines longer than 100 characters
• [ ] Comfortable reading experience at all sizes

Responsive Font Loading

Strategy:

• System fonts for instant rendering
• Web fonts load progressively
• Font display: swap (show fallback immediately)

Review Checklist:

• [ ] System font stack as fallback
• [ ] Web fonts optimized (woff2 format)
• [ ] Font-display: swap used
• [ ] Limited number of font weights loaded

---

Image & Media Patterns

Responsive Images

1. Fluid Images (Basic)

img {
  max-width: 100%;
  height: auto;
}

2. Responsive Image Element

<picture>
  <source media="(min-width: 1024px)" srcset="large.jpg">
  <source media="(min-width: 768px)" srcset="medium.jpg">
  <img src="small.jpg" alt="Description">
</picture>

3. Responsive Background Images

.hero {
  background-image: url('small.jpg');
}

@media (min-width: 768px) {
  .hero {
    background-image: url('medium.jpg');
  }
}

@media (min-width: 1024px) {
  .hero {
    background-image: url('large.jpg');
  }
}

Review Checklist:

• [ ] Images scale proportionally (no distortion)
• [ ] High-resolution images served to desktop
• [ ] Smaller images served to mobile (performance)
• [ ] Images don't exceed container width
• [ ] Aspect ratios maintained
• [ ] Lazy loading implemented for below-fold images

Image Optimization

Guidelines:

• Mobile: ≤300KB per image
• Tablet: ≤500KB per image
• Desktop: ≤1MB per image

Review Checklist:

• [ ] Images compressed (WebP, optimized JPEG/PNG)
• [ ] Appropriate image formats (WebP > JPEG > PNG)
• [ ] Responsive images serve appropriate sizes
• [ ] Lazy loading for off-screen images
• [ ] Alt text provided for accessibility

Video Patterns

Mobile:

• Smaller video player
• Autoplay disabled (data concerns)
• Controls visible
• Poster image loads first

Desktop:

• Larger video player
• Autoplay acceptable (with mute)
• Enhanced controls

Review Checklist:

• [ ] Video player responsive
• [ ] Controls accessible on touch devices
• [ ] Autoplay muted (if used)
• [ ] Fallback message if video unsupported
• [ ] Captions/subtitles available

---

Touch & Interaction Patterns

Touch Target Sizing

Minimum Touch Target Size: 44x44 CSS pixels (Apple HIG, WCAG)

Guidelines:

• Buttons: 44px+ height
• Links: Adequate padding around text
• Icons: 44x44px minimum
• Form inputs: 44px+ height
• Spacing between targets: 8px minimum

Review Checklist:

• [ ] All buttons minimum 44x44px
• [ ] Form inputs minimum 44px tall
• [ ] Icon buttons minimum 44x44px
• [ ] Links have adequate padding
• [ ] Spacing prevents accidental taps
• [ ] Targets larger on mobile than desktop (if different)

Hover vs. Touch States

Desktop (Hover):

• Hover states provide feedback
• Tooltips on hover
• Dropdown menus on hover

Mobile (Touch):

• No hover states (tap to activate)
• Tooltips on tap (dismissible)
• Dropdown menus on tap

Review Checklist:

• [ ] Touch states designed (not just hover)
• [ ] Active/pressed states provide feedback
• [ ] No functionality requires hover
• [ ] Tooltips accessible on touch
• [ ] Dropdown menus tap-activated on mobile

Gestures

Common Mobile Gestures:

• Tap: Activate button/link
• Swipe: Navigate carousel, dismiss notification
• Pinch: Zoom (maps, images)
• Long press: Context menu, reorder

Review Checklist:

• [ ] Common gestures implemented (swipe, pinch)
• [ ] Gestures have visible affordances
• [ ] Gesture alternatives provided (buttons)
• [ ] Gestures don't conflict with browser gestures

Form Interaction

Mobile Forms:

• Large input fields (44px+ height)
• Appropriate keyboard types (email, tel, number)
• Minimal typing required
• Autofill supported
• Clear error messages

Review Checklist:

• [ ] Input fields large enough to tap easily
• [ ] Correct input types trigger appropriate keyboards
• [ ] Labels visible (not placeholder-only)
• [ ] Autofill attributes used
• [ ] Submit button large and prominent

---

Performance Considerations

Mobile Performance

Performance Budget:

• Page weight: ≤1MB mobile, ≤2MB desktop
• Load time: ≤3 seconds on 3G
• First Contentful Paint: ≤1.5 seconds
• Time to Interactive: ≤3.5 seconds

Review Checklist:

• [ ] Images optimized for mobile
• [ ] CSS minified and compressed
• [ ] JavaScript deferred or async
• [ ] Critical CSS inlined
• [ ] Fonts optimized (woff2, font-display: swap)
• [ ] Lazy loading for below-fold content
• [ ] Service worker for offline support (PWA)

Conditional Loading

Strategies:

• Load high-res images only on desktop
• Defer non-critical JavaScript on mobile
• Lazy load below-fold content
• Reduce animations on mobile

Review Checklist:

• [ ] Heavy resources conditionally loaded
• [ ] Mobile experience not bloated
• [ ] Critical content loads first
• [ ] Non-critical features deferred

---

Testing Responsive Designs

Device Testing

Real Device Testing:

• iPhone (various models)
• Android phones (various manufacturers)
• iPad
• Android tablets

Review Checklist:

• [ ] Tested on real iOS device
• [ ] Tested on real Android device
• [ ] Tested on tablet
• [ ] Tested on different screen sizes

Browser DevTools Testing

Chrome DevTools:

• Device toolbar (Cmd+Shift+M)
• Test all breakpoints
• Test touch events
• Test network throttling

Review Checklist:

• [ ] All breakpoints tested (320px, 768px, 1024px, 1280px)
• [ ] Portrait and landscape orientations
• [ ] Touch events simulated
• [ ] Network throttled (Slow 3G, 4G)
• [ ] Zoom tested (200%)

Responsive Testing Checklist

Layout:

• [ ] No horizontal scrolling at any viewport size
• [ ] Content adapts smoothly between breakpoints
• [ ] Max-width constraints prevent line length issues
• [ ] Columns reflow appropriately
• [ ] No content cut off or hidden

Typography:

• [ ] Text readable at all sizes (minimum 16px)
• [ ] Line lengths comfortable (45-75 characters)
• [ ] Headings scale appropriately
• [ ] Text remains readable when zoomed 200%

Navigation:

• [ ] Navigation accessible on all devices
• [ ] Mobile menu functional
• [ ] Active page indicated
• [ ] All menu items accessible

Images & Media:

• [ ] Images scale proportionally
• [ ] No distorted images
• [ ] Appropriate image sizes loaded
• [ ] Videos responsive

Forms:

• [ ] Input fields large enough (44px+)
• [ ] Labels visible
• [ ] Appropriate keyboards on mobile
• [ ] Submit button accessible

Touch Interactions:

• [ ] Touch targets minimum 44x44px
• [ ] Adequate spacing between targets
• [ ] Touch states provide feedback
• [ ] Gestures functional

Performance:

• [ ] Page loads quickly on mobile (≤3 seconds)
• [ ] Images optimized
• [ ] No layout shifts during load
• [ ] Smooth scrolling and animations

---

Responsive Design Checklist Summary

Critical (Must Fix)

• [ ] Viewport Meta Tag: Present and correct
• [ ] No Horizontal Scroll: At any viewport size (320px+)
• [ ] Touch Targets: Minimum 44x44px on mobile
• [ ] Text Readable: Minimum 16px font size on mobile
• [ ] Images Scale: Proportionally without distortion
• [ ] Navigation Functional: Accessible on all devices
• [ ] Forms Usable: Input fields large enough (44px+ height)

High Priority (Should Fix)

• [ ] Breakpoints: Consistent and content-based
• [ ] Mobile-First: Base styles optimized for mobile
• [ ] Content Priority: Most important content accessible on mobile
• [ ] Image Optimization: Appropriate sizes served to each device
• [ ] Performance: Page loads in ≤3 seconds on mobile
• [ ] Keyboard Types: Appropriate mobile keyboards triggered
• [ ] Orientations: Works in portrait and landscape

Medium Priority (Recommended)

• [ ] Fluid Typography: Text scales at breakpoints
• [ ] Line Length: Constrained on wide screens (≤75 characters)
• [ ] Lazy Loading: Below-fold images lazy loaded
• [ ] Touch States: Designed for mobile interaction
• [ ] Responsive Images: Picture element or srcset used
• [ ] Gestures: Common gestures implemented (swipe, pinch)

---

Common Responsive Design Issues

1. Fixed Width Layouts

Issue: Layout doesn't adapt, horizontal scrolling on mobile Fix: Use fluid grids with relative units (%, rem)

2. Tiny Text on Mobile

Issue: Text too small to read (< 16px) Fix: Minimum 16px font size on mobile

3. Small Touch Targets

Issue: Buttons/links too small to tap accurately (< 44px) Fix: Minimum 44x44px touch targets

4. Images Not Scaling

Issue: Images overflow containers or distort Fix: max-width: 100%; height: auto;

5. Horizontal Scrolling

Issue: Content wider than viewport Fix: Fluid layouts, avoid fixed pixel widths

6. Broken Navigation

Issue: Desktop navigation doesn't fit on mobile Fix: Hamburger menu or bottom navigation

7. Poor Performance on Mobile

Issue: Large images, unoptimized assets Fix: Responsive images, lazy loading, compression

8. Content Prioritization Issues

Issue: Important content buried on mobile Fix: Prioritize critical content, use progressive disclosure

9. Inconsistent Breakpoints

Issue: Layout breaks at unexpected sizes Fix: Test all viewport sizes, add breakpoints where needed

10. Hover-Only Interactions

Issue: Functionality requires hover (unavailable on touch) Fix: Provide tap alternatives, design for touch-first

---

Responsive Design Resources

Tools

• Chrome DevTools Device Mode
• Firefox Responsive Design Mode
• BrowserStack (cross-browser testing)
• Responsive Design Checker
• Viewport Resizer

Guidelines

• Material Design Responsive Layout
• Apple Human Interface Guidelines
• Bootstrap Responsive Breakpoints
• Tailwind CSS Breakpoints

Testing

• Real device testing (iOS, Android)
• Browser DevTools
• Network throttling
• Accessibility testing at all sizes

---

Summary

Responsive design ensures optimal user experiences across all devices. When reviewing responsive designs:

1. Test All Breakpoints: Verify designs at all viewport sizes (320px - 1920px+) 2. Mobile-First: Ensure mobile experience fully functional, not stripped-down 3. Touch-Friendly: Minimum 44x44px touch targets, adequate spacing 4. Performance: Optimize for mobile networks (≤1MB page weight, ≤3s load) 5. Content Priority: Critical content accessible on mobile without excessive scrolling 6. Fluid Layouts: Use relative units, avoid fixed pixel widths 7. Accessibility: Maintain accessibility standards at all screen sizes

A well-executed responsive design provides seamless experiences from mobile phones to large desktop displays, ensuring all users can access content comfortably regardless of device.

Severity Levels

🔴 Critical

• Definition: Issues that severely impact usability, accessibility, or brand
• Examples:
• WCAG AA violations blocking users with disabilities
• Brand guideline violations affecting brand identity
• Critical user flows broken or confusing
• Interactive elements too small to use (< 44px)
• Action Required: Must be fixed before launch

🟠 High

• Definition: Significant issues affecting user experience or consistency
• Examples:
• Navigation confusing or inconsistent
• Major design system deviations
• Responsive design breaks at important breakpoints
• Poor visual hierarchy impacting comprehension
• Action Required: Should be fixed before launch or very soon after

🟡 Medium

• Definition: Moderate issues or improvement opportunities
• Examples:
• Minor inconsistencies in spacing or typography
• Suboptimal component variants
• Missing edge case designs
• Documentation gaps
• Action Required: Address in next iteration

🟢 Low

• Definition: Polish suggestions or nice-to-have improvements
• Examples:
• Animation polish opportunities
• Additional component states
• Enhanced visual details
• Future feature suggestions
• Action Required: Track for future improvements