Cheap usability testing: remote tests with real users
Cheap usability testing does not mean cutting corners. It means spending money on the one thing that matters, watching real people try to use your product, and skipping the lab, the recruiter and the scheduling. This guide shows how to run unmoderated remote usability tests as micro tasks, how many people you actually need, and how to turn recordings into fixes.
Remote usability testing: moderated vs unmoderated
In a moderated test a researcher watches live and can ask follow-up questions. In an unmoderated test the participant follows written tasks alone and records the session. Unmoderated tests are what make usability testing cheap: no scheduling, no facilitator time, and sessions happen in parallel.
| Moderated | Unmoderated (micro task) | |
|---|---|---|
| Best for | Early concepts, complex B2B workflows, “why” questions | Specific flows in a working product or clickable prototype |
| Your time per session | Full session plus scheduling | Watching the recording, often at higher playback speed |
| Turnaround | Days to weeks | Often the same day |
| Follow-up questions | Live | Only what you wrote in advance (or one request for changes) |
| Risk | Facilitator bias | Unclear tasks, low-effort sessions: fixed by good scenarios and proof |
Use unmoderated tests for the bulk of your testing and save moderated sessions for questions a recording cannot answer.
How many users: the 5-user rule and its limits
Jakob Nielsen’s widely cited advice is that testing with about five users uncovers most of the usability problems in a design, and that you learn more from several small rounds than one big one. It is good advice with important conditions:
- It is per user group. New users and experienced admins hit different problems. Five of each, not five total.
- It is per flow. Five people testing sign-up tells you little about reporting.
- It finds problems; it does not measure them. To estimate a completion rate or compare two designs, you need many more participants.
- It assumes you iterate. The value comes from fixing and testing again with new people.
On a micro-task platform, recruit six to eight per round rather than exactly five: a session or two will be unusable (a recording that cuts off, a tester on the wrong device) and you can reject or request changes on those.
Writing task scenarios
A scenario gives the participant a realistic goal and just enough context, then lets them find their own way. The classic mistake is writing instructions instead of scenarios.
| Weak (instruction) | Strong (scenario) |
|---|---|
| Click “Add expense” and add a $12 lunch. | You just paid $12 for lunch with a colleague. Record it so you can split it later. |
| Go to Settings → Billing and change your plan. | Your team has grown to 12 people. Find out what it would cost and switch to a plan that fits. |
| Use the filter to find red shoes. | Find a pair of red running shoes under $80 in your size. |
- Do not use words that appear on your buttons and menus; you will test word-matching, not understanding.
- Give concrete details (amounts, names, dates) so everyone does comparable work.
- Keep to two to four scenarios per session; fatigue sets in fast when people narrate.
- Say what to do if they get stuck: “If you cannot find it within 2 minutes, say so and move on.” Getting stuck is a valid result.
Prototype, staging or live product?
Unmoderated tests work with anything a participant can open from a link: a clickable prototype, a staging build or your live site. Prototypes are cheapest to change, so test navigation and wording there first. Use staging or live for flows that depend on real behaviour, such as form validation, loading times and emails. Whatever you use, open the link yourself on a phone, logged out and on mobile data, before publishing; a login wall or expired share link wastes a whole round.
Screen recordings and think-aloud
A screen recording with narration is the heart of a remote usability test. On Tasklify, choose Screen recording as a proof type and put these instructions in the proof note:
Recording instructions (copy into your task)
- Start your phone’s or computer’s screen recorder before opening the link, with the microphone on.
- Read each scenario out loud, then try to complete it.
- Say what you are looking for, what you expect to happen, and anything that surprises you.
- There are no wrong answers: we are testing the product, not you.
- Stop recording after the last question and upload the full video. Do not edit it.
Add a text answer for three follow-up questions: Did you complete each scenario (yes/no)? How easy was it, from 1 (very difficult) to 7 (very easy)? What was the most confusing moment? The 1–7 ease rating is a simple, widely used post-task question; it becomes useful when you compare it across rounds.
Target the device that matters (a mobile checkout needs phone testers), and use a minimum approval rate of 90% or more when think-aloud quality matters. Participants who have never seen your product are the point, so avoid over-filtering. For device and country targeting details, see the website usability testing page.
Analyzing results
Watching recordings is where cheap usability testing becomes useful. Keep it structured:
- Watch every session once without notes, or at least the first two, to get a feel for the flow.
- Log observations in a spreadsheet: one row per issue, one column per participant, mark who hit it.
- Note the evidence: timestamp and a short quote, so teammates can check the clip.
- Rate severity: blocked the goal, caused a detour, or just slowed them down.
- Prioritise issues that are both severe and frequent. An issue seen once is a hypothesis; seen three times it is a pattern.
| Issue | P1 | P2 | P3 | P4 | P5 | Severity |
|---|---|---|---|---|---|---|
| Didn’t notice “Skip” on plan screen | ✓ | ✓ | ✓ | ✓ | High | |
| Expected “Split” under the expense, not in menu | ✓ | ✓ | Medium | |||
| Date picker defaults to US format | ✓ | Low |
Share two-minute clips of the top issues with the team. A clip of a real person failing to find a button settles design debates faster than any slide. Then fix, and test again with fresh participants.
Budget examples for remote usability testing
Pricing on Tasklify is reward × participants + a 12% service fee. Recorded sessions take effort, so pay at least the suggested reward for the session length. With current suggested rewards:
| Study | Setup | Total |
|---|---|---|
| Quick check of one screen | 6 × $0.70 (10 min) | $4.70 |
| One round, one flow | 8 × $1 (15 min, recording) | $8.96 |
| Three iterative rounds | 3 × (8 × $1) | $26.88 |
| Longer exploratory session | 5 × $2 (30 min) | $11.20 |
The minimum top-up is $10. Rewards are held until you approve each session, and if a recording is incomplete you can request changes once before deciding. See pricing for the full breakdown.
Frequently asked questions
What is the cheapest way to do usability testing?
Unmoderated remote tests with a small number of participants per round. You write the scenarios once, participants record themselves completing them, and you watch the recordings. Running several small rounds is cheaper and more useful than one large study.
Is five users really enough for a usability test?
For finding the most common problems in one flow with one type of user, a handful of participants usually shows the main issues. It is not enough for measuring success rates precisely, for comparing designs statistically, or for covering several distinct user groups. Test five or so per segment and iterate.
Do I need special software for remote usability testing?
Not for unmoderated tests. Participants can use the screen recorder built into their phone or computer and upload the recording as proof. You need only a place to watch recordings and a spreadsheet to log issues.
How much does a remote usability test cost on Tasklify?
You pay the reward per participant times the number of participants plus a 12% service fee. A round of eight 15-minute recorded sessions at the suggested reward costs less than many single moderated sessions.
Can testers use my real product with real data?
Use a staging environment or test accounts where possible. Never ask testers to enter real payment details or other people’s personal data, and tell them clearly if anything on screen is test data.