Mobile-First UI Design Covering Thumb Zones, Content Priority, and Every Interactive State

The wrong assumption is that mobile first means starting with a desktop design and squeezing it into a smaller space. The right approach is the reverse: define what matters most when the canvas is at its smallest, then add complexity as room allows. You begin by deciding what the user must see and tap first, place those controls where thumbs can reach them without a stretch, and only then build up to larger breakpoints. Data from 2024 shows that 58.67% of global web traffic runs on mobile devices, and the most common display width worldwide is 360 px. Designing from that constraint, not around it, is the difference between an interface that works and one that frustrates.

Content priority is the principle from Luke Wroblewski's 2011 book Mobile First. The core content and primary calls to action load and render before secondary elements. On a 360 px wide display, you do not have room for a hero image, a three column feature grid, a sidebar, and a footer. You have room for one decision. Identify that decision first.

Write the content hierarchy before you open Figma or write a line of CSS. The hierarchy answers one question: what does the user need to accomplish on this screen? If the answer is "book a ticket", the primary action is a button that says "Book Now" placed where the thumb can reach it. Everything else, navigation, supplementary information, branding, sits below that priority. The Material Design 3 responsive grid starts at 0 dp for the compact class, and the medium class begins at 600 dp. Between 0 and 600 dp, you have one column. That column carries the primary content, and the secondary content either collapses into a menu or loads after the primary action has rendered.

The failure case is the desktop first designer who places the primary call to action in the top right corner, then squeezes it into a mobile layout where that corner is unreachable. The reader on a 360 px wide phone must stretch their thumb across the entire panel or switch hands. The solution is to start with the content priority and place the primary action in the bottom half of the display, where the thumb rests naturally.

Thumb zone research published by Steven Hoober in 2011 and updated through 2023 shows that users hold their phones in three main grips. The one handed grip, used by 49% of people in Hoober's study, places the thumb in an arc that covers the bottom half of the display easily, the middle third with a stretch, and the top quarter with a reach that often requires a grip shift. Primary actions belong in the bottom half, secondary actions in the middle third, and tertiary actions like settings or help in the top quarter.

Thumb Friendly Interface Placement Rules

A thumb friendly interface places the most frequently used controls within the thumb's natural arc. The WCAG 2.2 Success Criterion 2.5.8, published in 2023, requires a minimum touch target of 24 x 24 CSS pixels. Apple HIG recommends 44 x 44 points on iOS. The two units are not equivalent. A 24 px target at 1x resolution is smaller than a 44 pt target, and the larger platform guideline is the safer one to follow for accessibility. Material Design 3 adds an 8 dp minimum spacing between touch targets to prevent accidental taps.

The practical rule is simple: place the primary call to action in the bottom 30% of the display, center it horizontally, and make the target at least 44 px tall. Place secondary navigation in a bottom tab bar or a hamburger menu in the top left or top right, depending on platform convention. Place tertiary actions like account settings in a menu that opens from the top bar. This placement means the user does not need to shift grip to complete the primary task.

Here is a concrete before and after. A desktop layout squeezed to mobile places a "Buy Now" button in the top right corner of a card that is 200 px tall. On a 360 px wide display, that button sits at the top of the card, requiring a thumb stretch. The same interface redesigned mobile first places the "Buy Now" button at the bottom of the card, within the thumb zone, and makes it 48 px tall to exceed both WCAG 2.2 and Apple HIG minimums.

Progressive enhancement, defined by Aaron Gustafson in 2009, means the baseline functionality works without JavaScript or advanced CSS. Enhancements layer on for capable devices. On a mobile first page, this means the content loads and is readable on a 2G network with JavaScript disabled, and the interactive features like animations, infinite scroll, and real time updates load only when the device supports them.

The CSS media query for progressive enhancement uses the min width syntax: @media (min-width: 600px) { ... }. The styles outside any media query apply to the smallest displays. This is the opposite of the desktop first approach, which uses max width queries to strip features. The mobile first method ensures that every device gets the core content, and devices with larger canvases or faster networks get the enhancements.

Content priority supports progressive enhancement directly. If you have defined the primary action and the core content first, that is what the baseline delivers. The secondary content, the animations, and the complex layouts are the enhancements that load when the network and the available space allow.

Mobile usability rests on three foundations: the viewport meta tag, safe area insets, and touch target sizing. The viewport meta tag standard is <meta name="viewport" content="width=device-width, initial-scale=1">, introduced by Apple in 2007 and still the current guidance in 2023. Without it, mobile browsers render the page at a desktop width and the user must pinch zoom to read anything. With it, the page renders at the device width, and the user sees content at a readable size.

Safe Area Insets

Apple HIG safe area defines the zone within which content must be placed to avoid the notch, the home indicator, and the rounded corners. On an iPhone 14, the safe area insets are 47 px at the top and 34 px at the bottom in portrait orientation. Content placed outside the safe area is either hidden behind the notch or obscured by the home indicator. The same principle applies on Android devices with punch hole cameras and gesture navigation bars. The safe area is not a CSS property; you implement it using the env(safe-area-inset-*) CSS environment variables.

Touch Target Sizing

The WCAG 2.2 target size minimum of 24 x 24 CSS pixels applies to all interactive elements. The 24 px minimum is a floor, not a recommendation. Platform guidelines recommend larger targets. Apple HIG says 44 x 44 points. Material Design 3 says 48 x 48 dp for touch targets. The discrepancy between CSS pixels and platform specific units means you must test on actual devices. A 24 px target on a 360 px wide display at 2x resolution is 48 device pixels, which is smaller than a 44 pt target on a 3x display. Test on the lowest resolution device in your target market.

Breakpoints are defined by content, not by device dimensions. A breakpoint set to a specific pixel width ages instantly when a new device ships at a slightly different width. The durable approach is to set breakpoints where the content breaks. The Material Design 3 layout guidelines define three breakpoint classes: compact at 0 dp, medium at 600 dp, and expanded at 840 dp. Bootstrap 5 uses five breakpoints: small at 576 px, medium at 768 px, large at 992 px, extra large at 1200 px, and extra extra large at 1400 px. Neither set is authoritative. You pick the one that fits your content.

The mobile first method means your base styles apply from 0 px upward, and your media queries add complexity at larger sizes. A common mistake is to write @media (max-width: 575px) for mobile styles, which is the desktop first approach. The correct mobile first query is @media (min-width: 576px) for the next breakpoint. The base styles at 0 px handle the smallest display, and each min width query adds columns, larger typography, or additional content.

An interface is not finished when the happy path works. The loading state, the empty state, the error state, and the offline state must each be designed for the smallest canvas. A desktop first designer might add a loading spinner in the center of the page, which on a mobile layout covers the entire display and blocks the user from doing anything else. The mobile first approach places the loading state inline, within the content area, so the user can still see the page chrome and navigation.

Loading State on a Slow Network

The loading state must account for bandwidth. A page that transfers more than 1 MB total is heavy for a mobile link. The HTTP Archive median mobile page weight in 2023 was around 2 MB, but the target for a mobile first page is under 1 MB. Use SVG for icons and simple graphics, because SVG is resolution independent and typically smaller than a raster alternative. Use WebP for photographs with a JPEG fallback. Use the srcset and sizes attributes on the <img> element to serve the correct image size for the available space.

Font loading uses font-display: swap in the @font-face declaration, which shows text in a system font stack immediately and swaps to the custom font when it loads. The system font stack uses the operating system's default typeface, which is already cached. On iOS, that is San Francisco. On Android, that is Roboto. The text is readable from the first paint, and the custom font enhances the appearance when it arrives.

Empty State on First Use

The empty state is what the user sees when there is no data yet. A blank screen with no instruction is a failure. The empty state must tell the user what to do next. On a mobile layout, that instruction must be in the thumb zone. Place a primary action button that says "Add First Item" or "Get Started" in the bottom half of the display, and a brief explanation above it. The empty state is not an error; it is an invitation.

Error State on Network Failure

The error state on network failure must account for the offline state. A user on a train passing through a tunnel loses the link. The interface should detect the offline state and show a message that does not require a server round trip. Use a service worker to cache the page shell and the error message. The error message should include a retry button in the thumb zone and an estimate of what went wrong. "No internet. Tap Retry when you are back online." is better than "Error 500. Contact support."

Keyboard Accessory View and Screen Reader Linear Order

On iOS, a keyboard accessory view provides shortcuts for form navigation. On Android, the same concept exists as an action bar above the keyboard. Design the form so that the primary action, like "Submit" or "Next", appears in that accessory view. The screen reader linear order on both platforms follows the DOM order, not the visual order. Use the tabindex attribute to control focus order, but keep it simple. A linear order that matches the visual order from top to bottom is the least surprising for screen reader users.

Consider a booking interface for a hotel. The desktop layout shows a hero image across the top, a search form in the center with date pickers and a guest count dropdown, a map below the form, and a list of available rooms at the bottom. The primary call to action is a "Book Now" button at the top right of each room card.

Squeezed to a 360 px canvas, the hero image takes up the first 200 px. The search form is below it, with the date pickers in a two column layout that is too narrow for the touch targets. The "Book Now" button is at the top right of each card, unreachable by the thumb. The user must scroll past the hero image, the search form, and the map to see the room list, and then stretch to tap the button.

The mobile first redesign starts with content priority. The primary action is booking a room. The hero image is removed on the compact layout. The search form is collapsed into a single row with a "Search" button at the bottom. The room list appears immediately below the search form, and each room card has the "Book Now" button at the bottom of the card, 48 px tall, centered in the thumb zone. The map is a progressive enhancement that loads only on the medium breakpoint at 600 dp and above. The hero image reappears on the expanded breakpoint at 840 dp. The redesign transfers less than 1 MB total, meets WCAG 2.2 target size requirements, and places every primary action within thumb reach.

File weight determines how fast the page loads on a mobile link. The target for Largest Contentful Paint is 2.5 seconds or less on a 4G network. The target for Cumulative Layout Shift is 0.1 or less. Both are Google Core Web Vitals thresholds from 2023. A page that loads a large hero image on a 360 px canvas is wasting bandwidth. The image is displayed at 360 px wide, and the user cannot see the extra pixels. Use srcset to serve a 360 px wide image on a 360 px display, a 600 px wide image on a 600 px display, and so on.

SVG icons replace raster icons for resolution independence and smaller file size. An SVG icon is typically 1 to 3 KB. A raster icon at 48 x 48 px at 2x resolution is 9 KB as a PNG. The difference adds up across an interface with 20 icons. The system font stack replaces custom fonts for body text, saving the 50 to 200 KB per font file. Use custom fonts only for headings and branding, and load them with font-display: swap.

Standard	Minimum Target Size	Minimum Spacing	Source
WCAG 2.2	24 x 24 CSS pixels	Not specified	WCAG 2.2 Success Criterion 2.5.8 (2023)
Apple HIG	44 x 44 points	Not specified	Apple Human Interface Guidelines (2023)
Material Design 3	48 x 48 dp	8 dp between targets	Material Design 3 Accessibility Guidelines (2023)

The WCAG 2.2 target size minimum of 24 x 24 CSS pixels applies to all interactive elements including links, buttons, and form controls. The exception is inline links within a paragraph, which are exempt. A 24 px target is small. On a 360 px wide display at 2x resolution, 24 px is 48 device pixels. A user with larger fingers will miss it. The platform guidelines are better targets. Use 44 px for iOS and 48 dp for Android.

Colour contrast ratios for normal text must be 4.5:1 minimum under WCAG 2.1 AA. For large text, defined as 18 pt regular or 14 pt bold, the minimum is 3:1. For UI components and graphical objects, the minimum is 3:1. These ratios are measured between foreground and background luminance using the formula (L1 + 0.05) / (L2 + 0.05). A contrast checker plugin may sample an antialiased edge pixel and report a passing ratio that is inflated by up to 1.5:1. Verify contrast visually at the actual rendering size on a real device.

The single most common failure in mobile first UI design is treating the loading state as an afterthought. A designer spends weeks on the happy path, then adds a generic spinner when the network is slow. The spinner covers the entire display, blocks the user from seeing any content, and offers no way to cancel or retry. The user on a 3G link waits 10 seconds for a spinner that could have been replaced with a skeleton screen that shows the page structure. The skeleton screen loads in the first paint, gives the user a sense of progress, and fills in the content as it arrives. Design the loading state first, not last.