Thumb First Design

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

Content & Attention

What goes on the screen, in what priority, and how it survives a distracted, glancing user. Lenses: Focus Forcer (Wroblewski), Empirical Skeptic (Budiu / NN/g), supported by Thumb-Zone Mapper.

Load this when deciding content layout, hierarchy, prioritization, or reviewing a cluttered screen.

---

Prioritization Is the Design Work

Wroblewski's central claim: the small screen is not a problem to solve, it is a forcing function. It makes you answer the question every screen should answer anyway — what actually earns this space?

The method: 1. List everything the screen currently shows or could show. 2. Rank ruthlessly — what is the one thing this screen is for? Then second, then third. 3. Cut, defer, or demote the rest. Defer = behind a tap, lower on scroll, or on a later screen. Cut = gone. 4. Lay out from the ranking. Layout is downstream of priority, never the other way around.

The mobile-to-desktop direction is the payoff: the priority you were forced to find on mobile is the right priority on every size. That is "mobile first" in its real sense — a prioritization discipline, not a CSS breakpoint.

Claude's failure mode: taking a desktop screen and shrinking it — every element preserved, just smaller and stacked. That is not mobile design. If nothing was cut or demoted, no prioritization decision was made.

---

How People Read on Mobile (Budiu / NN/g)

Mobile users scan more than they read. NN/g's eye-tracking identifies the patterns — design for the scan:

Consequences for layout:

• Headings and subheadings do the heavy lifting. A user who reads only the headings should still get the gist. Vague headings ("Overview," "More") waste the layer-cake scan.
• Front-load. First sentence, first words, first screen — the answer up top, detail below.
• Chunk. Short paragraphs, clear groups, generous spacing between groups. A wall of text on a phone is abandoned, not read.
• Visual distinction is a budget. If everything is bold, nothing is. Spend emphasis on the words that carry meaning.

---

Glanceability — Designing for Interrupted Attention

Mobile use is interrupted by default: walking, in line, mid-conversation, one eye on something else. The 2010 canon under-covered this because small screens were already simple. On today's large screens, glanceability is a deliberate decision.

Borrow from instrument-panel design — encode state so it's readable in the periphery, before it's read as text:

• Status as position, color, shape, size — not as a sentence the user must stop and read. A user should know the state from a glance, then read for detail only if they choose.
• One primary thing per screen. A glanceable screen has an obvious focal point. Competing focal points force a stop-and-study the interrupted user won't give.
• Survive the resumed glance. When the user looks back after a distraction, the screen should re-orient them instantly — clear title, stable layout, obvious "where am I."
• Respect peripheral readability — sufficient size and contrast for the important state; don't hide critical status in low-contrast fine print.

---

Overlay Proliferation — the Current #1 Failure (Budiu)

NN/g's recent finding: the dominant mobile UX problem today is not forms or content parity — it is too many layers. Stacked sheets, popups over modals, in-app browsers with their own chrome, banners over toasts over dialogs.

The damage: the user loses track of where they are and what dismisses what. A swipe-down means "close the sheet" in one layer and "open Control Center" in another. Accidental dismissals lose work.

Rules:

• One overlay at a time. Resolve the current layer before opening another. If a flow seems to need stacked overlays, it needs to be a sequence of screens, not a stack of layers.
• Every layer has an obvious, consistent dismissal — and not gesture-only (see touch-gesture-motion.md).
• Prefer a screen over an overlay for anything that isn't transient. Overlays are for quick, scoped, dismissible moments. A multi-step task is a flow of screens.
• Watch in-app browsers — opening web content inside the app stacks a second set of navigation chrome. Decide deliberately: in-app browser vs. hand off to the system browser.

---

States: Empty, Loading, Error

A screen is not designed until its non-ideal states are designed. These are content decisions, not edge cases.

• Empty state — never a dead end. Explain why it's empty in plain language and give the one obvious action forward ("No results — clear filters"; "No messages yet — start a conversation"). An empty screen with no path is a design omission.
• Loading state — match the indicator to the wait. Skeleton screens (content-shaped placeholders) for content loads — they set the layout expectation and feel faster. A determinate progress bar when duration is known; a spinner only when it isn't and the wait is short. Avoid layout shift when real content arrives.
• Error state — say where the error is, what happened in plain language, and how to recover. A generic "Something went wrong" with no next step is not an error state.

---

Content & Attention Review Checklist

• [ ] Was a real prioritization decision made — something cut or demoted, not just shrunk?
• [ ] Does the screen have one obvious primary focus?
• [ ] Do the headings alone convey the gist (layer-cake scan)?
• [ ] Is important information front-loaded — top of screen, start of line?
• [ ] Is content chunked with clear groups and spacing, not a wall of text?
• [ ] Is emphasis spent on meaning-carrying words, not scattered?
• [ ] Is key status glanceable — readable by position/color/shape before text?
• [ ] Is there ever more than one overlay stacked? (Defect.)
• [ ] Does every overlay have an obvious, non-gesture-only dismissal?
• [ ] Are empty / loading / error states all designed, each with a way forward?

Mobile Design Forks

Decisions where there is no single correct answer — the right choice depends on the product, the content, and the user's intent. When the skill hits one of these, it presents the options with tradeoffs and asks the user to choose. It does not default silently.

This is the core discipline of thumb-first: most mobile design failures aren't wrong answers, they're un-asked questions.

---

How to Use This File

When planning or auditing, scan for the situations below. For each fork found: 1. Name the situation and why there's genuine ambiguity. 2. Present 2-3 options with honest tradeoffs. 3. Give the signals that point toward one option. 4. Ask the user to decide. If AskUserQuestion is available, present tappable options; otherwise, describe them and ask for a choice by letter.

Present forks one or two at a time — never a wall of decisions.

---

Fork 1: Primary Navigation Pattern

Situation: the app has multiple top-level destinations and needs a navigation model.

• A — Tab bar / bottom nav. Destinations visible, thumb-reachable. Caps at ~5; can't express depth.
• B — Hamburger / drawer. Holds many destinations. Hidden → poor discoverability; Material 3 deprecated it.
• C — Content-driven (no chrome). Immersive, content is the navigation. Relies on gestures → discoverability cost.

The question: "How many genuinely top-level destinations are there, and how independent are they?"

Signals: 3-5 equal, independent sections → A. Deep hierarchy or 6+ destinations → fix the IA first, then A with a "More" tab, or B as last resort. Single-purpose immersive app (camera, reader, player) → C.

---

Fork 2: Sheet vs. Modal vs. Full-Screen vs. New Screen

Situation: a secondary task or content needs to appear over or after the current screen.

• A — Bottom sheet. Quick, scoped, dismissible. Non-modal if background stays relevant.
• B — Full-screen modal. A self-contained task the user must finish or cancel.
• C — New pushed screen. Part of the main navigation flow; the user drilled in.
• D — Inline expansion / state change. No new surface at all — the current screen changes.

The question: "Is this transient (a quick detour) or a real destination — and does the user need the background?"

Signals: brief task, background still relevant → A non-modal. Brief task, background irrelevant → A modal. Substantial self-contained task → B. Part of the content hierarchy → C. Just revealing more of what's already here → D. If it's a multi-step flow, it is never a stack of sheets — it's C or B.

---

Fork 3: Gesture vs. Visible Control

Situation: an action could be a swipe/long-press/drag, or a visible button.

• A — Gesture only. Fast, clean, uncluttered. Invisible — experts only.
• B — Visible control only. Discoverable by everyone. Adds chrome; less expressive.
• C — Both. Gesture as accelerator, visible control as the discoverable path.

The question: "Is this action primary (everyone must find it) or an accelerator (power users will seek it)?"

Signals: primary action → B or C, never A alone. Frequent action for return users → C. Secondary accelerator on a well-known convention (swipe-to-delete) → A acceptable. Novel gesture → never A alone; needs an affordance or fallback.

---

Fork 4: Primary Action Placement

Situation: a screen has one clear primary action — where does it live?

• A — Top bar (e.g. top-right "Done"/"Save"). Platform-conventional on iOS; out of easy thumb reach.
• B — Bottom-anchored button. In the Natural reach zone; costs vertical space; can overlap content/keyboard.
• C — Floating action button. Persistent, reachable, one action; can occlude content; a strong Material idiom, less so on iOS.

The question: "How often is this action used, and how much does platform convention matter here?"

Signals: frequent action → B or C (reach wins). Infrequent confirm on an iOS form where convention is strong → A is acceptable. One dominant create action → C. Action tied to a scrolling list → B as a docked bar. Destructive action → never the easy-reach primary slot (see Fork 8).

---

Fork 5: List vs. Grid vs. Carousel

Situation: a collection of items needs to be displayed.

• A — Vertical list. Best scan for text-primary items; variable density; one column.
• B — Grid. Best for visual/image-primary items of equal weight; enables visual comparison; less room for metadata.
• C — Horizontal carousel. Compact, shows a category in little vertical space; off-screen items are easily missed.

The question: "Are users scanning text/metadata, comparing images, or browsing a peripheral category?"

Signals: text and metadata matter → A. Images are the content and items are comparable (photos, products) → B. A secondary category alongside other content → C — but never put primary content in a carousel; off-screen = unseen.

---

Fork 6: Long Form — One Scroll vs. Steps vs. Sections

Situation: a form has many fields.

• A — Single long scroll. Everything visible; user sees the whole commitment; can feel endless.
• B — Stepped wizard. One group per screen; reduces per-screen load; needs a progress indicator; user can't see the whole.
• C — Accordion sections. Collapsible groups on one screen; good for edit-specific-thing; risk of missed required fields in collapsed sections.

The question: "Is this fill-once (signup, checkout) or edit-often (settings, profile)?"

Signals: fill-once with 10+ fields or natural stages → B. Fill-once and short → A. Edit-often, users touch one section at a time → C. Mixed required/optional → step through required (B), accordion the optional.

---

Fork 7: Information Density — Show All vs. Progressive Disclosure

Situation: a screen could show a lot of information.

• A — Show it all. Everything at a glance; no extra taps; risks clutter and a lost focal point.
• B — Progressive disclosure. Show the essential; reveal detail on demand; cleaner; costs a tap and risks "I didn't know that was there."

The question: "Does the user need all of this at once, or do they need the summary with detail on demand?"

Signals: monitoring/at-a-glance use (dashboard, status) → A, but with clear hierarchy and one focal point. Task-focused use → B — show what the task needs, defer the rest. Power-user tool used daily → A leans better (familiarity beats tidiness). New-user or occasional-use product → B.

---

Fork 8: Destructive & Rare Actions — Where Do They Hide?

Situation: a screen has both frequent actions and destructive/rare ones.

• A — High-cost zone. Place destructive actions in the "Ow" zone — reach friction is a safety margin.
• B — Behind a swipe or overflow menu. Out of the way until sought; relies on discoverability (fine — they're rare).
• C — Behind a confirmation step. Reachable, but a deliberate second action guards it.

The question: "How damaging is a mis-tap, and how reversible is the action?"

Signals: irreversible and damaging (delete account, wipe data) → C, and ideally also A. Reversible but annoying (archive, remove from list) → B with an undo. Rare but harmless → B. Never place a destructive action adjacent to a frequent one in the same easy-reach zone.

---

Fork 9: Onboarding the Interface

Situation: the app has patterns or gestures a new user must learn.

• A — Upfront tour. Carousel/coach-marks on first launch; users skip and forget it.
• B — Contextual reveal. Teach each thing at the moment it becomes relevant; better retention; more design work per moment.
• C — No teaching. Rely entirely on convention and affordance; only works if the design is genuinely self-evident.

The question: "Can the interface teach itself through affordances, or are there genuinely non-obvious moments?"

Signals: design uses only conventions and visible affordances → C (the goal). A few non-obvious accelerators → B. Upfront tour (A) is almost always the wrong answer — if you need one, treat it as a signal the design isn't self-evident yet.

Designer Lenses

Thumb-first reasons through eight named lenses, not a flattened checklist. Each is a real practitioner (or institution) with sharp, attributable positions. This file holds the positions, the disagreements between lenses, and the weighting table.

Why lenses, not rules: mobile design has few universal rights and many context-dependent tradeoffs. A lens carries a point of view — it tells you what that designer would push back on. Reasoning through several lenses surfaces tension a checklist would flatten.

---

How to Use This File

1. At the start of Plan or Audit mode, read this file. 2. Identify what the work is about (navigation? forms? reach? motion?). 3. Use the weighting table at the bottom to decide which 2-3 lenses lead. 4. When lenses disagree (see "Where the Lenses Disagree"), surface the disagreement to the user as a design fork — don't silently pick one. 5. Attribute. Say "Hoober's point here is…" — named reasoning is more useful and more honest than anonymous "best practice."

---

Lens 1: The Ergonomic Realist — Steven Hoober

Hoober ran street-level observational research (1,333 observations) on how people actually hold phones.

The data: 49% one-handed, 36% cradled (two hands, one touching), 15% two-handed. 75% of all interactions are thumb-driven. Portrait 90% of the time. On large phones, two-handed use rises to ~70% but interactions stay ~60% thumb-driven.

His load-bearing position — and the one most often misapplied:

"Always accommodate the most constrained grip, so people can use your interface no matter how they choose to hold their device."

The 49% one-handed figure is not permission to assume one-handed use. Grips switch "every few seconds" with the task. Design so the interface works in the hardest grip the user might be in.

What this lens catches: layouts that assume a fixed grip; primary actions placed where only a comfortable one-handed reach finds them; "mobile = on-the-go and one-handed" oversimplification.

Dated vs. durable: the exact 49/36/15 split is 2013 pre-6" data — directional, not current. The principle (design for the constrained grip) is a risk-management rule and fully durable.

---

Lens 2: The Thumb-Zone Mapper — Scott Hurff

Hurff turned grip research into a placement framework: the screen has three reach zones.

His sharp position: designers were treating big screens as scaled-up small screens. The ergonomic map is non-linear with screen size — the "Ow" zone explodes on large phones; even a "stretch" causes an unconscious grip re-anchor that slows the task and raises drop risk. Re-map per device class.

Use it as a cost map, not a grid. The zones tell you the cost of a location. Putting "Delete" in the Ow zone is correct — the cost is a feature. Putting the main CTA there is the mistake.

What this lens catches: primary actions in high-cost zones; the same layout reused across phone sizes without re-mapping; treating top-of-screen as neutral.

---

Lens 3: The Focus Forcer — Luke Wroblewski

Wroblewski's Mobile First argued the small screen is an asset, not a constraint to apologize for.

Core position: designing mobile-first "forces you to focus and enables you to innovate." The screen makes you answer "what actually earns this space?" — and that answer is the right priority on every screen. Prioritization is the design work; layout is downstream of it.

On forms (still the definitive source):

• Single column, always — no exceptions on mobile.
• Labels stay visible — top-aligned; placeholder-as-label is an anti-pattern because the label vanishes exactly when the user is entering data.
• Match input type to data type — email field → email keyboard; not doing so is an avoidable tax.
• Aggressive field reduction — for every field ask "what happens if we remove this?" Smart, adjustable defaults make users measurably faster.

What this lens catches: desktop content crammed onto a phone with no prioritization decision; multi-column forms; placeholder labels; forms that ask for more than they need.

Dated vs. durable: the 2011 "mobile is exploding" argument is now just reality. The focus principle and the form rules are structural and durable.

---

Lens 4: Direct Manipulation — Josh Clark

Clark's Tapworthy and Designing for Touch argued touch demands rethinking interaction, not shrinking desktop UI.

Core positions:

• "Buttons are a hack" — buttons are an abstraction invented for the mouse. On touch, prefer manipulating content directly: "Who needs a control when you have the content itself?" Swipe the card, flick the list.
• 44pt is the basic unit — the minimum reliably tappable target, anatomical not pixel-based. Layout and spacing should derive from it.
• Gestures are the keyboard shortcuts of touch — faster and more expressive, and invisible to the novice in exactly the same way.
• Honor physical metaphors completely — if something looks like a physical object, people will try to interact with it like one. Half-honored metaphors fail.

The discoverability tension — his most honest position: he does not resolve gesture-vs-button cleanly. Hidden gestures cost discoverability; visible buttons cost expressiveness and feel un-native. His heuristic: teach gestures contextually, at the moment of need — not in an upfront tutorial.

What this lens catches: chrome-heavy designs that wrap controls around content instead of making content interactive; gestures with no affordance; sub-44pt targets; skeuomorphic cues that don't behave as they look.

---

Lens 5: The Navigation Taxonomist — Frank Rausch

Rausch maintains the most rigorous current taxonomy of mobile navigation.

The taxonomy:

• Structural — Drill-Down, Flat (tabs), Pyramid, Hub-and-Spoke
• Overlay — High-Friction Modal (requires a decision), Low-Friction Modal (swipe-dismissible), Non-Modal (doesn't block)
• Embedded — State Change, Step-by-Step, Content-Driven

Sharp positions:

• Hamburger menus are "the tab bar's evil sibling" — poor discoverability; tab bars measurably outperform them.
• Single-action alert dialogs should usually be replaced with inline text.
• Full-screen transitions are wrong for an in-place state change.
• Standard screen-edge pan (back) should be baseline support, not an enhancement.

What this lens catches: navigation chosen by aesthetics rather than content structure; modals used where a state change belongs; flows built by stacking overlays.

---

Lens 6: The Empirical Skeptic — Raluca Budiu / NN/g

Budiu leads NN/g's mobile research — the lens that checks fashionable assumptions against evidence.

Findings that overturn older canon:

• Platform convergence is real — iOS and Android have converged enough that near-identical UIs work on both. "Design separately per platform" is largely obsolete (NN/g, 2023).
• Forms are no longer the top friction — passkeys, magic links, biometrics, autofill fixed most of it. The new dominant problem is overlay proliferation — layered sheets/popups causing accidental dismissal and disorientation — plus in-app-browser chrome conflicts.
• Scanning patterns — F-Pattern (low comprehension), Spotted (jumps to bold/links/numbers), Layer-Cake (headings only — the most effective for navigation), Commitment (full reading — needs trust/motivation). On mobile, the "marking" pattern (eyes fixed, thumb scrolls) is common — so heading/subheading structure matters more than left-edge alignment.
• Bottom sheets (2024 guidance) — the bottom of the screen is not automatically in thumb reach (grips vary). Sheets are validated for transient tasks with persistent background context — not as primary navigation, and never stacked.

What this lens catches: designs justified by trend rather than evidence; overlay-stacking; assuming bottom-of-screen = reachable; weak heading structure.

---

Lens 7: Modern Craft — Andy Allen / Sebastiaan de With / Gavin Nelson

The contemporary voices — three practitioners shipping the apps the field currently treats as benchmark mobile craft. They are distinct people with distinct authority. Invoke the one whose domain matches the work, by name — don't blur them into a generic "craft" voice.

Andy Allen — expressive feel (Not Boring Software)

Maximalist, sensory interaction. Positions:

• Minimalism is a place to visit, not to live. Allen rejects minimalism as a governing philosophy in favor of "richness and texture and fun."
• The screen subtracts; the designer adds it back. "Experiences on our phones are still trapped behind a screen, so you have to put in what's taken away" — deliberate haptic, audio, and dimensional feedback at the moments conventional design leaves silent.
• Game feedback loops belong in utility apps — challenge, reward, and response aren't only for games; a habit tracker can use them.
• Leads when: the work is about how an interaction feels — sensory feedback, haptics, motion personality, making a screen feel alive.

Sebastiaan de With — native-class craft (Halide; joined Apple's Human Interface Design team, 2026)

Restraint and native fidelity. Positions:

• Framing decides everything downstream. "We didn't say we made an app. We say we made a camera." What you decide the thing fundamentally is governs every later choice.
• The pro-tool tension: offer "ultimate control and flexibility while keeping the experience simple and accessible." Depth must never cost approachability.
• Light, native, fast — as design qualities. Responsiveness and a lightweight feel are design outcomes, not just engineering ones.
• Leads when: the work is about native-class fidelity, pro/power-tool interaction models, performance-as-design, or what the product fundamentally is.

Gavin Nelson — complexity made native (Linear Mobile; now OpenAI)

Information density on a touch surface. Positions:

• Distill, don't shrink. Mobile means "distilling complexity even further" — making desktop-scale density genuinely accessible on touch, not cramming a desktop screen onto a phone.
• The bar is "a natural extension of oneself." Good mobile design feels like something you never had to learn — pull-to-refresh and AirPods auto-pause are the standard.
• Design from a vocabulary. Nelson works from a large curated reference library and long stretches away from the screen before tooling — pattern fluency precedes execution.
• Leads when: the work is about porting complex or dense software to mobile, information architecture, or complexity reduction.

The internal tension — surface it, don't average it. Allen (maximalist, expressive) and de With (restrained, native-quiet) genuinely disagree on how much personality an interface should carry. That's a fork, not a contradiction — see "Where the Lenses Disagree."

What this lens catches: motion added last and therefore meaningless; transitions that don't say where things went; janky or slow interactions excused as "an engineering problem"; a dense desktop screen shrunk rather than re-thought; an interface with no personality where the product wants one — or a noisy one where the product wants quiet.

---

Lens 8: Platform Canon — Apple HIG / Material 3

The institutional conventions. Not a person, but a lens: "what does the platform expect, and is the platform itself currently stable here?"

Stable canon: touch-target minimums (Apple 44pt / Material 48dp, with 8dp spacing on Material); system-reserved gestures (home, back, notification/control surfaces); tab bars for 3-5 equal top-level destinations; sheet/modal/alert distinctions.

Currently unsettled — flag, don't canonize:

• iOS 26 (Liquid Glass) — floating, scroll-collapsing tab bar; a new "accessory" layer; back-swipe now works anywhere on screen. NN/g published a critical usability assessment; treat as in-transition.
• Material 3 Expressive (2025) — navigation drawer deprecated, tall nav bar replaced by a shorter "flexible navigation bar." No clean phone replacement for 5+ destinations — an acknowledged gap.

What this lens catches: cross-platform convention mixing; intercepting system-reserved gestures; presenting a mid-transition pattern as settled.

---

Where the Lenses Disagree

Real tension — surface these as design forks rather than resolving them silently.

• Hoober vs. Hurff on placement. Hurff's zones invite "put primary actions in the bottom Natural zone." Hoober cautions that ~51% aren't in the grip that makes that zone easy. Resolution: use zones as a cost map; validate against grip diversity; bottom is preferred, not guaranteed.
• Clark vs. the ergonomics lenses. Hoober/Hurff care where the control sits. Clark argues that when content is the control, the placement question partly dissolves. Resolution: both apply at different layers — interaction model first (Clark), then placement of whatever chrome remains (Hoober/Hurff).
• Allen vs. de With on expressiveness. Within Modern Craft itself: Allen argues interfaces should carry rich sensory personality; de With argues for light, quiet, native restraint. Resolution: it's a product-type fork — a utility, habit, or consumer-delight app can carry Allen's expressiveness; a pro tool, productivity, or information-dense app leans de With's and Nelson's restraint. Decide it deliberately; don't split the difference into something characterless.
• Modern Craft vs. Empirical Skeptic. The craft voices push expressive motion and novel interaction; Budiu warns novelty often fails usability testing (see iOS 26 reception). Resolution: expressive and discoverable — motion must communicate, not just decorate; novel gestures need affordances.
• "Bottom sheet everywhere" vs. NN/g. Contemporary practice over-uses sheets as navigation; NN/g restricts them to transient tasks. Resolution: sheets for scoped, dismissible tasks with relevant background — never as pages, never stacked.

---

Context-Aware Weighting Table

Which lenses lead, by what's being designed or reviewed:

For the Modern Craft lens, the arrow names which of the three sub-voices leads: Allen for feel and expressiveness, de With for native-class quality, Nelson for complexity and information density.

When in doubt, run the two lead lenses plus Budiu — the Empirical Skeptic is the cheapest guard against confident-but-wrong mobile advice.

Forms & Input

Designing and reviewing any screen that asks the user to enter data. Lens: Focus Forcer (Wroblewski), supported by Direct Manipulation (Clark) and Platform Canon.

Load this for sign-up, checkout, settings, search, profile editing, or any data-entry screen.

---

The Core Position

Wroblewski's Web Form Design and Mobile First remain the definitive source. The central idea: a form is a cost you ask the user to pay. Mobile makes that cost visible — every field is a tap, a keyboard, a moment of friction on a small screen. Design the form by removing cost, not by arranging fields.

Modern note (Budiu / NN/g): authentication friction has genuinely dropped — passkeys, biometrics, autofill, magic links. Forms are no longer the #1 mobile pain point they were in 2011. But that's because these principles got adopted — they didn't stop mattering, they became table stakes.

---

Structural Rules (durable, non-negotiable on mobile)

1. Single column. Always. No side-by-side fields on a phone — not even "City" and "ZIP." Multi-column forms break the top-to-bottom scan and the keyboard's natural advance. The only exception is genuinely paired micro-inputs that are one value (e.g., a card-expiry MM / YY), and even those are often better as one field.

2. Labels stay visible — top-aligned. The label sits above the field. Eye-tracking shows top-aligned labels let the eye capture label and field in one fixation, and — critically on mobile — they stay visible when the keyboard pushes the layout up.

3. Placeholder-as-label is an anti-pattern. A label inside the field disappears the moment the user starts typing — exactly when they need to confirm what the field is. Placeholders are for examples ("e.g. jane@work.com"), not for the label itself. (The "floating label" pattern — placeholder that animates up into a label on focus — is an acceptable compromise; a static placeholder-only field is not.)

4. Match the input type to the data. Every field declares its type so the right keyboard appears: email → email keyboard, phone → number pad, URL, numeric, decimal. A wrong keyboard is an avoidable tax paid on every entry. Pair with autocomplete/autofill hints (name, email, one-time-code, address) and the right capitalization and return-key label.

5. Reduce fields aggressively. For every field ask: "What happens if we remove this?" If the honest answer is "nothing breaks," remove it. Wroblewski's Boingo case collapsed a five-screen form to one screen this way. Ask later, ask progressively, infer from context, or don't ask at all.

6. Use smart, adjustable defaults. A pre-filled-but-editable value (detected country, today's date, the obvious option) is faster than an empty field — measurably so. Defaults are a gift only if the user can override them easily.

---

Interaction & Feedback

• Validate inline, at the right time. Validate a field when the user leaves it (not on every keystroke, not only on submit). Show success and error at the field, in plain language, with how to fix it.
• Never clear the form on error. Preserve every entered value. Re-typing a form because one field failed is a top abandonment cause.
• Keep the active field and its label visible above the keyboard. When the keyboard opens it eats ~40% of the screen. The focused field, its label, and its inline error must remain in the visible band — scroll/inset the layout so they do.
• Put the submit action where the thumb is and where the eye ends. A primary submit button at the bottom of the single column, in the Natural reach zone. For long forms, a persistent bottom-anchored submit can work — but don't let it cover the field being edited.
• Show progress for multi-step forms. If the form is a wizard, the user must always know where they are and how much is left.

---

Choosing the Input Control

Match the control to the data, and prefer the lowest-friction one that fits:

Clark's angle: prefer manipulating a value directly over wrapping a control around it. A stepper you tap, a slider you drag, a chip you toggle — these are often better than a text field plus validation. But don't sacrifice precision: a slider is wrong for a value that needs an exact number.

---

Forms Review Checklist

• [ ] Single column throughout?
• [ ] Labels visible and top-aligned (no placeholder-as-label)?
• [ ] Every field declares the correct input type / keyboard and autofill hint?
• [ ] Has every field passed the "what if we removed it?" test?
• [ ] Are there smart, editable defaults where a value can be inferred?
• [ ] Does the focused field + label + error stay visible above the keyboard?
• [ ] Is validation inline and on-blur, in plain language, with a fix?
• [ ] Is entered data preserved on error?
• [ ] Is the submit action bottom-anchored in thumb reach?
• [ ] For multi-step: is progress always visible?
• [ ] Is each input control the lowest-friction one that fits the data?

Navigation

Choosing and reviewing mobile navigation — the single richest source of decision forks in mobile design. Lenses: Navigation Taxonomist (Rausch), Platform Canon (Apple HIG / Material 3), Empirical Skeptic (Budiu).

Load this when designing or reviewing how a user moves between and within screens.

---

Rausch's Navigation Taxonomy

Pick navigation by content structure, not by aesthetics. Three families:

Structural — how top-level content is organized

Overlay — temporary content over the current screen

Embedded — navigation inside a screen

State Change, Step-by-Step (wizard), Content-Driven (the content itself is the path).

Rausch's positions: hamburger menus have poor discoverability ("the tab bar's evil sibling"); single-action alert dialogs should usually become inline text; a full-screen transition is wrong for an in-place state change; edge-swipe back should be baseline.

---

The Primary Navigation Decision

The most common fork. Options and when each wins:

Tab bar / bottom navigation

• Best for: 3-5 independent, roughly-equal top-level destinations.
• Why it wins: destinations are visible — discoverability is built in. Bottom placement is thumb-reachable. Both platforms make it the default.
• Limits: hard ceiling of ~5 items; cannot express hierarchy depth; tabs must be stable (not role- or experiment-dependent); tabs are for navigation between modes, not for actions like "Create" or "Scan."

Hamburger / drawer

• Best for: genuinely deep or sprawling navigation that can't fit 5 tabs — and even then, reluctantly.
• Why it's a last resort: hidden behind one icon → poor discoverability → measurably lower engagement with buried destinations. Material 3 Expressive has deprecated the navigation drawer.
• If you must: pair it with a tab bar for the top 3-5, and use the drawer only for the long tail.

Content-driven / no chrome

• Best for: immersive, single-purpose apps (a camera, a reader, a game) where content is the navigation.
• Cost: relies on gestures — carries the discoverability tax (see touch-gesture-motion.md).

Claude's default failure: reaching for a hamburger because it looks tidy. Visible-but-busy beats tidy-but-hidden. Start from a tab bar; justify any move away from it.

The 5+ destinations problem

If you have more than 5 top-level destinations, that is itself a finding — surface it. Options: (a) a 5th "More" tab, (b) reduce to true top-level destinations and demote the rest into sections, (c) drawer as last resort. Material 3 Expressive deprecating the drawer leaves no clean phone answer for 5+ — which is a signal the information architecture, not the nav component, needs the work.

---

Sheets vs. Modals vs. Full-Screen

Bottom sheets are the most over-used pattern in current mobile design. Decide deliberately.

The deciding question is interaction-blocking, not size: does the user need to see/use the background? Yes → non-modal. No, and they must resolve this first → modal/full-screen.

NN/g's hard rules for sheets (2024):

• Sheets are for transient tasks, not destinations. A sheet is not a page.
• Never stack sheets to build a flow — it destroys the user's model of where they are.
• Dismissal must be obvious. Swipe-down conflicts with system gestures; always also give a visible close affordance.
• "The bottom of the screen is reachable" is not guaranteed — grips vary (Hoober). Don't justify a sheet purely by reachability.

Apple's detents give sheets explicit sizes: .medium (~half screen, auxiliary tasks/quick reference) and .large (full, substantial content/input). Material's sheets have no size tiers — only the standard/modal (scrim) distinction.

---

Platform Canon — Current State (flag as in-transition)

Stable

• Tab bars: 3-5 items, both platforms, primary phone navigation.
• System-reserved gestures: bottom-edge = home/recents; top-edge = notification/control surfaces; edge-swipe = back. Apps must not intercept these.
• Back behavior: iOS = left-edge (iOS 26: anywhere-on-screen) swipe within a nav stack. Android = system Predictive Back, which shows a preview of the destination — apps must support it and must not hijack it for internal routing.

Unsettled — name it, don't canonize it

• iOS 26 (Liquid Glass): tab bar is now a floating, semi-transparent capsule that collapses on scroll; a new "accessory" layer sits above it for persistent global UI (mini-player, live status). NN/g published a critical usability review. If designing for iOS 26, treat the floating tab bar as current but contested.
• Material 3 Expressive (2025): nav drawer deprecated; the tall navigation bar replaced by a shorter "flexible navigation bar"; on larger screens, navigation rail replaces the drawer. No defined phone replacement for 5+ destinations.

Rule: when a recommendation depends on iOS-26- or M3-Expressive-era chrome, say so explicitly and note it's a moving target. Don't present a pattern in active transition as settled best practice.

---

Navigation Review Checklist

• [ ] Is the navigation pattern chosen from content structure, not aesthetics?
• [ ] Are top-level destinations visible (tabs) rather than hidden (drawer) unless depth truly forces it?
• [ ] Are there >5 top-level destinations? If so, is that flagged as an IA problem?
• [ ] Are sheets used for transient tasks only — never as pages, never stacked?
• [ ] Is every modal's blocking behavior deliberate (does the user need the background or not)?
• [ ] Do dismissal affordances not rely on gesture alone?
• [ ] Are system-reserved gestures left untouched, and platform-appropriate (iOS vs. Android back)?
• [ ] If the design leans on iOS 26 / M3 Expressive chrome, is that called out as in-transition?

Output Format

How the Audit workflow presents its findings. Two modes:

• HTML mode (default) — a self-contained .html report written to the audited project and opened in the browser. This is the richer artifact: a designer reads it, weighs the forks, and decides what to fix.
• Terminal mode (flag-triggered) — the plain-text report rendered inline. Use when the user passes --terminal, --inline, "show it inline," "skip the HTML," or any natural-language equivalent. No file is written.

Both modes carry the same audit content — only the rendering differs. Never summarize to fit a mode; the report is the deliverable.

Plan mode does not emit a report. It produces the design brief defined in workflows/plan.md.

---

HTML mode (default)

Use the template — don't reinvent it

references/report-template.html is the canonical, worked example (a fictional cooking-assistant app, "Skillet"). Read it and adapt it — replace the content, keep the structure and CSS. Do not improvise a fresh layout each run; that is exactly the inconsistency this template exists to kill. The file is self-contained: one document, all CSS inlined, fonts from a CDN with a system fallback stack (degrades gracefully offline).

Where to write it

Write to the audited project, not to a temp dir:

{project-root}/mobile-audits/{project-name}-mobile-audit.html

If the project already has a .context/, docs/, or audits/ convention, follow it. Create the directory if needed. After writing, open it in the default browser using the platform's opener (open on macOS, xdg-open on Linux, start on Windows). Tell the user the path.

Color discipline — the one rule that matters

The template keeps four color channels separate. Honor this; collapsing them is the most common way these reports turn muddy (the pre-template reports overloaded one red for "critical," "high reach cost," AND the brand color).

Sampling the adaptive accent

Pick one color from the audited product (a primary brand color from its CSS, logo, or screenshots) and set the three --accent* tokens (the template's Skillet example uses a terracotta). This is the single bespoke flourish; everything else stays fixed.

Guards:

• No product to sample (description-only audit, no visuals) → leave the template default; the report is elegant near-monochrome with only semantic color. Don't invent a brand color.
• Sampled color collides with severity red (a red/orange brand) → that's acceptable, because the accent only appears as brand chrome in different regions than severity badges. If it reads confusingly in practice, desaturate the accent (lower chroma) or sample the product's secondary color instead. Severity tokens never move.
• Keep accent chroma moderate. A neon accent on dark is the AI-slop tell the identity is built to avoid.

Dual theme (light / dark)

The report ships a pure-CSS Dark / Light toggle — a segmented pill, top-right, the first child of .wrap. Dark is the default. Every theme-dependent token has a light counterpart in the :root:has(#theme-light:checked) block (same hue, mirrored lightness), so the whole report re-tones on toggle with no JS. :has() is Baseline 2023 (all modern browsers).

• Keep the toggle markup — the two .vh radios (#theme-dark default-checked, #theme-light) plus .theme-switch__pill — as the first element inside .wrap. The sibling-combinator selectors that highlight the active label won't resolve if it moves.
• When you re-sample the adaptive accent, set it in BOTH places: the :root (dark) trio and the :root:has(#theme-light:checked) (light) trio. The light accent should be deeper (lower L) so it stays legible as chrome on the chalk surface.
• Token values are tuned for contrast in both modes — body and labels clear WCAG AA on their surface in dark and light; --faint is the floor at ~4.9:1. If you re-tune any token, keep small text ≥ 4.5:1 on its surface in both themes.
• The mini-phone, fork, and thumb-zone SVGs are self-contained dark device illustrations that read on either page surface, so they are intentionally not re-themed.

The thumb-zone diagram — keep the pattern

The diagram is the signature element and the thing most likely to break if rebuilt freehand. The template's pattern is collision-proof — do not put long text labels inside the SVG:

• Inside the phone: numbered dots only (1, 2, …), each colored by the reach zone it sits in (--reach-low/med/high). A number tolerates proximity; a text label does not.
• Beside the phone: the .key-list maps each number → action name → zone tag. This carries all the text.
• Plot dots by their real on-screen position (top = Ow, bottom = Natural). The radial #reach gradient pivots from bottom-center — the real ergonomic model of a thumb arc.
• Below the key: the three zone definitions, then a "What's off" note calling out the misplacements.

Render this section only if the audit assessed action placement across a screen. A single-component audit may not warrant it.

Modular sections — render only what the audit produced

The visual system is fixed; the sections are not. Delete any <section> the audit didn't generate, and renumber the .sec-index labels so they stay sequential. Typical mapping from workflows/audit.md Step 5:

Full-review-only sections. The template also ships two sections used only when this report is the merged output of the /thumb-first umbrella: a Fix order lead (after the header) and a Platform defects section (after the findings, on the steel --plat channel). A standalone /thumb-first-design audit deletes both — they belong to the platform pass. Leave the warm design-severity channel untouched; the steel platform channel and P0–P3 ramp are not yours to populate in a design-only run. The head comment in the template documents this.

Findings — severity tiers, no stripes

• Group findings under .tier-label dividers (Critical / Important / Polish) in impact order. Within a tier, order by impact.
• Each .finding carries data-sev="crit|imp|pol" — that drives the numeral color, and Critical gets a slightly stronger border and larger title. This is the rhythm that keeps eight findings from reading as one gray wall.
• Attribute every finding to its lens(es) via .lens-chip. Named reasoning is what makes the audit teachable.
• Each finding body is What → Why it matters → Fix. The Fix is a tinted .fix block, not a side-stripe.

Banned patterns (these reproduce the AI-slop the report is judged against)

• No `border-left`/`border-right` accent stripes > 1px on cards, findings, callouts, or fix blocks. The template uses full borders, tinted blocks, and leading numerals instead. (This was the prior reports' biggest tell.)
• No gradient text (background-clip: text + gradient).
• No pulsing / breathing / glowing elements — no looping scale/opacity pulses, no "live" indicators. The report has no entrance or scroll animation at all; the only motion is a quiet border-color transition on hover.
• No banned fonts — the template uses Schibsted Grotesk (display) / Hanken Grotesk (body) / Spline Sans Mono (labels). Keep them. Do not swap in Inter, Space Grotesk, IBM Plex, DM Sans, Instrument, etc.
• OKLCH colors, tinted neutrals, no pure black/white. The template already obeys this — keep it when editing.

Empty / edge states

• Zero Critical + zero Important → the hero stat row still renders (showing 0); replace the findings tiers with a single dimmed-italic line ("No critical or important issues — see polish and forks below."). Don't render empty tier dividers.
• Single-screen scope → omit sections 02, 03, and likely 05/06; the report is hero → lens table → findings → limits → next steps. Still complete, just shorter.

---

Terminal mode (flag-triggered fallback)

When the user opts out of HTML, render the plain-text report inline. This is the format defined in workflows/audit.md Step 5 — the lens-summary table, prioritized findings (What / Lens / Why / Fix), silent forks, and what couldn't be assessed. No file written. Same content, same ordering, same lens attribution — just no diagram and no styling.

Reach & Ergonomics

How people physically hold and touch phones, and what that means for where things go. Lenses: Ergonomic Realist (Hoober) and Thumb-Zone Mapper (Hurff).

Load this when the work involves placing actions, assessing reach, one-handed use, or large-screen layout.

---

How People Actually Hold Phones

Hoober's observational research (1,333 people, public settings):

• 75% of all interactions are thumb-driven, across every grip.
• Portrait 90% of the time.
• On large phones (6"+), two-handed use rises toward ~70% — but ~60% of interactions are still thumb-driven. The common large-phone grip: hold in one hand, tap with the other hand's index finger.

The key correction: these are population averages at a moment in time, not stable per-user states. The same person switches grips constantly — picking up a coffee, holding a rail, carrying a bag. Never design for one grip.

---

The Thumb-Zone Map (Hurff)

A right-handed thumb sweeps an arc. That arc divides the screen into three zones:

┌─────────────────────────┐
│  Ow        Stretch      │   ← top: hardest to reach
│                         │
│  Stretch      Natural   │
│                         │
│  Natural    Natural     │   ← bottom: easiest (for that grip)
└─────────────────────────┘
   (right-handed, one-handed grip)

Use it as a cost map. The zone tells you the cost of a location. A high cost is sometimes exactly what you want — "Delete Account" in the Ow zone is good design, because the reach friction is a safety margin. The mistake is putting the primary action there.

Reach is non-linear with screen size

The map is not the same shape at every size — it shifts dramatically:

• Small phones (≤4") — thumb reaches almost everything; the Ow zone is tiny.
• Standard (~6") — Ow zone establishes itself across the entire top edge.
• Large (6.7"+) — the Ow zone is startlingly large. Hurff: the sheer amount of unreachable space "becomes startlingly apparent." Users "choke up" (slide the phone down in their hand) to compensate, which de-stabilizes the grip.

Implication: don't reuse one layout across phone size classes without re-checking reach. A layout tuned on a 6.1" simulator can put primary actions out of reach on a 6.9" device.

---

Placement Rules

1. Primary action → bottom band. The most frequent, most important action goes in easy thumb reach — the lower third — not the top. A top-right "Save"/"Done"/"Post" is a desktop habit; it survives on iOS partly by convention, but a bottom-anchored primary action is more reachable. (See the fork in design-forks.md: top-bar action vs. bottom-anchored action.)

2. Destructive action → high-cost zone, or behind confirmation. Reach friction protects against mis-taps. "Delete," "Remove," "Sign out" belong in the Ow zone, behind a swipe, or behind a confirm step — never adjacent to a frequent action.

3. Don't crowd the bottom edge. The very bottom ~20pt collides with the home indicator and the system back/home gesture area. Keep tappable targets above it; respect the safe area as a design boundary, not just a technical one.

4. Reachability is preferred, not guaranteed (Hoober's caution). Because grips vary, "it's at the bottom so it's reachable" is an assumption, not a fact. For a critical action, also ensure it's reachable when cradled or two-handed — usually true if it's bottom-anchored and not jammed into a corner.

5. Top of screen is for status and identity, not action. Titles, context, read-only status — fine at the top. Frequent interaction up there fights the user's hand.

6. Mind handedness asymmetry. A bottom-right control is easy for the 67% right-thumbed and a stretch for the rest. Center-bottom or full-width bottom elements are the most grip-neutral. Reserve corners for secondary actions.

---

One-Handed Use on Large Phones

Modern flagships are 6.7"+. The 2010-era "design for one-handed" advice predates them. Current synthesis:

• One-handed use of the whole screen is no longer realistic on large phones — accept it.
• Platforms responded in-product: iOS "Reachability" (swipe-down to pull the top half down), iOS 26 moving Search to a bottom-right island, Android keyboards offering one-handed mode.
• Design response: keep the interaction surface low. Content can fill the screen (you scroll content); controls, nav, and primary actions should cluster in the lower band. The top can hold scrollable content and non-interactive chrome.
• The "Reach Navigation" argument (Brad Ellis): a top navbar on a large phone demands a ~150% thumb-length increase to reach one-handed — which is why bottom tab bars, bottom sheets, and edge gestures exist. Treat bottom-anchored navigation as the default, top navbars as the exception.

---

Quick Ergonomics Check

When placing or reviewing any interactive element, ask:

• [ ] Is the primary action in the bottom (Natural) band, reachable in the common grips?
• [ ] Are destructive actions in a high-cost zone or behind confirmation — not next to frequent ones?
• [ ] Does the layout still work for someone cradling or two-handing the phone, not just comfortable one-handed?
• [ ] Has reach been checked at the largest target device size, not just a mid-size simulator?
• [ ] Is the interaction surface kept low, with the top reserved for content and status?
• [ ] Are tappable targets clear of the home-indicator / system-gesture strip at the very bottom?

Touch, Gesture & Motion

The interaction layer — how the user touches the interface and how it moves in response. Lenses: Direct Manipulation (Clark), Modern Craft (Allen / de With / Nelson), Platform Canon.

Load this when designing gestures, touch targets, transitions, or anything about how the interface feels.

---

Touch Targets

The non-negotiable floor:

Design to 44pt minimum, 48dp preferred. Clark's framing: 44pt is "the basic unit" — derive spacing and rhythm from it, don't treat it as a constraint to squeeze under.

Visual size and touch size are separate. A 24pt icon is fine visually — its hit area must still be ≥44pt, expanded with transparent padding. The user touches the target they can't see; the icon they can see just has to be findable.

Spacing matters as much as size. Two 44pt targets jammed together still cause mis-taps. Keep ≥8dp between adjacent targets; more between a frequent action and a destructive one.

---

Gestures and the Discoverability Tension

Clark's most honest position, and the one this skill must never paper over: gestures are the keyboard shortcuts of touch. Faster and more expressive for the user who knows them — and completely invisible to the user who doesn't. This tension never fully resolves. Manage it; don't pretend it's solved.

The rule

Every gesture needs one of these, or it doesn't ship as the only path: 1. It's a near-universal convention (swipe-to-go-back, pull-to-refresh, swipe-to-delete a list row, tap, scroll) — users already have it, or 2. It has a visible affordance — a peeking element, a handle, a hint of the action underneath, or 3. It has a non-gesture fallback — the same action is also reachable via a visible control.

A novel gesture with none of the three is a feature for experts only. That's a legitimate design choice for a secondary accelerator — never for a primary action.

Teaching gestures

Don't front-load a gesture tutorial at install — users skip it and forget it. Teach at the moment of need: reveal the hint exactly when the user is in the situation the gesture serves (the canonical example: a swipe-up hint appearing the first time a video is paused). Contextual reveal beats upfront onboarding.

System-reserved gestures — hands off

Don't bind app actions to these. If an app gesture sits near a system edge, expect conflict — design the app gesture inboard, and never make an edge-conflicting gesture the only way to do something.

Swipe actions on rows — the platform convention

Leading edge → positive/neutral action (archive, mark read). Trailing edge → negative/destructive (delete). Honor the convention; reversing it surprises users. Always pair a row swipe with a non-swipe path (a tap-through detail with the same actions) — the swipe is invisible.

---

Motion as Communication

The Modern Craft lens's core position (Allen most sharply): motion is not polish applied at the end — it is how the interface communicates state, hierarchy, and causality. Design transitions with the layout.

What motion is for (the working tests)

• Origin and destination — where did this come from, where did it go? A sheet that rises from a button ties the two together. A screen that pushes in from the right says "deeper"; sliding it back says "you returned." Spatial consistency builds the user's mental map.
• Continuity — animate the change between states, don't cut. A cut forces the user to re-find everything; a transition carries their attention across.
• Causality — motion confirms "your tap did this." Immediate, direct response to touch (the element tracks the finger, reacts on contact) makes the interface feel physical and trustworthy.
• Status — loading, progress, success. Motion communicates ongoing activity more naturally than static text.

What motion is not for

Decoration. An animation that doesn't tell the user something — that exists to look lively — adds latency and noise. If you can't name what a transition communicates, cut it.

Quality bars

• Speed is a design property (de With — "light, native, fast"). Slow is a design failure, not only an engineering one. UI transitions should feel instant — roughly 200-300ms for most; long enough to follow, short enough to never wait on.
• Interruptible. A user who taps again mid-animation should be obeyed immediately. Motion must never hold the interface hostage.
• Honor the physical metaphor (Clark). If something looks grabbable, it must drag. If it looks like a card, it must move like one. A half-honored metaphor (looks physical, behaves like a static button) is worse than no metaphor.
• Respect reduced-motion. When the OS signals reduced motion, replace large positional/scale animation with a simple fade or an instant change. The information the motion carried must still arrive — just without the movement.

Haptics

Haptics are touch feedback — design them, don't leave them to defaults.

• iOS vocabulary is semantic: notification haptics (success / warning / error) and impact haptics (light → heavy). Use the named one that matches the meaning — a success haptic on a failure miscommunicates to users who rely on feel.
• Android vocabulary is intensity-based (TICK → HEAVY_CLICK); the designer maps intensity to emotional weight — lighter for confirmations, stronger for errors/rejections.
• Every haptic pairs with a visible change, and haptics lose meaning when overused. A buzz on every tap is noise; a buzz at a meaningful moment is signal.

---

Touch / Gesture / Motion Review Checklist

• [ ] Are all touch targets ≥44pt / 48dp, with hit areas expanded beyond small icons?
• [ ] Is there ≥8dp spacing between adjacent targets, more around destructive ones?
• [ ] Does every gesture have a convention, a visible affordance, or a fallback — or is it a primary action with none (a defect)?
• [ ] Are gestures taught at the moment of need, not in an upfront tutorial?
• [ ] Do any app gestures collide with system-reserved edges?
• [ ] Do row swipes follow the leading=positive / trailing=destructive convention and have a non-swipe path?
• [ ] Does each transition communicate something nameable (origin, continuity, causality, status) — or is it decoration to cut?
• [ ] Do transitions feel fast (~200-300ms) and interruptible?
• [ ] Is there a reduced-motion path that still delivers the information?
• [ ] Are haptics meaningful, semantically correct, and paired with a visible change — not constant noise?

Workflow: Audit Mobile Design

Review an existing mobile design against the eight lenses, surface the forks that were decided silently, and return prioritized findings.

Required Reading

• references/designer-lenses.md — load now; it drives the evaluation.
• Load topic references on demand per the routing table in SKILL.md.

---

Step 1: Ingest What's Being Reviewed

Determine what the user has given you:

• A screenshot or image → assess what's visible; note what you can't judge (motion, states, real reach).
• A live URL or running app → if a browser tool is available, view it at a phone viewport; otherwise work from the user's description.
• Code → read the layout/structure, but judge the design decisions, not code quality (that's other skills).
• A description → work from it; ask for a screenshot if one would materially help.

Scope it. If the user pointed at one screen or one problem ("is the nav right?"), audit that — don't sweep the whole app. If they asked for a general review, cover the main screens.

Confirm scope and platform in one line before evaluating.

---

Step 2: Establish Context

A few quick questions calibrate the audit (ask only what isn't obvious): 1. "What is this screen for — the one thing a user does here?" 2. "Who uses it, and in what situation?" 3. "Web, native, or both? Which platform should I weight?"

Without the primary purpose, you can't judge whether the design serves it — get it before evaluating.

---

Step 3: Evaluate Through the Lenses

Walk the design through the lenses. Use the weighting table in designer-lenses.md — lead with the lenses that match what the screen is mostly about, but touch all eight. Load the topic reference for each as needed.

For each lens, ask its central question:

• Ergonomic Realist — does this work across grips? Is the primary action reachable? (reach-and-ergonomics.md)
• Thumb-Zone Mapper — what's in the high-cost zones — and should it be? (reach-and-ergonomics.md)
• Focus Forcer — was a real prioritization decision made, or is this a shrunk desktop screen? Forms? (content-and-attention.md, forms-and-input.md)
• Direct Manipulation — touch targets ≥44pt? Gestures with affordances? Chrome where content could be the control? (touch-gesture-motion.md)
• Navigation Taxonomist — does the nav pattern match the content structure? Overlays used correctly? (navigation.md)
• Empirical Skeptic — anything justified by trend not evidence? Overlay stacking? Heading structure for scanning? (content-and-attention.md)
• Modern Craft — does motion communicate or is it missing/decorative (Allen)? Does it feel genuinely native (de With)? If this is a dense or complex app, was it distilled for mobile or just shrunk (Nelson)? (load touch-gesture-motion.md before judging this row — its motion quality bars are needed)
• Platform Canon — convention conflicts? System-gesture collisions? In-transition iOS 26 / M3 dependencies? (navigation.md)

When you state a finding or judgment, attribute it to the lens by name — "Hoober's concern here…", "by Rausch's taxonomy this should be…", "Allen would push for…". For Modern Craft, name the sub-voice. Named reasoning is what makes the audit teachable rather than a list of opinions.

Also scan against the Gotchas list in SKILL.md — those are the highest-frequency failures.

---

Step 4: Surface the Silent Forks

The most valuable part of the audit. For each major design choice, check references/design-forks.md: was this a genuine fork where another option might serve the user better?

For each silent fork found: 1. Name the decision the design made. 2. Show the alternative(s) and the tradeoff. 3. Give the signal for which is right for this product — or, if it depends on something only the user knows, frame it as a question.

A silently-decided fork isn't automatically wrong — but it should have been a decision. Surfacing it is the point.

---

Step 5: Present Prioritized Findings

Two output modes — see references/output-format.md for the full spec.

• HTML report (default). Adapt references/report-template.html (a self-contained, worked example), fill it with this audit's content, write it to the audited project ({project}/mobile-audits/{name}-mobile-audit.html or the project's existing convention), and open it in the browser. The template governs the visual system: keep the four color channels separate, sample one accent from the product, and build the thumb-zone diagram with the numbered-dot + key-list pattern (never freehand SVG labels). Render only the sections this audit produced.
• Terminal report (flag). If the user passes --terminal / --inline / "skip the HTML" / "show it inline," skip the file and render the plain-text format below.

Both modes carry the same content, ordering, and lens attribution.

Terminal format

MOBILE DESIGN AUDIT — [screen / feature]

Primary purpose: [the one thing]   Platform: [...]

Lens summary:
| Lens                 | Read                          |
| Ergonomic Realist    | [strong / concern / problem]  |
| Thumb-Zone Mapper    | [...]                         |
| Focus Forcer         | [...]                         |
| Direct Manipulation  | [...]                         |
| Navigation Taxonomist| [...]                         |
| Empirical Skeptic    | [...]                         |
| Modern Craft         | [...]                         |
| Platform Canon       | [...]                         |

Findings (priority order):

1. [Critical] [title]
   What: [the issue]   Lens: [which lens caught it]
   Why it matters: [user impact]
   Fix: [the design change — not the code]

2. [Important] [title]
   ...

3. [Polish] [title]
   ...

Silent forks worth revisiting:
- [decision made] → [alternative + when it'd be better] → [signal or question]

What I couldn't assess: [motion / states / real-device reach — if working from a static image]

Order findings by user impact: Critical (blocks or badly degrades the primary task) → Important (real friction) → Polish (refinement). Attribute each to its lens — that's what makes the audit teachable, not just a list.

Wait gate: present findings and stop. Ask before going further.

---

Step 6: Offer Next Steps

After the user has read the findings, offer:

• Re-plan a problem area — switch to the Plan workflow for a screen that needs rethinking.
• Hand off the fixes — name the implementation skill (responsive-craft, the sibling thumb-first-platform for web/PWA technical defects, or the RN/Expo skills). thumb-first-design identifies the design changes; it doesn't write the implementation.

---

Success Criteria

• [ ] Scope and primary purpose established before evaluating
• [ ] Design walked through all eight lenses, weighted to context
• [ ] Checked against the gotchas list
• [ ] Silent forks surfaced with alternatives and signals
• [ ] Findings prioritized by user impact and attributed to lenses
• [ ] Limits of the audit stated honestly (what couldn't be assessed)
• [ ] Next-step hand-off offered

Workflow: Plan Mobile Design

Design a feature's mobile UX before code — decide patterns, ergonomics, and content priority, then hand off a brief an implementer can build from.

Required Reading

• references/designer-lenses.md — load now; it drives every step.
• Load other references on demand per the routing table in SKILL.md.

---

Step 1: Discovery

Understand the feature before designing it. Ask 2-3 questions at a time, not a wall.

If AskUserQuestion is available, present tappable options; otherwise ask in plain text.

Round 1 — what and who: 1. "What is the feature, and what is the one thing a user comes to it to do?" 2. "Web, native (iOS/Android), or both? Any platform that matters most?" 3. "New screen(s), or a mobile version of something that exists on desktop?"

Round 2 — context (ask only what's still unknown): 4. "Who uses it, and in what situation — focused and seated, or glancing mid-task?" 5. "First-time users, returning power users, or both?" 6. "Any fixed constraints — an existing design system, brand, platform requirement?"

If the user gave a lot up front, skip questions already answered. Confirm your understanding in 2-3 lines before moving on.

---

Step 2: Prioritize Content

Before any layout, do the prioritization work (Focus Forcer lens — see references/content-and-attention.md).

1. List everything the feature could show or do. 2. Rank: what is the screen's single primary purpose? Then secondary, then the rest. 3. Decide for each lower item: keep / defer (behind a tap or lower on scroll) / cut.

Present the ranked list and the cut/defer calls — attribute the reasoning to the lens by name ("Wroblewski's point: the screen forces the question what earns this space?"). Named reasoning is the skill's value; don't present this as anonymous best practice. Wait gate: the user confirms priorities before pattern decisions — layout is downstream of this.

---

Step 3: Choose Patterns — Surface the Forks

Now decide the structure. For each major decision, check references/design-forks.md. When a decision is a genuine fork, present the options with tradeoffs and let the user choose — don't default.

Typical decisions, in rough order:

• Navigation — how the user moves between/within screens (references/navigation.md, Forks 1-2)
• Primary action — what it is and where it sits (references/reach-and-ergonomics.md, Fork 4)
• Layout of the main content — list / grid / carousel; density (Forks 5, 7)
• Forms — if there's data entry (references/forms-and-input.md, Fork 6)
• Interaction model — gestures vs. visible controls; what moves and why (references/touch-gesture-motion.md, Fork 3)
• Destructive/rare actions — where they hide (Fork 8)

Pull the relevant lens for each decision (weighting table in designer-lenses.md) and attribute the reasoning by name: "Rausch's taxonomy says…", "Hoober would push back here because…", "Allen and de With would split on this — …". For the Modern Craft lens, name the sub-voice (Allen / de With / Nelson), not just "Modern Craft."

Wait gate: present no more than two forks at once. Wait for the user's choice on each before presenting the next. Do not advance to Step 4 until every major pattern decision has been made.

---

Step 4: Pressure-Test with the Lenses

Before writing the brief, run the design through the lenses that weren't already leading — especially the Empirical Skeptic. Load references/touch-gesture-motion.md for this step regardless of the feature type — the Modern Craft check needs its motion quality bars (timing, interruptibility, reduced-motion).

• Ergonomic Realist — does it work in the constrained grips, not just comfortable one-handed?
• Empirical Skeptic — is any choice justified by trend rather than evidence? Any overlay stacking?
• Modern Craft — what moves, and what does each transition communicate (Allen)? Does it feel genuinely native (de With)? Is the personality level right for this product type — and does it match the Allen-vs-de-With call if that fork came up?
• Platform Canon — any convention conflict? Does anything depend on in-transition iOS 26 / M3 chrome?

Check the result against the Gotchas list in SKILL.md. Note anything that needs a second look.

---

Step 5: Write the Mobile Design Brief

Produce the deliverable — a brief an implementer (or another skill) can build from. Keep it tight.

MOBILE DESIGN BRIEF — [feature]

Primary purpose: [the one thing]
Platform(s): [web / iOS / Android]
User context: [who, and in what situation]

Content priority:
  1. [primary]   2. [secondary]   3. [...]
  Deferred: [...]   Cut: [...]

Structure decisions (with the fork chosen and why):
- Navigation: [choice] — [reasoning + lens]
- Primary action: [what] at [where] — [reasoning]
- Main content layout: [choice] — [reasoning]
- Forms: [approach, if any]
- Interaction model: [gestures + their affordances/fallbacks]
- Destructive/rare actions: [where + guard]

Ergonomics: [reach notes — what sits in which zone]
Motion: [key transitions and what each communicates]
States: [empty / loading / error — the plan for each]

Open questions / risks: [anything unresolved]
Platform-in-transition flags: [iOS 26 / M3 dependencies, if any]

Per the user's preference, a self-contained HTML artifact is a good format for a brief like this if the user wants something richer than markdown — offer it; otherwise markdown is fine.

Hand-off: name the implementation skill the brief should go to — responsive-craft (responsive web), thumb-first-platform (mobile-web/PWA technical), or the React Native/Expo skills (native). thumb-first-design decided the design; it does not write the implementation.

---

Success Criteria

• [ ] Feature, platform, and user context understood via discovery
• [ ] Content prioritized — something cut or deferred, confirmed by the user
• [ ] Pattern decisions made as explicit forks, user chose each
• [ ] Design pressure-tested against the non-leading lenses and the gotchas
• [ ] Mobile design brief produced, with reasoning attributed to lenses
• [ ] Hand-off to the right implementation skill named