Mobile UX Patterns

By the end of this lesson you will be able to choose the right navigation pattern for a mobile app, design empty and offline states, and ask for permissions at the right moment.

A design pattern is a proven solution to a common problem. Patterns help because people already know them from other apps. When your app uses a bottom navigation bar, nobody needs to learn how to move between sections. Using familiar patterns frees people to focus on their task.

Navigation patterns

Think of a busy railway station. The most used counters (tickets, enquiry, platforms) are right at the entrance with big signs. Rare services (lost and found) are listed on a board inside. Bottom navigation is the entrance; the drawer is the board.

Always pair icons with text labels in navigation. An icon alone is often ambiguous: is a bell "notifications" or "reminders"?

Tabs inside a section

Run this example. It shows top tabs for "Upcoming" and "Past" visits, built with proper tab semantics.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Segmented tabs</title>
  <style>
    body { font-family: system-ui, sans-serif; margin: 0; color: #1a1a2e; max-width: 380px; }
    header { padding: 16px; font-size: 18px; font-weight: 700; border-bottom: 1px solid #d4d4dc; }
    [role="tablist"] { display: grid; grid-template-columns: 1fr 1fr; border-bottom: 1px solid #d4d4dc; }
    [role="tab"] { min-height: 48px; border: 0; background: #fff; font-size: 15px; font-weight: 600; color: #4b5563; border-bottom: 3px solid transparent; }
    [role="tab"][aria-selected="true"] { color: #3b0d8c; border-bottom-color: #5b21b6; }
    [role="tabpanel"] { padding: 16px; }
    .item { padding: 12px 0; border-bottom: 1px solid #eee; }
  </style>
</head>
<body>
  <header>My visits</header>
  <div role="tablist" aria-label="Visits">
    <button role="tab" id="t1" aria-selected="true" aria-controls="p1" type="button">Upcoming</button>
    <button role="tab" id="t2" aria-selected="false" aria-controls="p2" tabindex="-1" type="button">Past</button>
  </div>
  <div role="tabpanel" id="p1" aria-labelledby="t1">
    <div class="item"><strong>Dr Mehta</strong><br>Thu 19 Nov · 9:00 am</div>
  </div>
  <div role="tabpanel" id="p2" aria-labelledby="t2" hidden>
    <div class="item"><strong>Dr Rao</strong><br>2 Oct · Prescription available</div>
    <div class="item"><strong>Lab test</strong><br>15 Sep · Report available</div>
  </div>
  <script>
    const tabs = [...document.querySelectorAll('[role="tab"]')];
    function select(tab) {
      tabs.forEach(t => {
        const on = t === tab;
        t.setAttribute('aria-selected', String(on));
        t.tabIndex = on ? 0 : -1;
        document.getElementById(t.getAttribute('aria-controls')).hidden = !on;
      });
      tab.focus();
    }
    tabs.forEach((tab, i) => {
      tab.addEventListener('click', () => select(tab));
      tab.addEventListener('keydown', e => {
        if (e.key === 'ArrowRight') select(tabs[(i + 1) % tabs.length]);
        if (e.key === 'ArrowLeft') select(tabs[(i - 1 + tabs.length) % tabs.length]);
      });
    });
  </script>
</body>
</html>

You should see two tabs with a purple underline on the active one. Click "Past" to switch the list. With the keyboard, Tab focuses the active tab, and the left and right arrow keys switch tabs. The ARIA roles tell screen readers this is a tab set. The accessibility course covers the full pattern in Tabs & Menus.

Bottom sheets

A bottom sheet slides up from the bottom of the screen to show options or a short task without leaving the page. It sits in the thumb zone, so it is easy to use with one hand. Use it for choices like "Share report", "Choose language" or "Cancel visit?". You built one in Prototyping in Figma.

Gestures need visible partners

Swiping, long-pressing and pinching are fast for people who know them, but they are invisible. Nobody can see that a list item can be swiped to delete. So every gesture should have a visible alternative, such as a menu button with "Delete". Gestures are shortcuts, not the only path.

Lists: pagination, load more or infinite scroll

• Infinite scroll loads more items as you reach the bottom. Good for browsing feeds. Bad when people need the footer or want to return to a position.
• Load more button gives control and works well on slow networks.
• Pagination (pages 1, 2, 3) suits search results people compare.

For a list of past visits or lab reports, a "Load more" button is usually the calmest choice.

Onboarding and permissions

Onboarding is what new users see first. Keep it short. Let people skip it. Better still, teach features at the moment they are needed, rather than in five slides before anyone has used the app.

Apps often need permissions: location, notifications, camera. Asking for all of them at launch feels pushy, and people tap "Deny". Instead:

1. Wait until the feature is needed, such as when the user taps "Find nearest clinic".
2. Explain why in your own screen first: "Allow location to show clinics near you."
3. Then show the system permission prompt.
4. If they deny, keep the app working: let them type their area instead.

Empty and offline states

An empty state is what a screen shows when there is nothing to show yet: no visits, no reports, no saved doctors. A blank screen looks broken. A good empty state explains what will appear and offers the next action.

An offline state tells people they have lost connection and what still works. In many parts of India, signal drops in lifts, trains and rural areas, so design this from day one.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <title>Empty and offline states</title>
  <style>
    body { font-family: system-ui, sans-serif; margin: 0; color: #1a1a2e; max-width: 380px; }
    .offline { display: none; background: #fef3c7; color: #78350f; padding: 10px 16px; font-size: 14px; border-bottom: 1px solid #f59e0b; }
    body.is-offline .offline { display: block; }
    .empty { text-align: center; padding: 48px 24px; }
    .empty .icon { font-size: 40px; color: #5b21b6; }
    .empty h1 { font-size: 19px; margin: 12px 0 4px; }
    .empty p { color: #4b5563; margin: 0 0 20px; }
    .cta { min-height: 48px; padding: 0 24px; border: 0; border-radius: 8px; background: #5b21b6; color: #fff; font-size: 16px; font-weight: 600; }
    body.is-offline .cta { background: #d4d4dc; color: #4b5563; }
    .toggle { margin: 16px; }
  </style>
</head>
<body>
  <div class="offline" role="status" id="banner"></div>
  <div class="empty">
    <div class="icon" aria-hidden="true">📄</div>
    <h1>No lab reports yet</h1>
    <p>When the lab uploads a report, it will appear here and we will send you an SMS.</p>
    <button class="cta" type="button" id="cta">Book a lab test</button>
  </div>
  <label class="toggle"><input type="checkbox" id="net"> Simulate offline</label>
  <script>
    document.getElementById('net').addEventListener('change', e => {
      const off = e.target.checked;
      document.body.classList.toggle('is-offline', off);
      document.getElementById('cta').disabled = off;
      document.getElementById('banner').textContent = off ? 'You are offline. Saved reports still open; booking needs a connection.' : '';
    });
  </script>
</body>
</html>

You should see a friendly empty state with an icon, a heading, an explanation and a button. Tick "Simulate offline": an amber banner explains what still works, and the booking button is disabled because it needs a network.

Platform conventions

Android and iOS differ in small but important ways: back navigation, the look of switches and date pickers, and where actions sit in the header. Google's Material Design and Apple's Human Interface Guidelines document these. If you design one app for both, keep your brand and layout the same, but respect each platform's system behaviours, such as the Android back gesture.

Common mistakes

• Icon-only navigation with no labels.
• More than five bottom navigation items.
• Permission requests at launch with no explanation.
• Blank empty states that look like errors.
• Gesture-only actions with no visible button.

Key points

• Patterns work because people already know them from other apps.
• Bottom navigation suits 3 to 5 main sections; tabs switch related views.
• Bottom sheets keep short tasks in the thumb zone.
• Every gesture needs a visible alternative.
• Ask for permissions in context, after explaining why.
• Design empty and offline states, not just the full, connected state.

<h1>No saved doctors yet</h1>
<p>Tap the heart on any doctor's profile to save them here for quick booking.</p>
<button class="cta" type="button" id="cta">Browse doctors</button>