Seeing your app through new users' eyes: a one-week method

The people who build an app are the worst placed to judge it. After a few months you know where every setting lives, which icon means what and which screen you can skip. Your test account is full of tidy data, your phone is recent, the office Wi-Fi is fast and the text size is whatever the default was. A new user arrives with none of that, usually on a bus and often in a hurry.

You can't forget what you know. You can borrow other people's eyes, though, and you can change the conditions you use the app under until it feels unfamiliar again. This guide covers both: fresh-eyes testing, first-use recordings, support tickets and reviews as a mirror, and accessibility settings used as a lens. It ends with a one-week exercise a small team can run. For the first-run flow on its own, our guide to onboarding flows people actually finish has a step by step audit. What follows looks at the whole app, including the weeks after install.

Contains affiliate links. As an Amazon Associate I earn from qualifying purchases.

What the team knows that users don't

Familiarity hides problems in predictable places. A good first step is to write down what the team has that a new user lacks, because each row is a test condition you can recreate.

The team has	A new user has	How to recreate it
An account full of sample data	An empty account	Sign up fresh, with a new email, on a reset device
Names for every feature	Their own words	Ask people to name each screen before you tell them
Recent phones on fast Wi-Fi	An older phone and patchy mobile data	Test on the oldest supported device with a throttled network
Default text size and light mode	Their own settings	Largest text, dark mode, a second language
Permissions granted long ago	Permissions denied on day one	Deny everything and use the app anyway
A reason to persist	A dozen other apps to try	Give yourself a time limit for each task

The second row matters more than it looks. Teams name things during planning ("Spaces", "Flows", "the hub") and those names leak into the interface. Users never sat in those meetings.

Fresh-eyes testing without a lab

Watching a stranger use your app doesn't need a research budget. It needs people who have never seen the app, one realistic task, and the discipline to stay quiet. Friends of friends, colleagues from another department and customers of a different product all qualify. Current users don't, for this purpose, because they have already learned your quirks.

Give a task, not a tour. "You've just had dinner with three friends and paid the whole bill. Get your money back." Then hand over the phone and say nothing. Ask the person to think aloud, and note every pause longer than a couple of seconds, every tap on something that isn't tappable and every trip back to the previous screen. If you have to step in, write down exactly where, because that spot is the finding.

A handful of short sessions usually turns up the worst problems; after that, the same stumbles repeat. Fresh eyes are also a one-time resource. Each person can be new to your app only once, so don't spend them on a build you already know is broken.

First-use recordings

When you can't sit next to someone, ask them to record. Both platforms have a screen recorder built in: iOS has one in Control Center, and Android 11 and later has a Screen record tile in Quick Settings that can also show touches, which is exactly what you want to see. A recording made on the tester's own phone carries their real settings: their text size, their language, their crowded home screen.

Ask testers to turn on Do Not Disturb before they start, so private messages don't land in the video, and tell them how long you keep the file and who will watch it. Delete recordings once the findings are written down. If you use a session replay tool in production instead, mask text fields, mention it in your privacy policy and check with whoever handles GDPR on your side before switching it on.

Watch the first minute twice. The second time, turn the sound off and watch only the hands.

Support tickets and reviews as a mirror

Support tickets are first-use reports written by people who got stuck. Read them raw rather than as a monthly summary chart, and read them for vocabulary as much as for bugs. If people write "the calendar" when your interface says "Timeline", that gap deserves a design ticket. Keep a running list of user words next to your own, and check it whenever you write a new label.

Store reviews work the same way. Search the lower-rated ones for phrases like "can't find", "where is", "how do I" and "it won't let me". A one-star review that describes a confusing first session is worth more than ten that say the app is great. Tag each finding with the screen it belongs to, and patterns appear after a few dozen.

Accessibility settings as a lens

Accessibility settings exist for the people who rely on them, and that alone is reason to test with them; our accessibility checklist for small teams covers what to check. They have a second use too: they make a familiar app strange again.

Turn on the largest text size and the layout tells you which labels the screen really depends on. On iOS you can change the text size for a single app from the Text Size control in Control Center, which keeps the rest of the phone usable. Turn on VoiceOver or TalkBack and listen to the order things are read in. Switch the display to grayscale (Color Filters on iOS, or the monochromacy simulation in Android's developer options) and see whether color was carrying meaning on its own.

Two developer settings belong in the same toolbox. Xcode can run an app in a double-length pseudolanguage or a right-to-left pseudolanguage from the scheme's run options, and Android offers pseudolocales once you enable them for debug builds. Both expose truncated labels and hard-coded strings within minutes. For networks, Apple's Network Link Conditioner and the Android emulator's cellular settings slow everything down to the speed of a train tunnel.

A one-week perspective exercise

Block an hour a day for one person, or share the days across the team. Keep a single shared page of findings.

Monday, start from nothing. Use a reset or borrowed device, install the release build from the store or a test track, and create a new account. Record the session, then write down everything you needed to know that the app never told you.
Tuesday, read what users wrote. Go through 30 recent support tickets and 30 low-rated reviews, and build the vocabulary list.
Wednesday, change the settings. Largest text, a screen reader, grayscale, dark mode, a pseudolanguage. Screenshot every screen that breaks.
Thursday, make conditions worse. The oldest supported device, a slow network, Low Power Mode or Battery Saver, and every permission denied.
Friday, borrow two pairs of eyes. Run two fresh-eyes sessions with one task each, then meet for half an hour and pick three fixes for the next release.

Three fixes is enough. The value of the week is the habit, and a short list actually ships.

Questions

How often should we repeat the exercise?

Once a quarter suits most small teams, plus once before any redesign or major release. The ticket and review reading can happen monthly, because it takes an hour and the material changes quickly.

Can't analytics show us the same thing?

Analytics show where people drop off, not why. A funnel can tell you that many new users leave on the third screen; a recording shows them looking for a button below the fold. Use numbers to decide which screens to watch, and see our piece on A/B testing in mobile apps before reading too much into small differences.

Who on the team should watch the sessions?

Everyone who makes decisions about the interface, developers included. A developer who watches a tester hunt for a hidden gesture for a full minute rarely needs convincing about the fix. If only designers watch, findings turn into one person's word against another's.

What if testers say things we disagree with?

Weigh what people do over what they say. A tester who calls a screen fine while tapping the wrong button three times has given the more useful answer with their hands. Opinions about colors and fonts are worth noting, but rarely worth acting on after a single session.