Skip to main content Scroll Top

Mobile UX: a website must work for a thumb, not just fit a smaller screen

Good mobile UX is not desktop squeezed into a narrow screen; it is a path designed for thumbs, interruptions and real conditions.

Ruka upravlja zelenim mobilnim sučeljem s velikim zlatnim dodirnim elementima u dosegu palca.

7 min read

A mobile website can pass a technical responsive check and still be exhausting to use. Text fits the screen, but controls are tiny. Navigation works, but hides the most important action. The form is shorter than desktop, yet opens the wrong keyboard and deletes input after an error.

Mobile UX is therefore not about shrinking a desktop design. It is about deciding what users need first, what can wait and how they can complete a task one-handed, on a weaker connection and while being interrupted.

Start with the task users came to complete

Define the primary mobile task: find information, compare a service, send an enquiry, buy a product, locate a store or check an order. The first screen does not need every desktop component in the same order. It needs a clear next step.

Review journeys by device: where mobile users abandon, go back, zoom or reopen the same step. A conversion-rate difference alone does not prove bad UX because usage context may differ, but it is a strong research signal.

Responsive means more than a few breakpoints

A robust layout responds to available space, content and device capabilities. web.dev notes that pages without a correct viewport meta tag can load zoomed out and make text difficult to read, and recommends layouts that adapt rather than depend on fixed dimensions [1].

WCAG 2.2 requires content at a width equivalent to 320 CSS pixels to remain available without loss of information or functionality and without two-dimensional scrolling, except where a two-dimensional layout is essential [2].

In practice, use one clear main column, responsive media, intentional table behavior and components that survive text enlargement. Do not remove important information simply because it is harder to place.

A touch target must be larger than its icon

People do not tap with a cursor tip. WCAG 2.5.8 sets a minimum target of 24 × 24 CSS pixels or sufficient spacing around smaller targets [3]. That is an accessibility floor, not the ideal for every primary button.

Apple recommends hit targets of at least 44 × 44 points [4]. Android recommends at least 48 × 48 dp and explains that a visible icon may remain smaller when padding expands its interactive area [5].

Check modal close buttons, baskets, quantity controls, slider arrows, checkboxes, footer links and filter controls. Adjacent targets must not turn an imprecise tap into the wrong action.

Design for thumbs and changing grips

Place common actions within comfortable reach, but do not assume one universal thumb zone. Device size, dominant hand and context change reach. Important controls should not require precise stretching, while destructive actions should not sit next to the primary CTA.

Fixed bottom navigation helps when it contains a few clear destinations. It fails when it covers content, conflicts with a cookie banner or consumes too much vertical space. A sticky CTA should disappear or change state when it is no longer relevant.

Text must remain readable without pinch-zoom

Readability includes contrast, line spacing, line length, hierarchy and whitespace. A four-line heading that pushes useful content away can be as unhelpful as tiny text.

Do not disable zoom. Content must reflow when enlarged without losing functionality. Accordions may reduce page length, but headings must explain what is inside, and key information must remain available to search engines and assistive technology.

Mobile forms should require less work

Ask only for data needed for the next business step. Every field needs a persistent label, an example when useful and an error explaining how to fix the problem. A placeholder is not a label.

Use the appropriate field type, inputmode and autocomplete. The GOV.UK Design System recommends autocomplete to help people complete forms faster, combined with a clear label and hint when a particular format is required [6].

On a phone, verify that the correct keyboard opens, password managers work, data survives validation errors, errors appear near the field and the keyboard does not hide the active control or submit button.

Responsive feedback is part of usability

After a tap, show that something happened: the button changes state, the basket confirms an addition, the menu opens or a loading indicator appears. Without feedback, people repeat the action and may submit a form or add an item twice.

Interaction to Next Paint measures page responsiveness to user interactions. web.dev defines 200 ms or less at the 75th percentile as good responsiveness, evaluated separately for mobile and desktop visits [7]. The metric is not the whole experience, but a slow interface directly obstructs use.

Mobile must not be the content-poor version

Google uses the mobile version for indexing and ranking. It recommends responsive design and equivalent primary content, headings, metadata, structured data and image alt text across mobile and desktop [8].

You can move content into tabs or accordions, but do not remove service details, terms, delivery information, reviews or other evidence users need to decide.

Test on a device, not only in a narrow window

An emulator is useful but incomplete. Test at least one smaller and one larger phone, iOS and Android when relevant, portrait and landscape, slower networking, enlarged text and a real on-screen keyboard.

Complete the entire task from entry to confirmation. Check back navigation, rotation, reload, an interruption by a call and resuming a form. Analytics shows where a problem occurs; observing users helps explain why.

Mobile UX checklist

  • the primary task is immediately visible
  • ordinary content does not require horizontal scrolling
  • text remains readable when enlarged
  • touch targets are large and well spaced
  • navigation and sticky elements do not cover content
  • forms use labels, autocomplete and an appropriate keyboard
  • errors do not delete entered data
  • every action receives immediate visual feedback
  • mobile content and SEO data are equivalent to desktop
  • the key journey has been tested on real devices

Mobile UX succeeds when people do not have to think about the interface. They can read, tap, correct an error and finish without mouse-level precision, a perfect connection or uninterrupted attention.

Frequently asked questions

Is responsive design the same as good mobile UX?

No. Responsive design adapts layout; mobile UX also covers priorities, touch, readability, forms, speed and the complete journey.

How large should mobile buttons be?

WCAG sets 24 × 24 CSS px or sufficient spacing as a minimum, while Apple recommends 44 pt and Android 48 dp.

Should mobile have less content?

Not necessarily. Content can be arranged differently, but primary information and SEO elements should remain equivalent to desktop.

How do you simplify a mobile form?

Ask only for necessary data and use persistent labels, autocomplete, the right inputmode and clear errors that preserve input.

Is browser emulation enough?

No. Real devices expose issues with keyboards, grip, browsers, networks, zoom and interruptions.

Sources

Sources last checked: 30 October 2026.

  1. web.dev — Responsive web design basics
  2. W3C WAI — Understanding Reflow
  3. W3C WAI — Understanding Target Size (Minimum)
  4. Apple Developer — UI Design Dos and Don’ts
  5. Android Developers — Make apps more accessible
  6. GOV.UK Design System — Text input
  7. web.dev — Interaction to Next Paint
  8. Google Search Central — Mobile-first indexing best practices

Services related to this topic

Share with