What mobile design is and why it's different
Mobile design isn't desktop design on a smaller screen. It's design for a fundamentally different context: one-handed use on a moving train, glancing at a notification while walking, filling in a form in direct sunlight, using an app with intermittent connectivity. The constraints — small viewports, imprecise touch input, variable network conditions, constant interruption — aren't limitations to work around. They're the primary design context for most of the world's digital interactions.
More than half of global web traffic comes from mobile devices. For many markets and demographics, the phone is the only device. Designing for mobile isn't a feature you add; it's the baseline you start from. Mobile-first design means designing for the most constrained environment first and progressively enhancing for larger screens — not because mobile is more important, but because the constraints force clarity. If your information hierarchy works on a 375px screen with one thumb, it'll work anywhere.
Mobile-first vs responsive
Mobile-first is a design strategy: start with the smallest viewport, prioritize ruthlessly, then add complexity for larger screens. Responsive design is a technical approach: fluid grids, flexible images, and media queries that adapt layout to the viewport. You can build a responsive site without mobile-first thinking (desktop layout that collapses awkwardly), but the best results come from combining both — mobile-first thinking with responsive implementation.
Touch interaction fundamentals
Touch is imprecise. A fingertip covers roughly 7–10mm of screen area, and the actual contact point can deviate from the intended target by several millimeters. This has direct design implications: tap targets must be large enough, spacing between targets must prevent misfires, and interactive elements must provide clear feedback because there's no hover state to preview an action.
The dominant hand matters. Most people use their phones one-handed, and thumb reach is limited. Steven Hoober's research on mobile usage shows that 49% of people hold their phone in one hand and use their thumb, 36% cradle the phone and use their thumb, and only 15% use two hands. The thumb's natural arc creates zones of easy, stretchy, and hard-to-reach areas — the "thumb zone." Primary actions belong in the easy zone; destructive or rare actions can live in the hard zone.
The thumb zone shifts
Phone screens have grown significantly since the original thumb zone research. On modern 6.5"+ devices, the top quarter of the screen is effectively unreachable one-handed. This is why bottom navigation has become standard — it puts primary actions where thumbs naturally rest. If your app still puts the most important buttons at the top, users are literally stretching to use your product.
Tap target sizing and spacing
Tap Target Guidelines Core Method
Use when: designing any interactive element for touch screens.
Platform guidelines converge on similar minimums. Apple: 44×44pt minimum tap target. Google Material: 48×48dp minimum, with at least 8dp between targets. WCAG 2.2: 24×24 CSS pixels minimum (Level AA). The visual element can be smaller than the tap target — a 24px icon can have a 48px hit area through padding. The key is that the tappable area, not the visible element, meets the minimum. Common violations: text links in body copy (too small), icon-only buttons without padding (too close together), and close buttons on dialogs (tiny X in the corner).
Thumb-Zone Analysis Technique
Use when: deciding where to place primary actions on mobile screens.
Map your screen's interactive elements against the thumb zone. The natural zone (bottom center on the phone's dominant-hand side) is where primary actions belong — add to cart, send message, navigate tabs. The stretch zone (top corners, far edges) works for secondary actions. The oos (out of stretch) zone should only hold actions users rarely need or that benefit from being harder to reach (delete, logout). Test with actual devices — simulator testing misses the physical reality of hand position.
Gesture design
Gesture Vocabulary Framework
Use when: deciding which gestures to support and how to make them discoverable.
Universal gestures (no instruction needed): tap, scroll, pinch-to-zoom. These are so ingrained that users expect them everywhere. Learned gestures (need initial discovery): swipe to delete, pull to refresh, swipe between tabs. These are common enough that many users know them, but you should provide alternative visible controls too. Custom gestures (need explicit instruction): long-press for context menu, multi-finger swipes, shake to undo. Use sparingly — every custom gesture is a learning burden. The golden rule: gestures should accelerate actions, not be the only way to perform them. Every gesture needs a visible alternative for discoverability and accessibility.
Gesture conflicts
Horizontal swipe in a vertically-scrolling list is a common gesture conflict — the system can't tell if the user intended to swipe the list item or scroll slightly diagonally. Swipe-to-delete conflicts with swipe navigation between screens. Pull-to-refresh conflicts with overscroll behavior in web views. Map all gestures in your app to identify conflicts, and test on actual devices — these issues rarely surface in prototyping tools.
Responsive layout strategies
Breakpoint Strategy Core Method
Use when: defining how your layout adapts across viewport widths.
Common breakpoints: 320–480px (small phones), 481–768px (large phones, small tablets), 769–1024px (tablets, small laptops), 1025–1440px (desktops), 1441px+ (large screens). But don't design for breakpoints — design for content. Add a breakpoint when the content breaks, not at arbitrary device widths. A single-column layout might work until 600px, where a two-column layout becomes possible; that's your breakpoint, regardless of which device happens to be 600px wide.
Layout Patterns Framework
Use when: choosing how elements reflow across screen sizes.
Mostly fluid: Multi-column layout that stacks to single column on small screens. Most common pattern. Works well for content-heavy pages. Column drop: Columns drop below each other as the viewport narrows — sidebar drops below main content, then secondary sidebar drops below that. Layout shifter: Different layouts at different breakpoints — not just reflowing, but fundamentally reorganizing. Most flexible but hardest to maintain. Off-canvas: Content slides in from off-screen (navigation drawers, side panels). Preserves screen real estate on mobile. Tiny tweaks: Single-column layout that adjusts font size, spacing, and image size but doesn't fundamentally change structure.
Mobile form design
Mobile Form Optimization Core Method
Use when: designing any form for mobile completion.
Mobile forms have unique constraints: the virtual keyboard covers half the screen, typing is slower and more error-prone, and users often complete forms in distracting environments. Design accordingly:
- Minimize fields — every field you remove increases completion rate. Ask only what you need right now, not what might be useful later.
- Use the right keyboard — type="email" for email (shows @), type="tel" for phone (shows numpad), inputmode="numeric" for numbers.
- Single-column layout — side-by-side fields on mobile cause tab-order confusion and hit-area problems.
- Top-aligned labels — they don't get hidden by the keyboard.
- Autofill and autocomplete — leverage the browser's autofill by using standard field names (name, email, tel, address-line1).
The keyboard shift problem
When the virtual keyboard appears, it pushes content up or covers it. The field the user is typing in should always be visible above the keyboard. Test this explicitly — many mobile forms break because the active field scrolls behind the keyboard, or a fixed footer covers the submit button. iOS and Android handle this differently, and web apps handle it worse than native apps. Use scroll-into-view behavior and avoid fixed-position elements at the bottom of form screens.
Performance and perceived speed
Mobile Performance Budget Technique
Use when: setting performance targets for mobile experiences.
Mobile users are often on slower connections than desktop users, and mobile processors are less powerful. A performance budget sets limits: Total page weight under 500KB for initial load (many mobile pages exceed 3MB). Time to interactive under 3 seconds on a mid-range device with 3G. First contentful paint under 1.5 seconds. These aren't aspirational — Google's research shows 53% of mobile users abandon sites that take longer than 3 seconds to load. Design impacts performance: large hero images, web fonts, third-party scripts, and unoptimized animations all cost time.
Skeleton Screens and Progressive Loading Technique
Use when: content takes noticeable time to load.
Skeleton screens show the page structure (grey boxes where content will appear) before content loads. They feel faster than spinners because they set expectations about what's coming and make the page feel like it's already partially loaded. Progressive loading takes this further: load and display content in priority order. Show text before images. Show above-the-fold content before below-the-fold. Show cached content immediately while fetching fresh data in the background. The goal is perceived speed — the user should feel like the app responded instantly, even if loading continues for seconds.
Platform conventions: iOS vs Android
Cross-Platform Pattern Comparison Framework
Use when: designing for both iOS and Android and deciding what to standardize vs. adapt.
iOS and Android have meaningful interaction differences. Navigation: iOS uses edge swipe to go back; Android has a system back button/gesture. Action placement: iOS puts primary actions at the top-right of the navigation bar; Material Design uses floating action buttons. Selection: iOS uses swipe-to-reveal actions; Material uses long-press. Typography: iOS defaults to San Francisco; Android uses Roboto. Alerts: iOS action sheets slide up from the bottom; Android uses centered dialogs. The pragmatic approach: use platform-native patterns for system-level interactions (navigation, selection, alerts) and your own consistent patterns for app-specific interactions (onboarding, custom controls, brand moments).
The "design once" trap
Identical designs across platforms save design time but cost user trust. Android users expect a floating action button for the primary action; iOS users expect a top-right bar button. Ignoring these conventions makes your app feel foreign on one or both platforms. You don't need separate designs for everything — but navigation, system dialogs, and primary action placement should respect platform conventions. If using a cross-platform framework (Flutter, React Native), budget design time for platform-specific adjustments.
Offline and intermittent connectivity
Offline-First Design Technique
Use when: users may have unreliable network connections (transit, rural areas, travel).
Offline-first design assumes the network is unreliable and designs the experience around that assumption. Cache aggressively: Store previously viewed content locally so users can access it without a connection. Queue actions: Let users compose messages, fill forms, and take actions offline, then sync when connectivity returns. Communicate state: Show clear indicators when offline, syncing, or fully connected — but don't block the entire app. Resolve conflicts: When offline edits conflict with server data, provide clear resolution options rather than silently overwriting. The worst offline experience is a blank screen with "No internet connection." The best is an app that feels like it's always working.
Templates and checklists
- All tap targets are at least 44×44pt (iOS) or 48×48dp (Android)
- At least 8dp spacing between adjacent tap targets
- Primary actions are within thumb reach (bottom half of screen)
- Forms use appropriate keyboard types (email, tel, numeric)
- Content is readable without zooming (minimum 16px body text)
- No horizontal scrolling on any viewport width
- Images are optimized and lazy-loaded below the fold
- Page loads in under 3 seconds on 3G mid-range device
- Skeleton screens or loading states for all asynchronous content
- Offline state is handled gracefully (no blank screens)
- Platform conventions respected for navigation and system interactions
- Touch gestures have visible alternative controls
[Name of the screen being audited]
[320px / 375px / 414px / 768px / 1024px / 1440px]
[What content is most important on mobile? Does the layout reflect that?]
[Breakpoint + description: e.g., "At 375px, CTA button overlaps price text"]
Real-world examples
Case study
Google Maps: mobile-native interaction design
Google Maps demonstrates how to design for mobile context rather than shrinking a desktop interface. The bottom sheet pattern — a panel that users can swipe up for more detail or swipe down to dismiss — solves the fundamental mobile problem of limited vertical space without hiding content behind navigation taps. The map remains visible and interactive while details appear on top. Search uses the full-screen keyboard with recent and suggested searches. Directions put the most common action (driving) as the default, with alternatives one tap away. Every element respects thumb-zone placement.
Why it works: The interface was designed around mobile gestures and constraints from the beginning, not adapted from desktop. The bottom sheet has become a platform-level pattern that other apps adopt.
Case study
Spotify: offline-first content strategy
Spotify's offline mode lets users download playlists, albums, and podcasts for listening without a connection. What makes it effective isn't just the download feature — it's the design around it. Downloaded content is clearly marked. The app gracefully degrades when offline: you can browse your library, play downloaded content, and queue songs. Features that require connectivity (search, discover, social) show clear but non-blocking offline indicators. When connectivity returns, play counts and preferences sync seamlessly. The experience never feels broken.
Why it works: The app treats offline as a normal state, not an error state. Users can plan ahead (download before a flight) and the app communicates what will and won't work without connectivity.
Case study
Instagram: progressive loading and perceived speed
Instagram loads a low-resolution placeholder image instantly, then progressively loads the full-resolution version. The user sees content immediately — there's never a blank screen or spinning loader for the main feed. Combined with aggressive prefetching (loading images likely to be scrolled to), the feed feels instantaneously fast even on slow connections. The approach extends to stories: the next story preloads while you're watching the current one, so transitions feel instant.
Why it works: Perceived speed matters more than actual speed. By showing something immediately and improving it progressively, Instagram eliminates the waiting experience that causes abandonment.
Common pitfalls
Designing on desktop, testing on desktop
Responsive browser emulators simulate viewport size but not touch interaction, thumb reach, sunlight readability, or the feel of holding a device. Designs that look fine in Chrome DevTools break on actual phones. Test on real devices, in real contexts — hold the phone in one hand, walk while using it, try it in bright sunlight.
Hiding everything in hamburger menus
When everything is hidden, nothing is discoverable. The hamburger menu should be a supplement to visible navigation, not a replacement. If your most important features are behind a hamburger, your users may never find them. Data consistently shows that visible navigation increases engagement with features.
Ignoring landscape orientation
Users rotate their phones. Video playback, photo viewing, and form filling often happen in landscape. If your layout breaks or becomes unusable in landscape, you've created a frustrating experience. At minimum, test that content is accessible in both orientations — even if you don't optimize a landscape-specific layout.
Fat-finger misfires near destructive actions
Placing "Delete" next to "Edit," or "Cancel" next to "Submit," creates misfires on touch screens. Destructive actions need confirmation dialogs, physical distance from safe actions, or undo capability. A user accidentally deleting a draft email because "Delete" was 8 pixels from "Send" is a design failure, not a user error.