Usability Testing Template: The 7 Sections You Need

A usability testing template is a reusable plan you fill in once per study so every session runs the same way. A complete one has seven sections: research objective, participant profile, task scenarios, success metrics, a moderator script, a findings log, and a short report. Below is what goes in each section, with a table you can copy and reuse.

Good usability testing is mostly preparation. A template takes out the guesswork, keeps sessions consistent, and makes results comparable from one round to the next. Here are the seven sections, in the order you fill them in.

1. Research objective and questions

Start with the decision you are trying to make, written in one or two sentences. Then list three to five specific research questions the study will answer, like "Can a first-time visitor find pricing within 30 seconds?" or "Do people understand what they get after signing up?" Tie each objective to a real product decision, not a vague goal like "test the homepage." If you cannot name the decision a finding would change, the question does not belong in the plan.

2. Participant profile and how many

Describe who you want, the screening criteria to reach them, and how many you will run. For a moderated qualitative study, five participants per distinct user segment is the widely accepted minimum. Jakob Nielsen's model at Nielsen Norman Group shows that testing with five users uncovers roughly 85% of the usability problems in a fairly homogeneous group, and that extra users past that point mostly repeat what you already saw. If you have two clearly different audiences, run five in each rather than ten in one.

3. Task scenarios

The tasks are the heart of the test, so write them with care. Each one should read as a realistic scenario that gives a goal and some context without naming buttons or hinting at the path. "You bought a pair of shoes last week and they do not fit. Show me how you would start a return" works. "Click the Returns link in the footer" does not, because it hands the participant the answer. Neutral wording keeps you from leading people and lets the real friction show up on its own.

4. Success metrics and criteria

Decide before testing how you will measure each task, then write the pass threshold next to it. The four standard usability metrics are task completion rate, time on task, error rate, and a satisfaction score. For overall satisfaction, the System Usability Scale is the common yardstick. Jeff Sauro's analysis of more than 500 studies puts the average SUS score at 68, so treat 68 as a plain C and aim above 80, the point where users start recommending a product to others. Setting thresholds up front stops you from grading on a curve after the fact.

5. Moderator script

A short script keeps every session consistent: a one-line welcome, a reminder that you are testing the design and not the person, and the think-aloud instruction. Thinking aloud, where you ask people to say whatever crosses their mind as they work, is the single most useful technique in usability testing according to Nielsen Norman Group, because it shows you why someone hesitates, not just that they did. Add a few neutral prompts you will reuse, like "What are you expecting to happen here?" and keep a moderating checklist nearby so you stay quiet and avoid steering.

6. Findings log

During and right after each session, record what happened in a structured way: the issue, the task it came up in, which participant hit it, and a severity rating from cosmetic to minor, major, or blocker. The severity tag is what turns a pile of raw notes into a ranked fix list. A blocker that stops one person from checking out matters far more than a label three people found slightly confusing, and your log should make that obvious at a glance.

7. Summary report

Close the loop with a one-page summary so the work actually changes the product. List the top issues by severity, the metric results against the thresholds you set in section four, and a recommended fix for each major problem. Keep it short enough that a busy team will read it. A template that ends in a clear report is the difference between research that ships changes and research that sits in a folder.

The template at a glance

Section	What to write	Quick example
Objective	The decision plus 3-5 research questions	"Can a new user find pricing in 30s?"
Participants	Profile, screener, count per segment	5 small-business owners
Tasks	Realistic scenarios, no UI hints	"Start a return for last week's order"
Metrics	Completion, time, errors, satisfaction	Pass = task done under 60s
Moderator script	Welcome, think-aloud, neutral prompts	"What do you expect to happen?"
Findings log	Issue, task, participant, severity	"Checkout button hidden, blocker"
Report	Top issues, metrics vs threshold, fixes	One page, ranked by severity

When you cannot recruit five users

A template assumes two things you may not have yet: a pool of people to recruit from and the calendar time to schedule sessions. Early-stage sites and pre-launch flows rarely have either, which is why so many teams skip testing right when it would help most. That gap is the reason we built CanaryUsers. It runs a flock of AI users through your live site, working through real task scenarios, and reports where they get stuck, with no recruiting and no traffic required. Across the 428 sites we scanned, the average score was 70, and 27% had no clear call to action while 28% asked people for input without showing any trust signals. Those are exactly the problems a task-based test is meant to catch. run a free scan to see your own drop-off points in a few minutes, then use the template above to investigate the ones worth a moderated session.

The point of a template is not paperwork. It is making the next test easy enough that you actually run it, and consistent enough that you can trust what it tells you.