No opinion is worth as much as watching a real person struggle with your screen. Usability testing is that watching, done deliberately: several people from your actual audience use the product on their own devices to complete a specific task, while we record where they hesitate, where they go wrong and where they quietly give up. At PBDP this replaces taste-based argument with evidence — decisions get made on task success rates and clip recordings rather than on seniority. The practical outcome is a shorter distance between "we thought it was obvious" and "it turns out it was".

What usability testing actually measures

Five things: whether the user finishes the task, how long it takes, how often they take a wrong path, how much conscious effort it costs, and what they remember afterwards. It is not a survey and not a design beauty contest. We do not ask "which version do you prefer"; we watch whether a person can find their tax invoice using the version they were given. The method pairs observation with measurement, and what people say sits beside what web analytics and reporting already recorded — where the two disagree, we trust the behaviour.

What you receive

• Test protocol: the task list, written scenarios, success criteria and participant screening rules.
• A real participant panel: people from your actual audience rather than colleagues, recruited through user research and analysis and the agreed personas.
• Behaviour recordings: screen and face capture, timestamped to the exact second a mistake happens so teams can review the moment, not the summary.
• Prioritised issue report: every finding scored on severity, number of users affected and estimated cost to fix.
• Baseline numbers: success rate and completion time per task, so you can prove the fix worked after the next round.
• Actionable recommendations: not general advice but a specific change to a specific screen, ready to enter a product redesign backlog.

The process, step by step

1. Define the question: what exactly do we need to learn, and which number would change the decision.
2. Choose the artefact: prototype, staging build or live interface, changing one variable per round.
3. Write the scenarios: tasks phrased in the user's language, never pointing at the button we hope they press.
4. Run the sessions: five to eight individual hours with a trained moderator, no guidance, questions only after the task ends.
5. Analyse patterns: errors are grouped until the root cause shows — labelling, information architecture, form order or missing system feedback.
6. Fix and re-measure: the revised version is tested against the same scenarios so the improvement is proven, not assumed.

Picking the right method

For an early build with no code yet, unmoderated remote testing on a clickable prototype is fastest: results inside a day. For complex enterprise forms, regulated sign-ups or expert users, a moderated lab session earns its cost, because the "why" can be probed in the moment. Before launch, five participants are usually enough; after launch we combine testing with quantitative data and, on sensitive screens such as payment, compare revised variants as an isolated landing page. One rule holds throughout: never test two changes at once, or you will never learn which one moved the number.

Frequently asked questions

How many participants are enough?

Five to find problems, twenty or more to measure percentages. The widely cited usability research shows that five participants surface most severe issues, and later sessions mostly repeat them. Because we work towards decisions rather than dissertations, we prefer several small, frequent rounds over one large study at the end of a project.

What does it cost, and how is the return measured?

Price follows the number of sessions, moderation model, recording depth and how hard the audience is to recruit. The return is measured with the same instrument we started with: task success, completion time and, on revenue pages, the conversion difference before and after the fix. When one small change recovers a few percent of abandoned carts, the test pays for itself inside the month. The full scope of our work is on the services page.

Our product is not built yet — what can you test?

Precisely the thing that is still cheap to change: the prototype. The cheapest fix in any project happens in a design file, not after development. We put the key screens into a clickable file on participants' own phones and deliver the findings before engineering starts, which is the same input our web and mobile UI design team works from.

To make your next product decision on evidence instead of opinion, contact PBDP. Send us the current build and we will draft a test plan around your open questions.