Thumb-First · Design

Mobile design judgment — what the right mobile pattern is and why, not how to code it. The decisions hold whether the implementation is CSS, SwiftUI, or React Native. This is the design-judgment layer of the thumb-first suite.

Quick Start

Plan a feature's mobile design: /thumb-first-design plan or "design the mobile UX for this" or "how should this work on mobile" Audit an existing mobile design: /thumb-first-design audit or "review this mobile screen" or "is this good mobile design"

This skill decides patterns and ergonomics; it does not write the implementation — for responsive CSS use responsive-craft; for mobile-web/PWA technical defects (safe areas, viewport, service workers) use its sibling thumb-first-platform; for React Native/Expo use the native-mobile skills. For a single combined pass that runs this judgment audit and the platform audit and merges them into one report, run /thumb-first.

---

Core Principles

These are the durable principles — synthesized from the people who defined the field. They survive device generations and platform churn.

1. Design for the most constrained grip (Hoober) — Grips switch every few seconds with the task. The often-quoted "49% use one hand" is not license to bury controls in easy-reach zones. Accommodate the hardest grip the user might be in, so the interface works no matter how they hold the device. In practice: keep the interaction surface — controls, nav, primary actions — in the lower band; let content fill the top, but don't put interaction there.

2. Thumb zones are a cost map, not a layout grid (Hurff) — Natural / Stretch / "Ow" tells you the cost of a location, not where things must go. High-cost zones are the right home for rare or destructive actions. Reach cost rises non-linearly with screen size — re-map it per device class.

3. Mobile forces focus (Wroblewski) — The small screen is a feature: it forces the question "what actually earns this screen?" Decide what to cut and what is primary before deciding layout. Prioritization is the design work.

4. The content is the control (Clark) — Prefer direct manipulation of content over chrome wrapped around it. But every gesture without a visible affordance is a feature only experts will discover — gesture power and discoverability trade off, and that tension never fully resolves.

5. Motion is communication, not decoration (Modern Craft) — Transitions carry state, hierarchy, and causality. Design motion with the layout, not as a final polish pass. Where something comes from and goes to is information.

6. Navigation chrome is currently unsettled — iOS 26 (Liquid Glass, floating tab bar) and Material 3 Expressive (nav drawer deprecated) are mid-transition. Treat platform navigation as in-flux; flag it, don't present a moving target as settled canon.

7. Surface decision forks — don't default silently — When a mobile design choice has multiple valid answers (nav pattern, sheet vs. modal, gesture vs. visible control), present 2-3 options with tradeoffs and let the user choose. See references/design-forks.md.

---

The Designer Lenses

This skill reasons through eight named lenses rather than a flattened checklist. Each is a real practitioner with sharp, attributable positions. Weighting is context-aware — the lenses that matter most depend on what's being designed.

Full positions, disagreements between lenses, and the weighting table are in references/designer-lenses.md. Load it at the start of both modes.

---

Mode Selection

Two modes. Detect from $ARGUMENTS or ask.

Detection

• $ARGUMENTS contains "audit", "review", "critique", "evaluate", "feedback" → Audit
• $ARGUMENTS contains "plan", "design", "build", "new", "how should" → Plan
• User points at an existing screen/component/app and asks for assessment → Audit
• User is starting a new mobile feature or unsure how it should work → Plan
• Ambiguous → Ask.

If AskUserQuestion is available:

• Plan — Design the mobile UX for a feature before any code is written
• Audit — Review an existing mobile design against best practice

Otherwise: "Do you want to (1) plan the mobile design for a new feature, or (2) audit an existing mobile design?"

If the user picks Audit but hasn't provided anything to review, ask what they're reviewing — a screenshot, a live URL, code, or a description — before routing. The audit workflow can work from any of these; it just needs one.

---

Routing

Load other references on demand:

• references/reach-and-ergonomics.md — placing actions, thumb reach, one-handed use, large screens
• references/navigation.md — choosing nav patterns; tab bar, drawer, bottom sheet, modals
• references/forms-and-input.md — any screen with form fields or data entry
• references/touch-gesture-motion.md — gestures, touch targets, transitions, haptics, feel
• references/content-and-attention.md — content prioritization, scanning, glanceability, overlays
• references/design-forks.md — when a choice has multiple valid answers
• references/output-format.md — presenting Audit findings (HTML report by default; adapt references/report-template.html)

---

Gotchas — Where Claude Fails at Mobile Design

Mobile design failures are judgment failures, not code failures. Check every recommendation against this list.

1. Defaulting to a hamburger menu because it looks "clean" — Hidden navigation has poor discoverability. A tab bar exposes destinations and consistently outperforms it. The hamburger is a last resort for genuinely deep navigation, not a default.

2. Primary action at the top of the screen — A desktop habit. The top is the hardest thumb zone on a modern phone. Primary, frequent actions belong in the easy-reach lower band.

3. Designing for the average grip — There is no average grip. Designing only for comfortable one-handed reach penalizes the ~51% who are cradling or using two hands at any moment. Accommodate the most constrained grip.

4. Treating a bottom sheet as a navigation destination — Sheets are for transient, scoped tasks with the background still relevant. They are not pages. Never stack sheets to build a flow.

5. Adding gestures with no visible affordance — A swipe action nobody can see is a feature for experts only. Every gesture needs either a well-known convention behind it or a visible cue, and ideally a non-gesture fallback.

6. Multi-column forms and placeholder-as-label — Mobile forms are single-column, always. Placeholders that vanish on focus remove the label exactly when the user needs it. Labels stay visible.

7. Treating motion as a final polish pass — Motion that's bolted on after layout can't communicate where things come from. Decide transitions alongside the layout — they carry state and causality.

8. Porting desktop information density to mobile — Cramming a desktop screen's content into a phone is not mobile design. Mobile forces a prioritization decision: what is primary, what is deferred, what is cut.

9. Designing for an unspecified "mobile" target — Asked to design "for mobile," Claude silently defaults to iOS patterns (back-swipe, sheet detents, top-bar actions) that don't translate to Android. When the platform isn't stated, name the assumption and flag what differs across iOS / Android — and note where iOS 26 / Material 3 are mid-transition rather than treating either as settled.

10. Optimizing for the showcase screen — A design that looks great in a marketing shot may fail in one-handed use, with the keyboard open, mid-interruption, or for a returning user. Design for the real, distracted, glancing context.

For the reasoning behind each and the lens that catches it, see references/designer-lenses.md and the topic references.

---

Reference Index

Workflow Index