Mobile App Design Basics: Touch Targets, Thumb Zones and Navigation

Designing for a phone is not designing a desktop screen and shrinking it. People hold phones in one hand, tap with a thumb that covers what it touches, use them on a bumpy bus or in bright sunlight, and get interrupted constantly. A layout that looks perfect in Figma at 100% zoom can be frustrating in a real hand.

This post covers the mobile app design foundations every designer needs: how big touch targets should be (with the actual numbers from Apple, Google and WCAG), where to put important actions, how to choose a navigation pattern, and the details that separate a polished app from an awkward one. The same rules apply to mobile websites.

Touch targets: the numbers that matter

A touch target is the area that responds to a tap. It can be larger than the visible icon: a 24-pixel icon can sit inside a 48-pixel tappable area. Fingers are far less precise than a mouse pointer, so small targets lead to missed taps and to tapping the wrong thing.

Points (pt) and density-independent pixels (dp) are units that scale with the screen’s pixel density, so 44 pt and 48 dp are roughly similar physical sizes on different phones. On the web, a CSS pixel behaves in a similar way.

Spacing between targets

Size alone is not enough. Two 44-point icons pressed edge to edge are still easy to mis-tap. Leave space between targets, and keep destructive actions such as Delete away from frequent ones such as Save. WCAG 2.5.8 even lets an undersized target pass if it has enough empty space around it, which shows how much spacing matters.

Thumb zones: where to put important actions

Many people use their phone with one hand, tapping with the thumb. The thumb reaches the lower and middle part of the screen easily, while the top corners, especially the one opposite the holding hand, need a stretch or a grip change. On today’s tall phones that difference is noticeable.

This is why bottom navigation bars, floating action buttons and bottom sheets have become common. A “Book now” or “Pay” button pinned to the bottom of the screen is easier to reach than one in the header. That said, people switch between one hand, two hands and resting the phone on a table, so do not treat the thumb zone as a strict map; treat it as a reason to keep the most frequent actions low and large.

Navigation patterns in mobile app design

Navigation is the skeleton of your app. Before choosing a pattern, list your top-level destinations. The information architecture lesson explains how to group content first.

Nielsen Norman Group’s research on hidden navigation found that people used navigation less, and completed tasks more slowly, when it was hidden behind a hamburger menu compared with visible or partly visible navigation. Their recommendation for mobile is to show the top-level links directly when you have about four or fewer. A bottom tab bar does exactly that.

Rules for a good tab bar

• Use an icon and a short text label for each tab. Icons alone are often ambiguous.
• Highlight the current tab clearly, not only with colour (add a filled icon, an indicator or bold text).
• Keep tabs for top-level destinations, not for actions like “Share” or “Log out”.
• Keep the tab bar in the same order on every screen where it appears.
• Make each tab’s whole area tappable, not just the icon.

A web example: a thumb-friendly bottom bar

Here is a mobile-web version of a tab bar with 48-pixel-high targets, labels under icons and padding for the phone’s safe area. Try clicking the tabs. The page also shows the measured size of each target.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1, viewport-fit=cover">
<title>Bottom navigation</title>
<style>
  body { margin: 0; font-family: system-ui, sans-serif; background: #f4f5f7; color: #1f2937; }
  main { padding: 16px 16px 96px; }
  .tabbar {
    position: fixed; left: 0; right: 0; bottom: 0;
    display: grid; grid-template-columns: repeat(4, 1fr);
    background: #fff; border-top: 1px solid #d1d5db;
    padding-bottom: env(safe-area-inset-bottom);
  }
  .tabbar button {
    min-height: 56px; border: 0; background: none; font: inherit;
    font-size: 12px; color: #4b5563; cursor: pointer;
    display: flex; flex-direction: column; align-items: center; justify-content: center; gap: 2px;
  }
  .tabbar button span { font-size: 20px; line-height: 1; }
  .tabbar button[aria-current="page"] { color: #1d4ed8; font-weight: 700; }
  .tabbar button:focus-visible { outline: 3px solid #1d4ed8; outline-offset: -3px; }
</style>
</head>
<body>
<main>
  <h1 id="title">Home</h1>
  <p>Tap a tab below. Each tab fills a quarter of the width and is at least 56px tall.</p>
  <p id="size"></p>
</main>
<nav class="tabbar" aria-label="Main">
  <button aria-current="page"><span aria-hidden="true">⌂</span>Home</button>
  <button><span aria-hidden="true">⚲</span>Search</button>
  <button><span aria-hidden="true">☰</span>Bookings</button>
  <button><span aria-hidden="true">☺</span>Profile</button>
</nav>
<script>
  const tabs = document.querySelectorAll('.tabbar button');
  tabs.forEach(tab => {
    tab.addEventListener('click', () => {
      tabs.forEach(t => t.removeAttribute('aria-current'));
      tab.setAttribute('aria-current', 'page');
      document.getElementById('title').textContent = tab.textContent.trim().slice(1);
    });
  });
  const r = tabs[0].getBoundingClientRect();
  document.getElementById('size').textContent =
    `Each tab target: ${Math.round(r.width)} x ${Math.round(r.height)} CSS pixels.`;
</script>
</body>
</html>

The viewport-fit=cover meta value and env(safe-area-inset-bottom) keep the bar above the home indicator on phones that have one. The aria-current="page" attribute tells screen-reader users which tab is selected. If you want to understand the layout, see CSS Grid and CSS position explained.

Safe areas, gestures and system UI

• Safe areas: notches, camera cut-outs, rounded corners and the home indicator take space. Keep text and controls inside the safe area. In Figma, mark these areas on your frames so you do not place buttons under them.
• System gestures: both iOS and Android use edge swipes for going back or switching apps. Avoid placing your own swipe gestures or important controls right at the screen edges.
• Status bar: keep enough contrast between your header colour and the status bar icons.

Typography, contrast and readability

• Body text around 16 px (or the platform’s default body style) is a sensible minimum on phones. Small grey text is a common readability problem.
• Support dynamic type or browser zoom: layouts must not break when the user increases the text size.
• Check colour contrast for outdoor use. WCAG asks for at least 4.5:1 for normal text. See web accessibility basics and typography for UI.
• Keep line length comfortable and avoid long, unbroken paragraphs. Mobile readers scan.

Forms on mobile

Typing on a phone is slow and error-prone, so every field you remove helps. When you do need fields:

• Use the right keyboard: on the web, type="email", type="tel" and inputmode="numeric" bring up suitable keyboards.
• Allow autofill with correct autocomplete values such as name, tel and postal-code.
• Put labels above fields so they do not get cut off on narrow screens.
• Make inputs and buttons at least 44–48 high, with enough space between them.
• Show errors next to the field, in plain language. Our UX writing guide has examples.

For the code side, read HTML Forms and HTML form best practices.

Feedback and states

On touchscreens there is no hover, so feedback must come from the tap itself. Show a pressed state immediately, show progress for anything that takes more than a moment, and confirm success. Design empty, loading and error states for every screen, not just the happy path. Avoid hiding essential information behind hover-only tooltips.

Mobile app design checklist

• Frequent targets are at least 44 pt (iOS) or 48 dp (Android); nothing on the web is below 24 × 24 CSS px without enough spacing.
• Primary actions sit in the lower, easy-to-reach part of the screen.
• Top-level navigation is visible (tab bar) if you have a handful of sections.
• Tabs have both icons and labels, and the current tab is clear without relying on colour alone.
• Content and controls respect safe areas and avoid system gesture edges.
• Text is readable at default size and still works when enlarged.
• Forms use the right input types and autocomplete.
• Every screen has loading, empty and error states.
• You have tested the design on a real phone, held in one hand, not only in Figma.

In mobile app design, the last point matters most. Figma’s mobile app lets you view prototypes on your phone; do it early and often. Then test with real users, following the steps in usability testing.

Frequently asked questions

Further reading

• developer.apple.com/design/human-interface-guidelines/accessibility
• m3.material.io/foundations/designing/structure
• support.google.com/accessibility/android/answer/7101858
• w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
• nngroup.com/articles/touch-target-size
• nngroup.com/articles/hamburger-menus