Five people, real devices. You will learn more than from a year of meetings.
Usability testing observes real users attempting real tasks on your product. Haryes recruits participants matching your Kenyan audience, tests on the devices they actually use, and reports the issues in priority order with video evidence.
You cannot test a product you already know how to use.
Everyone inside the business knows where things are, what the words mean, and which step comes next. That knowledge makes it impossible to see what a first-time visitor sees, and no amount of internal review fixes it.
Watching five strangers attempt the task does.
- Labels that make sense internally and nothing to a customer.
- A step everyone inside the business skips mentally because they already know it exists.
- Testing done on fast laptops when the audience is on mid-tier Android phones.
- Disagreements settled by seniority, because nobody has evidence either way.
How a test runs
Two to three weeks from brief to findings.
Define the tasks
Three to five realistic tasks tied to what the business needs people to be able to do.
Tests that answer real questions.
Recruit
Participants matching your actual audience, screened properly, on the devices and connections they really use.
Representative, not convenient.
Moderate the sessions
Each participant attempts the tasks while thinking aloud, with minimal prompting and no leading.
Honest behaviour.
Analyse
Patterns across participants, separated from one person's preference. One person struggling is noise, three is a finding.
Findings, not anecdotes.
Report with evidence
Issues in priority order, each with the video clip that shows it happening.
An argument nobody can dismiss.
Why five participants
Small numbers find most of what matters, which is what makes testing affordable.
Patterns appear early
The serious problems show up with the first few participants, because they are structural rather than personal.
Diminishing returns after.
Test more often instead
Three rounds of five, between changes, beats one round of fifteen at the end.
Iterate, do not accumulate.
Real devices matter
Testing on a mid-tier Android over mobile data surfaces issues a laptop never will.
Match the audience.
Video ends arguments
A clip of three people failing the same step is more persuasive than any report paragraph.
Show, do not summarise.
What you receive
Works well before a build, and again once the first version is live.
A test plan
Agreed before recruitment.
- Tasks tied to business goals
- Participant criteria
- Devices and conditions
Session recordings
Yours to keep.
- Screen and audio
- Consent obtained from every participant
- Clips indexed to findings
Prioritised findings
Patterns, not preferences.
- How many participants hit each issue
- Severity and business impact
- Recommended fix for each
A walkthrough
With the clips.
- Findings presented in order
- Evidence shown, not described
- Recorded for people who missed it
Questions clients ask before they commit
Can we test before the site is built?
Yes, and it is the cheapest time to do it. A clickable prototype tests just as well for structure and labelling, and fixing a prototype costs a fraction of fixing a build.
How do you find participants?
Screened recruitment against criteria we agree with you. We do not use colleagues, friends of the team, or anyone who already knows the product, because they cannot see it fresh.
Is remote testing as good?
For most tasks, yes, and it widens who you can recruit. In-person is better where the physical device, the environment or the connection is part of what you are testing.
What if the test says our idea does not work?
That is the test working. Finding out from five people is considerably cheaper than finding out from the market after you have built it.
Before or after the build?
You have a prototype or a plan.
Test the structure now, while changing it is cheap.
Run a usability testThe product is out and something is not working.
An audit first is often cheaper, then test what the audit flags.
See the UX auditWatching one person fail a task you designed is worth more than ten internal opinions about it.
