7 Mobile App Usability Testing Examples, From Checkout to Check-In

Picture a participant in her kitchen, phone in one hand, reordering last week’s groceries. She taps a delivery slot that looks open, nothing happens, and she taps twice more before setting the phone down to read the screen. Your analytics can show that orders drop on that screen, but only watching her shows the tap that missed and the reason behind it.

The seven mobile app usability testing examples below each start from a moment like that one and show the study that explains it. Every example names the research question, the method, the participants, a sample task, and what to measure, so you can borrow the plan closest to your own app.

TL;DR

• Pick the example closest to your app’s problem, then adapt its question, method, and sample task.
• Moderated sessions explain why people stall; unmoderated studies, X-second tests, and tree tests answer narrower questions faster.
• Recruit people who have used their own phone for at least three months, with separate quotas for iOS and Android.
• Test the way phones are really used: one hand, a cellular connection, and the occasional interruption.
• Run small rounds of five or six people per platform, fix what you find, then test again.

Compare the Seven Mobile App Usability Testing Examples at a Glance

Each example is an illustrative model study built to show a method in context, with no results from a real Userlytics study. The steps, task formats, and sources are real, so you can lift the structure and replace the app.

1. Find Why Grocery Reorders Stall at the Delivery Slot

An in-house product team at a regional grocery chain sees orders drop between the basket and the delivery-slot screen in its new reorder flow. Before the next sprint, the product lead has to decide whether to redesign the slot picker or the substitution step, and the study exists to settle that decision.

Each participant works through five tasks, from reorder to the final review.

In the sessions, participants think aloud while they work. The think-aloud protocol works best when the moderator stays quiet until something happens worth asking about. The moderator guide holds four neutral probes:

1. “What did you expect to happen when you tapped there?”
2. “What is this screen telling you?”
3. “You paused for a moment. What were you looking for?”
4. “If you were at home right now, what would you do next?”

Each probe asks about what the participant just did. None of them suggests an answer or praises the design.

What to measure: task success on the slot task, repeated taps on one control, and the time from opening the basket to a confirmed slot.

2. Test a Banking App’s Onboarding Before It Ships

A bank’s product team has rebuilt account sign-up in its app and wants to know whether new customers can finish it alone before release. The build exists only as a prerelease version, so the study runs unmoderated on participants’ own phones.

Setup needs care on both platforms. The Userlytics Help Center guide to testing a TestFlight prototype recommends a screener question confirming participants have installed TestFlight and opened the link. The guide to testing an APK file has Android participants install the build from a public link, which may require allowing installs from unknown sources.

Give participants test details for every field that would normally hold personal data. Userlytics tells its participants to stop and contact support if a test asks for financial or personal information, such as a card number or a password, so a study that depends on real details will stall on its own.

With no moderator present, any probing has to be built into the study. AI Moderation adds AI follow-up questions to selected activities in unmoderated Userlytics studies. Confirm it is available for your mobile study type before you plan around it.

Where it is, the researcher writes the objective in plain language, such as “understand why the participant stopped at the identity step,” and the AI asks a follow-up question when a response calls for it. Where it is not, add one open question after each sign-up step that asks what the participant expected to happen.

What to measure: completion of the full sign-up, the step where each participant stopped, and what they said at that moment.

3. Check One-Handed Workout Logging in a Fitness App

A fitness app team wants to know whether people can log a set between exercises without breaking their workout. Gym use is often one-handed and interrupted, so the study recreates both conditions.

For the one-handed task, the moderator asks participants to hold the phone in one hand, the way they would while holding a water bottle. During the second task, the moderator pauses the session for 30 seconds, then watches whether the participant can pick up where they left off. Nielsen Norman Group notes in its guide to setting up a mobile usability study that phones are used in interruptible places, so a planned interruption adds realism.

The team also checks the size of every control in the logging flow against platform guidance. Apple’s Human Interface Guidelines list 44 x 44 points as the default control size on iOS, and Material Design recommends touch targets of at least 48 x 48 dp for most platforms. A plus button can look roomy in a zoomed-in design file and still measure below those sizes when it ships.

What to measure: mis-taps on the logging controls, a 1 to 5 one-handed ease rating after the task, and whether participants recover after the pause.

4. Run an Airline Check-In on a Weak Cellular Signal

An airline’s app team wants to know how online check-in holds up on the way to the airport, away from fast Wi-Fi. Nielsen Norman Group recommends testing apps on both cellular and Wi-Fi connections, since a weaker connection shows how an app behaves when screens load slowly.

The cellular sessions can show what the Wi-Fi sessions hide: a seat map that renders in stages, a spinner with no message, or a boarding pass that fails to save. Compare the two groups task by task rather than in one blended result.

What to measure: task success per connection type, time on task for successful attempts, and every point where a participant retried an action.

5. Measure First Impressions of a Food Delivery Home Screen

A food delivery app is about to launch a redesigned home screen with a new promotions banner. The team wants to know what people notice in the first seconds and where they would tap to start an order, so the study uses two quick activities instead of a full session.

The Userlytics guide to X-second tests describes showing an uploaded image or screenshot for a short time, often five seconds, then asking what the participant noticed or felt. Both the X-second test and the first-click test work with mobile recording, and the first-click results arrive as a heatmap and click map of where participants tapped.

Treat the results as first-impression evidence. A screen can be memorable at a glance and still slow people down once they try to order, so pair these activities with a task-based round before launch.

What to measure: what participants recall after five seconds, how many first clicks land on the intended control, and how long the first click took.

6. Compare Two Navigation Designs for a News App

A news publisher is choosing between a bottom tab bar and a single menu for its app. Before building either, the team tests whether people can find sections in each structure and which design they prefer.

A tree test asks participants to find an item in a hierarchy of labels, so the structure is judged before visual design adds noise. Userlytics reports a success rate, the first category chosen, time spent, and directness for each task, and the method works for websites, mobile apps, and prototypes.

A preference test on its own never proves that a design performs better. Pair it with the tree test results before anyone quotes it in a meeting.

What to measure: success rate and directness per task for each structure, and the reasons participants give for their preference.

7. Study a Field-Service App With Your Own Employees

An enterprise operations team has released a field-service app its technicians use to close out jobs on site. The people who matter are already on the payroll, so the study recruits them directly instead of drawing from a panel.

With BYOU (Bring Your Own Users), you can invite your own participants and manage them inside Userlytics, or combine them with the global panel of 2M+ participants in 150+ countries. Tell participants up front that the session evaluates the app and does not assess their work.

What to measure: task success on job close-out, time on task, and the workarounds technicians describe, such as notes kept outside the app.

Need someone to run one of these studies for you? Userlytics UX consultants can design the plan, moderate mobile sessions, and deliver the findings report to your team. Talk to a UX consultant

Build Your Own Study From These Mobile App Usability Testing Examples

Every example above follows the same four moves, whatever the app. Use them to adapt the closest example to your own product.

1. Screen for Participants Who Know Their Phones

Nielsen Norman Group recommends recruiting people who have used their device for at least three months, because new owners do not yet behave the way regular owners do. The same guide suggests naming the exact device in screener questions. Someone who owns a phone and a tablet should answer about the one you plan to test.

Platform quotas need deliberate setup. On Userlytics, selecting both iOS and Android recruits on a first-come, first-served basis, so the split can land at six and four. The Help Center guide to running mobile moderated sessions recommends duplicating the study and setting each copy to one platform when you need equal numbers.

2. Write Task Scenarios With a Clear Finish Line

Good task scenarios give a person a reason to act without telling them how. The Nielsen Norman Group article on usability task scenarios asks for tasks that are realistic, that ask for an action, and that avoid clues about which control to use.

The sample tasks in each example follow that rule and never say “tap the calendar icon” or “open the menu.” If a participant has to ask which button to press, the scenario has done its job, and the interface has a problem to fix.

3. Pilot the Build on iOS and Android

A pilot with one person per platform catches broken links, unclear task wording, and builds that will not install. Run it with someone who did not write the tasks.

The pilot also confirms the recording setup. On Userlytics, mobile app testing runs on iOS and Android phones and tablets without an SDK, and participants stay inside the app being tested. The participant app, rated 4.7 on the US App Store from about 3,000 ratings, now includes a guided check of the internet connection, camera, audio, and screen sharing before a study starts.

4. Log Every Finding in One Shared Format

Findings scattered across notes, chats, and memory do not survive the stakeholder meeting. Log every observation in one table during or right after each session.

The evidence column is what turns a finding into something a skeptical engineer accepts. AI Annotations flags key moments, sentiment patterns, and usability friction once transcripts are ready, so the researcher can confirm each logged moment and pull the clip without scrubbing through the full recording.

Measure Each Mobile App Usability Testing Example by What Participants Do

Behavior comes first in mobile usability testing, because what people do on a small screen often differs from what they say about it. The examples draw on five measures, and each one stays in its lane.

With five or six people per platform, report counts and quotes rather than precise percentages. “Four of six iPhone participants tapped the slot twice” is honest. “67% of iPhone participants” suggests a precision a small round cannot support.

The System Usability Scale earns its place when you compare the same flow across rounds. A single SUS score from six people is a starting point for the next round, and it says little on its own.

Size Each Study Per Platform

Small rounds work because usability problems tend to repeat. In Jakob Nielsen’s analysis of small usability test samples, his model estimates that five participants uncover about 85% of the usability problems, and he recommends three rounds of five over a single round of 15.

Mobile adds a twist. iOS and Android differ in navigation patterns, keyboards, and system controls, so most of the examples treat each platform as its own group of five or six. That puts 10 to 12 people in a first round, which also sits inside the 8 to 20 participant range of the Userlytics mobile app usability test template.

If you need a benchmark you can report with confidence, such as a success rate for an executive dashboard, plan a larger quantitative study. Keep the qualitative rounds small and frequent.

Avoid the Mistakes That Skew Mobile Results

Most weak mobile studies fail in the planning, long before a session starts. These are the patterns the examples were built to avoid.

• Testing only on a simulator or a desktop browser: a mouse pointer lands where a thumb may not, so tap-target problems can disappear. Test on the participant’s own phone.
• Recruiting people new to their device: recent switchers struggle with the operating system and blur what the app itself causes.
• Letting one platform fill the quota: without separate iOS and Android quotas, a study can end up mostly iPhone and miss Android-only problems.
• Writing tasks that name the control: “Tap the calendar to pick a slot” tests reading, and it hides whether people can find the calendar.
• Testing on perfect Wi-Fi only: loading states, timeouts, and half-rendered lists show up far more often on weaker connections.
• Calling a SUS score a percentage: a score of 75 is above the average of 68, and it does not mean the app is “75% usable.”

Start With One Example Before the Next Sprint Review

A first mobile study fits inside a single sprint. Pick whichever of these mobile app usability testing examples sits closest to the flow where your analytics shows the steepest drop, and write the business question it should answer.

Then adapt its sample task into five task scenarios with a clear finish line, recruit five or six experienced phone owners per platform, and run one round this week. Log every finding with its clip, rank the list by severity, and bring the top three to your next sprint review.

See your app the way your customers hold it. Talk to the Userlytics team about testing your app on real phones. Book a free demo

Frequently Asked Questions

These questions come up when teams adapt the examples to their own app.

Can You Test an App Before Launch?

Yes. Unreleased iOS builds can be shared through TestFlight, and Android builds through an APK file, and clickable prototypes from design tools work for earlier concepts. Userlytics supports prototype testing through integrations with tools such as Figma, Adobe XD, and Proto.io.

How Long Should a Mobile Usability Session Be?

The Userlytics mobile app usability test template estimates 15 to 30 minutes per participant, which keeps attention high on a small screen. On Userlytics, a session lasts 30 minutes by default and can run to 45 or 60 minutes when the study needs more time.

Should Participants Use Their Own Phones?

Yes, in most cases. Participants already know their own device, settings, keyboard, and accessibility options, so the session reflects how they really use their phone. Provide a device only when you are studying a specific model or a device the participant does not own.

What Separates Mobile Usability Testing From QA Testing?

QA testing checks whether the app works as built, such as whether a button responds or a screen crashes. Usability testing checks whether people can reach their goal with it. An app can pass every QA test and still lose customers on a confusing screen.

Can We Run the Study With Our Own Customers?

Yes. BYOU studies work for customers as well as employees, and you can run them on their own or alongside panel participants. Mixing current customers with people who shop elsewhere shows both familiarity effects and first-use problems.