Usability testing without a lab

Every park has one: the paved path the landscape architect designed, and beside it the worn dirt shortcut across the grass that everybody actually walks. The path is what we thought users would want. We planned it, we designed it, we built it. The users took one look and cut the corner, and now the grass is damaged beyond repair. Software is exactly the same, except the trampled grass is your signup flow.

The discipline that catches this before launch is usability testing, and the good news is that it needs no lab, no one-way mirror and no research department. It needs a prototype, a handful of the right people, and the self-restraint to shut up and watch.

Usability testing is a method of testing a website, app or other digital product by observing real users as they attempt to complete tasks on it. It is not bug testing, bug fixing or user acceptance testing; it’s the part of the UX process where we find out whether people can use the product the way we hoped, or whether they actually need something different.

Why your assumptions need testing

The core mistake usability testing corrects is assuming our product design makes sense to other people the way it makes sense to us. It doesn’t need to be a subtle design flaw; sometimes the assumption that fails is foundational. You might be convinced your users want a desktop application, and discover most of them prefer to accomplish the task on mobile. Or take an app for sitting down and recording stories with family members: the natural assumption is that people record their own stories and share them, but in practice it’s usually the family member who initiates the recording, so the people driving usage aren’t the users you designed for. Assumptions that central can be completely invalid, and no amount of internal review will tell you, because everyone inside the project shares them.

There’s an everyday version of this failure you’ve almost certainly lived. You open a SaaS product looking for the billing screen to downgrade a subscription, or the settings screen to change your email address. These are utterly standard features that exist in every product, and yet you spend three, five minutes hunting, because the team put them somewhere completely different from where users expect. If those companies had run a usability test on that functionality, they’d have watched someone flounder for minutes and realised the design wasn’t usable. That’s the entire goal: to discover the frustrations users actually have with the design, while it’s still cheap to change.

What you’re listening for

The main goal of a usability test is to uncover pain points. As your testers work through the app, where do they get stuck? Where do they get frustrated? How could the experience be improved? Concretely, expect to see things like:

• They can’t find a feature they’re looking for in the nav.
• They get stuck on a screen and can’t go back.
• They can’t progress through signup and onboarding, because too much information is being requested up front and what they really want to do is skip ahead and try the one crucial feature they came for.

None of these are bugs. Everything works exactly as built. That’s precisely why this class of problem survives your own testing and QA: the product does what you intended, and what you intended is the problem.

You don’t need a finished product

Two kinds of prototype support a perfectly good test. The first is the live app itself: with tools like Bubble it’s easier than ever to have a genuinely working prototype early, which you can put in front of real users and iterate on. The second is a Figma prototype, which steps the user through your actual designs with clickable regions, so it looks and feels like a working app even though it’s just linked screens. Once you have some UI designs completed, you have enough to test with.

The sessions themselves need nothing lab-like either. You can sit in a room with somebody and watch them use the product. You can run it over a video call and have them share their screen while they navigate. Or you can use tools that record the user’s screen and review the sessions afterwards. All three produce the thing that matters: direct observation of a real person attempting real tasks.

Plan just enough

It’s great to have a usability test plan, and there are plenty of published examples and templates worth scanning. But it doesn’t have to be over the top. In its simplest form, planning a test means answering three questions:

1. How many people do we want to test? At least three is the working minimum; a handful of honest sessions surfaces most of what a formal study would.
2. What are our main questions? Decide up front which parts of the design you need validated: the tasks the product exists to serve, the flows you’re least sure about.
3. Who is the right audience? Recruit from the people the product is actually for, the same audience you surveyed during research, not whoever happens to be nearby.

Then run the sessions around your main tasks and watch.

Observe without contaminating

The discipline that separates a useful test from a demo is this: don’t lead the user. Don’t ask leading questions, don’t give them a tutorial of the product, and don’t bias the results by explaining what things do. Let them try to find their way through and accomplish the product’s tasks without prompting. The moment you say “oh, that’s under the profile menu”, you’ve thrown the session away, because you won’t be standing next to your real users in production.

This takes more self-control than it sounds. Watching someone miss a button you can see perfectly well is genuinely uncomfortable, and narrating the product is a reflex, especially when the product is yours. Remember you’re not trying to sell the app to the person in front of you; you’re trying to extract data that makes the app better. Every struggle you resist interrupting is exactly the finding you came for.

Respect Jakob’s law

One principle prevents half the failures you’d otherwise catch in testing. Users spend most of their time on other sites and in other apps, which means they prefer your product to work the same way as all the ones they already know. That’s Jakob’s law, and it’s self-explanatory but routinely violated. Everyone else puts the nav bar on the left, so putting yours on the right feels boldly original. Everyone puts user settings in the top-right corner, so yours go bottom-left. Everyone’s logo sits top-left and links home, so yours lives in the footer and goes somewhere else.

Don’t. Follow the normal conventions of most other sites, and spend your creativity on the problem you’re solving rather than on relocating furniture. Convention is accumulated usability research you get for free, and every deviation from it is something your testers will trip over before your users do.

From observation to iteration

A usability test only pays off if the findings change the product. Collect the pain points across your sessions: the places people got stuck, the features they couldn’t find, the steps where they wanted to bail. Where the same struggle shows up for more than one tester, you’ve found a design problem, not a user problem. Take those learnings, revise the design, and fold the fixes into the next iteration; testing sits at the end of the lightweight UX process precisely so its output can loop straight back into wireframes and build. It’s the same humility that runs through the whole process: the product is shaped by user evidence, not by our assumptions about what makes sense.

Try it yourself

Take whatever you have right now: a Figma prototype or a rough working Bubble app. Recruit three people from your actual audience. Give each a task the product exists to serve (“find and contact a freelancer you’d hire”), then say nothing. Watch over a screen share or shoulder, and write down every hesitation, wrong turn and backtrack. Three sessions in, you’ll have a repair list more honest than any internal review could produce, and you’ll never again assume a design works just because it makes sense to you.

This skill in the AI era

AI has made prototypes nearly free: what took a Bubble build now takes Claude Code an afternoon, which means there’s no longer any excuse to test late. What hasn’t changed is that no model can watch a human hesitate; the observation, and the restraint not to lead, remain stubbornly manual. Our working loop as a Claude Code development team in Sydney is to generate the prototype quickly, put it in front of three real users, and feed their pain points back as the next prompt. The tests got cheaper to arrange and the software got faster to change, but the skill of extracting honest evidence from users is the same one we practised in Bubble — see how the rest of that toolkit translated.