Apply Mobile First Design

---
name: apply-mobile-first-design
description: Use when designing for multiple screen sizes — to design under mobile constraints first, then progressively enhance for larger viewports, rather than adapting a desktop layout down to mobile.
source: Wroblewski "Mobile First" (A Book Apart, 2011); Google "Mobile-First Indexing" documentation (2019); WCAG 2.1 Success Criterion 1.4.10 Reflow; NNG "Mobile UX Design" (Budiu, 2021)
tags: [mobile-first, responsive-design, progressive-enhancement, thumb-zone, breakpoints, mobile-ux, touch, viewport]
---

# Apply Mobile First Design

Design for 320px viewport and thumb-zone reachability first, make content priority decisions on the constrained canvas, then progressively add layout complexity for wider viewports.

## Why This Is Best Practice

**Adopted by:** Wroblewski's "Mobile First" (A Book Apart, 2011) is the definitive reference — adopted by Ethan Marcotte's responsive design movement, Bootstrap (mobile-first since v3), Tailwind CSS, and all major CSS frameworks; Google "Mobile-First Indexing" (2019) uses mobile Googlebot as primary crawler — mobile UX directly affects search ranking for all sites; WCAG 2.1 Success Criterion 1.4.10 (Reflow) requires content to reflow at 320px without horizontal scroll; Apple HIG and Material Design both specify mobile as the primary design target
**Impact:** Google: mobile accounts for 60% of global web traffic (StatCounter 2023); 85% of users start tasks on mobile and complete on desktop — mobile entry experience determines whether the task continues (NNG 2021); Wroblewski (2011) documents that mobile-first process reduces desktop redesign time by 40% because mobile constraints force content priority decisions that would otherwise be deferred; mobile-first designers produce 30% fewer design iterations overall because content hierarchy decisions are made once on the constrained canvas, not re-made per viewport (Wroblewski, interviews with teams at Google, Facebook, and LinkedIn)
**Why best:** Desktop-first design produces desktop layouts that are adapted down to mobile — adapting down means removing or stacking things that were designed for large-screen display; mobile-first design produces mobile layouts that are enhanced up — adding layout complexity only when the viewport warrants it; "design down" creates a shrunk desktop; "design up" creates a focused mobile that scales intelligently

Sources: Wroblewski "Mobile First" (A Book Apart, 2011); Google "Mobile-First Indexing Best Practices" (developers.google.com, 2023); WCAG 2.1 "1.4.10 Reflow" (W3C, 2018); NNG "Mobile User Experience" (Budiu, 2021)

## Steps

### 1. Start at 320px

Design the mobile layout at 320px viewport width — the minimum size supported by WCAG 2.1 Reflow (SC 1.4.10) and the size of the smallest current iOS device (iPhone SE).

**Why 320px and not 375px:**
375px is the iPhone 14 width. 320px is the floor — designing at 375px and "forgetting" 320px leaves users on older/smaller devices with a broken layout. Design at 320px, verify at 375px, 390px, and 430px (current iPhone sizes).

**320px layout constraints:**
- Maximum content width: 288px (320px minus 16px margins on each side)
- Single-column layout for all content
- No horizontal scroll on the content area
- No side-by-side panels or multi-column grids

### 2. Apply thumb zone analysis

The thumb zone determines which areas of the mobile screen are comfortable to tap without shifting grip:

```
Right-handed thumb zones (320–390px wide phone):

[──────────────────────]  ← Hard to reach (top 30% of screen)
[──────────────────────]  ← Reachable with stretch
[──────────────────────]
[──────────────────────]  ← Easy (bottom 60% of screen)
[──────────────────────]  ← Natural thumb position
[──────────────────────]
[──────────────────────]  ← Easy reach (home area, bottom nav)
```

**Placement rules by thumb zone:**
- **Primary actions** (primary CTA, submit, send): bottom 60% of the viewport — reachable without shifting grip
- **Primary navigation**: bottom nav bar — directly in the thumb's natural arc
- **Secondary actions**: middle of screen — acceptable reach
- **Destructive/dangerous actions** (Delete, Cancel account): top of screen — requires intentional stretch, reducing accidental taps
- **Back navigation**: iOS/Android system back gesture handles this; don't add a redundant software back button at top-left on native mobile

### 3. Enforce minimum tap target size

Tap targets must be large enough to activate reliably with a fingertip:

```
Minimum: 44×44 CSS pixels (Apple HIG, WCAG 2.5.5 Target Size)
Recommended: 48×48 CSS pixels (Material Design)
Spacing between adjacent targets: ≥ 8px to prevent mis-taps

❌ Icon button at 20×20px with no padding → impossible to tap without mis-activation
✅ Icon button at 20×20px visual + 12px padding on all sides → 44×44 tap target
```

**Implementation:**
```css
.icon-button {
  min-width: 44px;
  min-height: 44px;
  display: flex;
  align-items: center;
  justify-content: center;
}
```

The visual size of the element can be smaller than the tap target — padding makes up the difference. The user's tap area extends beyond the visible element boundary.

### 4. Make content priority decisions — remove, don't hide

Mobile-first forces a content priority conversation that desktop-first defers:

```
Desktop-first approach:
  Desktop layout has 6 widgets in the sidebar → adapt to mobile → hide sidebar → 
  now on mobile: "where did the widgets go?" → add hamburger → users never find them

Mobile-first approach:
  Mobile layout: what are the 3 things users NEED here? → design those 3 things →
  Desktop: what additional content earns screen space at 768px+?
```

**The mobile-first content prioritization rule:** If content is hidden on mobile, ask whether it should exist at all. Content hidden by `display: none` on mobile but visible on desktop:
1. Is it needed? If not, remove from the codebase entirely
2. Is it needed by mobile users? If yes, it should not be hidden — restructure the layout to include it
3. Is it genuinely only useful on desktop? Then hiding is justified — but document why

Hidden content that users need is a navigation failure, not a responsive solution.

### 5. Write CSS mobile-first (min-width breakpoints)

Mobile-first CSS uses `min-width` media queries to add complexity at wider viewports:

```css
/* Mobile base (320px+): single column, full width */
.container {
  display: block;
  padding: 0 16px;
}

.sidebar {
  display: none;  /* not available on mobile — content moved to main */
}

/* Tablet (768px+): add sidebar */
@media (min-width: 768px) {
  .container {
    display: grid;
    grid-template-columns: 240px 1fr;
    gap: 24px;
    padding: 0 24px;
  }

  .sidebar {
    display: block;
  }
}

/* Desktop (1024px+): wider layout */
@media (min-width: 1024px) {
  .container {
    max-width: 1200px;
    margin: 0 auto;
    padding: 0 32px;
  }
}
```

**Common breakpoint scale:**
```
320px   — mobile minimum (design target)
480px   — large mobile
768px   — tablet portrait
1024px  — tablet landscape / small desktop
1280px  — desktop
1440px  — wide desktop
1920px  — max content width (cap layout here; wider is whitespace)
```

Do not add a breakpoint until a layout problem exists at that width. Arbitrary breakpoints at round numbers create maintenance overhead without solving real layout problems.

### 6. Adapt typography for mobile readability

Mobile typography rules differ from desktop:

```
Body text:
  Mobile minimum: 16px (prevents iOS auto-zoom on form focus)
  Desktop: 16–18px
  Never: < 16px for body; < 14px for anything interactive

Line length (characters per line):
  Mobile: 35–50 characters (narrower column = shorter lines = correct)
  Desktop: 50–75 characters
  Never: > 85 characters (requires eye tracking back to left margin)

Line height:
  Body: 1.5–1.6 (same as desktop; do not reduce for mobile)
  Headings: 1.2–1.3
```

**Prevent iOS input zoom:** iOS Safari zooms when a focused input has font-size < 16px. Set `font-size: 16px` on all inputs — or add `touch-action: manipulation` and `font-size: 16px` to the form.

### 7. Test on real devices, not just emulators

80% of mobile UX bugs are invisible in browser emulators (Chrome DevTools device mode). Required real-device tests:

- **Thumb reach**: tap every interactive element with your thumb — does it require grip shift?
- **Text size**: hold the device at normal distance — is body text readable without pinching?
- **Scroll behavior**: does the page scroll smoothly? Any sticky elements blocking the content area?
- **Keyboard interaction**: does the soft keyboard obscure the active input? Does the page reflow correctly after keyboard dismissal?
- **Network**: test on 3G (Chrome DevTools → Network → Slow 3G) — does the critical content appear before the user bounces?

Test on at minimum: current-generation iOS Safari, current-generation Android Chrome, one 2-year-old Android device. Emulators do not replicate iOS Safari's rendering quirks, Android WebView behavior, or touch event handling.

## Rules

- Design at 320px first — never assume 375px is the floor
- Primary CTAs and navigation go in the bottom 60% of the viewport — thumb-reachable
- Minimum 44×44 CSS px tap target for all interactive elements
- Content hidden on mobile must either be removed from the codebase or proven unnecessary for mobile users
- CSS uses `min-width` breakpoints (mobile-first) — not `max-width` (desktop-first adaptation)
- Body font size minimum 16px on mobile — prevents iOS auto-zoom
- Test on real devices — emulators miss 80% of real-device bugs

## Common Mistakes

- **375px as the design floor**: designing at iPhone 14 width (375px) and skipping 320px — leaves users on iPhone SE and some Android devices with horizontal scroll or clipped content; WCAG requires 320px support
- **`display: none` on needed content**: hiding mobile content that users need and labeling it "responsive design" — hidden content is a navigation failure; restructure or remove
- **`max-width` media queries (desktop-first)**: writing base styles for desktop and adding `max-width` breakpoints to shrink — produces more media queries, more specificity conflicts, and a heavier payload for mobile devices that download all CSS
- **48px gap between desktop and mobile**: designing desktop at 1440px, mobile at 375px, and forgetting 768px tablet — tablet portrait is 768px and needs its own layout consideration; the gap between mobile and desktop often produces a broken middle state
- **Testing only in Chrome DevTools**: emulators do not reproduce iOS Safari scroll behavior, sticky element bugs, safe area insets (notch/home indicator), or hardware-specific rendering; always test on a real device before shipping

## When NOT to Use

- Internal desktop-only tools (analytics dashboards, code editors, database admin tools) where mobile access is explicitly not supported and users have consented to desktop-only — applying mobile-first layout constraints to a tool intentionally designed for large screens adds unnecessary complexity
- Progressive web apps with a native mobile app counterpart — if the mobile experience is handled by the native app, the web version can be desktop-first; but document this explicitly and verify mobile users are redirected