Your app's first usability test should embarrass you.

Process · 6 min read

I had a client test his prototype with his uncle. Retired, mid-sixties, not particularly good with technology. The client's logic was simple: if he can figure it out, we're on a winner.

He couldn't figure out one of the features. He tapped the wrong thing, got confused, and asked what "Webster Pack" meant. He's not in the disability sector. He's never heard the term. The feature worked fine. The label didn't. We renamed it the next week.

That test took ten minutes. No lab. No budget. No script longer than one sentence. And it caught a problem that would have confused every single new user who downloaded the app.

Why you don't need a fancy setup

The usability testing industry has made this feel way more complicated than it is. Eye-tracking. Moderated sessions. Recruitment panels. Analytics dashboards. That stuff has its place, but it's not where you start.

Steve Krug, who wrote the book on usability testing, argues that testing with even one user early in the process is better than testing with fifty users at the end. Research from the Nielsen Norman Group backs this up: five users will catch 85% of usability problems. One user will catch more than you expect.

The test I run with clients is dead simple. I hand them the prototype on their phone. I give them a task. "Add a medication for Monday mornings." That's it. Then I watch. I don't help. I don't explain. I don't point to the button they're looking for. I just watch where they tap, where they hesitate, and where they give up.

The things testing catches that thinking doesn't

You can sit in a room and think about your app for weeks. You can diagram every user flow. You can debate button placement and label wording until you've convinced yourself it's all perfect. Then you put it in front of a real person and they do something you never predicted.

On another project, a client's partner tested the scheduling feature. Found it easy. Tapped through, added the entry, set the repeat, no issues. But the client's neighbour, similar age, similar background, completely different result. She scrolled down when she got stuck instead of looking at the buttons in front of her. Two people, same generation, completely different behaviour.

That's the thing about usability testing. It doesn't tell you what people think. It shows you what people do. And those are very different things. People will tell you "yeah, that makes sense" and then tap the wrong button. The action is the truth.

How to run your first test

Find one person who isn't you and isn't your designer. Ideally someone who represents your actual users, but honestly, anyone will do for a first test. Your mum, your mate, your neighbour. If the core flow doesn't make sense to a regular person, it's not going to make sense to your target user either.

Give them one task. Not three. Not "have a play around and tell me what you think." One specific thing. "Book an appointment for next Tuesday." "Add your morning medication." "Find the emergency contact number." Something concrete with a clear success or failure.

Then shut up. This is the hard part. Every instinct will tell you to help. They'll hesitate and you'll want to say "it's that button there." Don't. The hesitation is the data. The confusion is the data. The moment they look up at you for help is the data. That's where the problems live, and those problems are invisible until someone who isn't you tries to use the thing.

What to do with what you learn

You'll find two kinds of problems. The first kind is labelling. People don't understand what something means. That's easy to fix. Change the word. We changed "Webster Pack" to "Medication Pack" because one person didn't understand the term. That's not overreacting to one data point. It's respecting the fact that if one tester doesn't know the term, plenty of real users won't either.

The second kind is structural. People can't find the thing. They tap in the wrong place. They go down a path you didn't intend. That's harder to fix, but it's far better to discover it in a prototype than after you've paid a developer to build it. A label change in a prototype takes five minutes. A structural change after development can take weeks.

The whole point of a prototype is that it's cheap to change. Use that. Test early. Test with people who aren't in your head. And when someone can't figure out your app, don't blame them. Fix the app.

Sources
Why You Only Need to Test with 5 Users (Nielsen Norman Group) - Five users catch 85% of usability problems.
Steve Krug, Don't Make Me Think and Rocket Surgery Made Easy - Foundational texts on lightweight usability testing.

Related blog posts:

A prototype is not an MVP →

Don't forget to do your homework →

Why we renamed a feature mid-build →