# UX Mobile > Apply medium-specific UX reasoning for MOBILE (phone) applications: touch input, small screen, one-handed use, single-surface focus. Use alongside ux-first-principles when the target is a phone app (iOS or Android) and the decision is affected by touch target sizing, the absence of hover, thumb reach, limited screen real estate, or single-task focus. USE FOR: 'design a mobile screen', 'lay out this phone app', 'what should the mobile navigation be', touch target sizing, thumb-reach layout, single-task handheld flows. DO NOT USE FOR: the invariant principles (use ux-first-principles); desktop or tablet layouts (use ux-desktop or ux-tablet); picking colors, fonts, or platform chrome (use a styling/execution skill). - Skill: `davidortinau/ux-mobile` (Agent Skill) - Install (CLI): `npx skillmds@latest add davidortinau/ux-mobile` - Raw SKILL.md: https://api.skillmd.com/api/skills/davidortinau/ux-mobile/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: davidortinau (https://skillmd.com/u/davidortinau) - Updated: 2026-09-10 - Page: https://skillmd.com/skills/davidortinau/ux-mobile --- # UX for Mobile (Phone) A thin medium layer. The reasoning lives in `ux-first-principles`; read it first or alongside. Here is only what the phone *medium* changes — driven by the body-to-device interface, not by which OS it is. ## What defines the mobile medium A coarse touch input (fingertip, not a point), a small screen held at arm's length, frequent one-handed and on-the-move use, and a single app in focus filling the screen. These change six things — and several are the mirror image of desktop. ## The six things that change 1. **Target sizing is a floor, not a budget.** A fingertip is roughly 10–14mm wide and *occludes* the thing it taps. Interactive targets must be large and well-spaced or users mis-tap. Treat a generous minimum tap target as a hard floor and add spacing between adjacent targets to prevent errors. You cannot use the dense, tiny controls that work on desktop. (The exact minimum is a platform metric — see handoff.) 2. **There is no hover.** The finger is either off the glass or committing to a tap; there is no idle-pointer state. Anything desktop would put behind hover — tooltips, reveal-on-hover controls, hover previews — **must not** carry essential information or actions on mobile. Surface it persistently, or behind an explicit tap/long-press with a visible signifier. This is the most common porting bug from desktop UI. 3. **Screen real estate is scarce — density must drop.** The same content that reads as efficient on desktop reads as cramped and overwhelming on a phone. Reduce per-screen density, shorten navigation depth, and accept more screens / more scrolling rather than packing one. Lead with the single primary task; defer the rest (progressive disclosure is heavily used here). 4. **Reach and thumb zones matter.** Held one-handed, the thumb comfortably reaches the bottom-center of the screen; the top corners are a stretch. Put primary, frequent actions in the easy bottom zone; put rare or destructive actions where they're harder to hit by accident. This consideration has no desktop analog — the cursor reaches every pixel equally. 5. **Single-surface, single-task focus.** One app, fullscreen, one task at a time. Design a focused linear flow rather than the multi-panel, multi-window layouts desktop affords. Carry context forward between screens so users don't have to remember it (Miller's Law, recognition over recall — recall is costlier on mobile because there's no room to keep things visible). 6. **Gestures replace precision and right-click.** There is no right-click and no fine pointer. Swipe, long-press, pinch, and pull are the equivalents — but they're invisible unless signified. Provide a visible button path for anything important; never make a hidden gesture the only way to reach an action. ## How principles shift on mobile - **Fitts's Law:** target size is now a usability floor; distance matters less than reachability (thumb zones). - **Hick's Law:** show fewer choices per screen than desktop — small screens make long option sets punishing. - **Progressive disclosure:** your main tool, used aggressively; lead with the common case, defer everything else to taps and subsequent screens. - **Aesthetic-Usability / Peak-End:** mobile moments are short and frequent; smooth, fast, focused flows matter more than feature breadth. ## Render-time platform handoff (NOT design decisions) Mechanical per-platform substitutions, handled in styling / at render time (e.g., by .NET MAUI), not reasoned from principles: - Exact minimum tap-target metric, system fonts, control styling, corner radii, and material/elevation conventions. - Platform navigation chrome styling and the standard system affordances. - OS-global gestures: respect the platform's system back / home / edge gestures rather than fighting or overriding them. **Everything else — including structural choices like tab bar vs. navigation drawer, bottom-sheet vs. full screen, and flow depth — is a design decision. Reason it from first principles (information architecture, Hick, hierarchy) and commit to ONE answer; both tabs and drawers are acceptable on either OS, so don't fork the structure per platform.** ## Deliberate scope note This optimizes for a coherent cross-platform product over maximal single-OS idiomaticity, which is the right trade-off for cross-platform work. It would only bite an app whose whole value proposition is feeling 100% hand-built-native on one OS.