Usability Testing Services: The 7 Step Process and a Sample Script

Usability testing services are moderated or unmoderated sessions with real users. Recruited people attempt real tasks in your product. A moderator watches, records, and notes exactly where they get stuck.

That is different from an expert review. A UX audit or a heuristic evaluation is one person inspecting your product against known principles, with nobody real in the room. Testing observes actual behavior. An audit predicts likely problems.

Reach for testing when a flow is already losing people and nobody can explain why. Or before you spend engineering time on a fix you are only guessing will work.

Below is the difference, a 7 step process, and the script I use.

Usability testing services vs a UX audit: who is actually in the room

The core rule is simple. Expert methods predict, testing observes. A heuristic evaluation or a UX audit tells you where a screen might confuse someone, based on known principles. Usability testing tells you whether it actually does, because someone real sits down and tries.

Here is what separates the three, side by side.

| Method | Who is in the room | What it answers | What it cannot tell you | |---|---|---|---| | Heuristic evaluation | One expert reviewer | Does this screen break a known usability principle | Whether a real person would hit it, or care | | UX audit | A reviewer, plus whatever analytics exist | Where the product is losing people, and in what order to fix it | Why people behave that way | | Usability testing | Recruited users, plus a moderator | Can a real person complete this task, and where do they get stuck | How widespread the problem is at scale |

An audit is faster and cheaper, and it gives you a ranked backlog. Testing is slower, and it gives you the reason behind the behavior. Neither replaces the other.

Think of it as a pairing. An audit generates suspects. A test convicts them. Running the audit first makes the test cheaper too, because you already know which tasks to script.

If you have not run one yet, the full UX audit process end to end covers the audit side in detail.

What usability testing services include, end to end

A usability testing engagement should produce these deliverables, not just a summary deck:

• A study plan with the research question written down
• A screener that filters for the real audience
• Recruited participants who match that screener
• Session recordings
• A findings document with severity scores
• A short clip reel of the worst moments
• A prioritized fix list

Moderated sessions let you probe the why. Unmoderated sessions give you volume and speed with no chance to follow up. For a first round I moderate, because five real conversations teach you more than twenty silent recordings.

Remote is the default now, and it works for almost everything. In person only earns its cost for physical context, specific hardware, or environments like a clinic or a warehouse floor.

Cost has no honest single answer. It moves with participant count, how hard the audience is to recruit, incentives, and moderated versus unmoderated. Ask any provider to quote recruiting, incentives, and moderation as separate line items.

For comparison, real 2026 UX audit price bands are a useful anchor, and a worked audit report with findings written out shows what a finished deliverable looks like.

How to run a usability test in 7 steps

1. Write down the single question the study answers. One question, not five. If you cannot say it in one sentence, the study will produce anecdotes, not answers.

2. Script tasks, not features. A task has a goal and a finish line, so you can watch someone fail it. "Try the new filters" is not a task. "Find a plan that covers three seats and start checkout" is a task, because it has a clear finish line.

3. Recruit the actual audience, using a screener. Testing your teammates, your investors, or your users' account managers produces flattering nonsense, not findings.

4. Set a sample size and a round count. Aim for five to eight people per user group, per round. Fix what you found, then run a second round.

5. Pilot the session with one person first. Broken prototypes, ambiguous task wording, and overlong sessions all surface here for free, before you burn a real participant.

6. Moderate without leading. Your job is silence, a stopwatch, and three neutral prompts. The exact wording for those prompts is below.

7. Turn recordings into severity scored findings, with a named fix per finding. A finding without an owner or a fix sits in a document, unread. For a reference you can reuse across rounds, a fixed list of usability checks is worth keeping next to your findings doc.

Usability testing questions: the script I actually use

Before the tasks

Open every session with the same framing line, said out loud: "We are testing the product, not you. There is no wrong answer here."

Then ask:

• "What do you currently use to do this job?"
• "When did you last do this?"
• "What usually goes wrong when you try?"
• "Walk me through the last time you did this, step by step."

During the tasks

Ask only these three prompts while someone works through a task:

• "What are you trying to do right now?"
• "What did you expect to happen?"
• "Talk me through what you are looking at."

Wait a full ten seconds of silence before you step in. That silence is where the real findings live.

After the tasks

• "What was the hardest part of that for you?"
• "If a colleague asked you about this product tomorrow, what would you tell them?"
• "What almost stopped you from finishing?"
• "If you could change one thing we just tested, what would it be?"

Questions that bias the result

Some questions look neutral and are not. They shape the answer before the participant opens their mouth.

| Biased question | Ask this instead | |---|---| | How easy was that to use? | How did that compare to what you expected? | | Would you pay for this? | What do you use today, and what does it cost you? | | Would you like a dashboard here? | What did you come here to find out? | | Did you find that confusing? | What was going through your mind just then? | | Let me show you where that is. | What would you try next? |

Those versions fail because people are polite, nobody can forecast their own behavior, and a rescued task is one you never tested.

How many participants you need, honestly

The working answer is five to eight people per distinct user group, per round. Two very different audiences mean two separate sets of participants, not one pool.

The part nobody says out loud: more rounds beat bigger rounds. Twelve people in a single round mostly confirm the same blocker, again and again. Two rounds of six, with fixes shipped in between, tells you whether the fix actually worked.

There is a real limit here too. Qualitative testing tells you what is broken and why. It does not tell you how many users hit that problem. For prevalence, you need analytics or a survey behind it.

When usability testing is the wrong spend

Testing is not always the right next step. I have talked clients out of it more than once.

1. You have not fixed the blockers you already know about. Watching five people hit the same broken email verification step is an expensive way to confirm a bug ticket you already opened.

2. You cannot reach the real audience. If recruiting means paying panel participants who will never touch your product again, the findings are theatre. Run an expert inspection pass instead. It costs less and needs no recruiting.

3. Nobody has capacity to build the fixes. A clip reel of people struggling changes nothing if the backlog is frozen for two quarters.

That third one is the most common. On a B2B trading platform, an anonymized composite rather than any one client, three rounds had already found the fix. Nobody shipped it.

If the whole product feels wrong rather than one flow, the signal is different. Behavioral signals that point to a redesign is a better place to start than a usability round.

When you do have capacity and a real question, the usability testing service I run turns recruited, moderated, recorded sessions into a severity scored fix list you could hand an engineer on Monday.