Usability Testing: How to Run It Without a Lab

Author: Inputly

What is usability testing?

Usability testing is watching a real person attempt a real task in your product, then fixing what stopped them. Nothing more complicated than that. You give three to five tasks, you stay quiet, and you write down every pause, wrong turn and workaround you see. The output is a list of concrete interface problems, ranked by how badly they block people, which is exactly the kind of input that makes a prioritisation meeting short and calm. It is the closest thing to seeing your product for the first time.

How is usability testing different from a user interview?

They answer different questions, and mixing them up wastes a session.

| Method | What you ask the person to do | Best question it answers | | --- | --- | --- | | User interview | Talk about their work and past behaviour | Why do you do it this way? | | Usability test | Attempt a task while you watch | Where does the interface fail? | | Feedback survey | Answer fixed questions at scale | How widespread is this? |

If you ask people what they think of a design, you get politeness. If you ask them to export a report and say nothing, you get the truth in under a minute.

How many participants do you need?

Five people per round, and more rounds rather than bigger ones. Jakob Nielsen's long standing rule of thumb is that about five participants uncover roughly 85 percent of usability problems, and in practice the first five sessions find the failures that affect everyone while later sessions find edge cases.

The practical pattern that works for small teams:

1. Fix everything blocking in the first round before running a second.
2. Run a fresh round after each significant release, not once a year.
3. Recruit from the roles that actually do the task, not from whoever is easy to schedule.
4. Include one person who has never seen the product. Their confusion is the most valuable data you will collect.

How do you run a usability test step by step?

Prepare the tasks first, because vague tasks produce vague findings.

| Stage | Time | What to do | | --- | --- | --- | | Warm up | 5 min | Explain you are testing the product, not them, and ask for their honest reaction | | Context | 5 min | How do they handle this task today, with what tools | | Tasks | 25 min | Hand over one task at a time, ask them to think aloud, stay quiet | | Follow up | 10 min | Ask about the moments they hesitated, and what they expected to happen | | Debrief | 5 min | Thank them, explain what happens next |

Task writing is where most sessions are won or lost. Compare these two:

• Weak: "Explore the reports section." Nothing to succeed at, so you learn nothing.
• Strong: "Show me how you would find out which features your team requested most last month."

A good task names a goal, not a route. If your task mentions the button to press, you are testing your instructions.

What should you measure?

Watch the behaviour, and write these down per task. Two or three numbers plus your notes beat an elaborate scoring system.

| Signal | What it means | | --- | --- | | Task success | Completed, completed with difficulty, or failed | | Time on task | Where the interface costs people minutes rather than seconds | | Errors and wrong turns | Which navigation or label misled them | | Verbal hesitations | The moment they said "hmm" or "wait" out loud | | Workarounds | Anything a power user would not need to do |

Note the deliberate omission: satisfaction scores matter less than success here. You can ask how they felt at the end, but if four of five participants failed the task, the rating is not the story.

How do you turn findings into product decisions?

1. Write each problem as a sentence with the task it broke and the participant who hit it. "Three of five could not find the export option; two went to Settings first."
2. Sort into blocking, costly and cosmetic. Only the first two belong in the current cycle.
3. Fix the cheapest blocking problem first, because blockers are rarely expensive and they skew everything else you measure.
4. Re-test the same task with fresh participants after the fix. Without this step you are guessing twice.
5. Log findings next to your other customer input, so a usability problem that also appears in feedback gets the weight it deserves.

Feed the results into the same prioritisation as everything else rather than running testing as a side project, or you will produce reports that nobody acts on.

What are the most common usability testing mistakes?

• Asking leading questions. "Was that easy?" collects agreement, not information. Ask what they expected and what they saw.
• Rescuing the participant. The moment you explain where to click, the session is over as a source of data.
• Testing a prototype of the wrong flow. Test the task your users struggle with, not the screen you are proud of.
• Recruiting only friendly users. Existing fans forgive the interface and hide the problems you need to find.
• Testing once and stopping. Usability is a moving target because you keep shipping. Small rounds forever beats one study a year.

Frequently Asked Questions

1. Can you run usability testing remotely? Yes, and it is the default for most teams. Screen sharing plus a recording gives you nearly everything a lab gives you, minus the travel.
2. Should you test with existing customers or new users? Both, in separate rounds. New users show you on boarding and first-run problems, existing users show you workflow failures at depth.
3. How do you take notes without missing what happens? One person facilitates and one person takes notes, or record the session and tag timestamps afterwards. Never ask the participant to wait while you type.
4. What if the participant asks how to do something? Reflect it back and ask them to guess. The guess is the finding, and it usually shows exactly which label or layout failed.
5. How do you know a fix worked? Re-run the same task with new participants and compare success and time. Pair that with product analytics for a larger sample, but keep the qualitative check for the why.

Run five sessions this month and you will have a shorter, more honest roadmap. Open a free Inputly space to keep those findings next to the requests and votes they explain, so usability problems and feature demand get prioritised together.