Website usability tests and recorded sessions, what they pay

What a usability test actually buys

A product team has built a new checkout page. They think it’s clear. They want to watch a stranger try to buy something on it, hear what that person is thinking, and see exactly where they hesitate. That recording is the product in paid usability testing.

It’s a different deliverable from a survey. A survey buys your opinions, usually as clicks on a scale. A focus group buys a conversation. A product test buys your experience of something physical over days or weeks. A usability test buys your behaviour on a screen, captured on video, with your voice narrating it.

That changes how the work is set up and how it’s paid. The client doesn’t care much about your demographic profile beyond a few targeting criteria. They care that you’re the kind of person who’d plausibly use their product, that you’ll speak clearly while you work, and that the recording is usable. A silent video of someone clicking around is close to worthless to them. A video of someone saying “I expected the shipping cost to be here, and I can’t find it” is exactly what they paid for.

Most paid usability work is done through testing platforms that sit between product teams and testers. The team writes a set of tasks and a short screener. The platform finds testers who match, collects the recordings, and delivers them. Testers get paid a fixed amount per accepted test.

This piece explains how that system works from the tester’s side: the screener, the practice test most platforms use to vet new testers, the rating system that decides how many tests you see, and why pay is per test instead of per minute. Figures below are illustrations. Rates vary by platform, by test type and over time, and none of this is a claim about what a specific platform pays.

The think-aloud method in plain terms

The core technique is called thinking aloud. While you work through the tasks, you say what you’re doing, what you’re looking for, what you expect to happen and how you feel when it doesn’t.

It sounds easy. At first it usually isn’t. Most people go quiet when they concentrate, which is exactly the moment the product team most wants to hear from them. A good tester keeps talking through the confusion. “I’m looking for a menu. There’s an icon up here, I think that might be it. No, that’s search. Okay, I’m going to scroll down.” That running commentary is what makes the recording useful.

Clients also want honesty more than politeness. If a page is confusing, they need to hear that. Testers sometimes soften criticism because it feels rude, or try to guess what the client wants to hear. That makes the recording less useful, and experienced reviewers can usually tell. The job is to be a normal user, reacting normally, and saying so out loud.

There’s a balance to strike. You’re describing your own experience, and clients generally don’t want a professional design review or a suggested new colour scheme. They want to see where a real person gets stuck and hear why. Some tests do ask for opinions or ratings at the end, which is the right place for them.

Tasks are usually written as scenarios. “You’re planning a weekend trip and want to book a hotel for two nights under a certain budget. Go ahead and do that.” You’re expected to follow the scenario as if it were real, while narrating. Some tasks are deliberately open-ended to see what you do first.

The skill improves with practice. And it matters a lot for pay, because the quality of your narration feeds directly into the rating system that decides how many tests you’re offered.

The screener before every test

Like surveys, usability tests start with a screener. A product team testing a banking app might want people who use mobile banking weekly. A team testing a recipe site might want people who cook at home several times a week. A business software test might want people in a particular job role.

The screener is usually short, a handful of questions. If you match, you can take the test. If not, you’re out, and screeners are generally unpaid.

Two things about usability screeners differ from survey screeners.

First, tests are often first come, first served. A client might want five or ten recordings. The platform sends the test to far more eligible testers than that, because not everyone responds quickly. Once the slots are taken, the test closes. It’s common to pass a screener and find the test is already full, or to see a test disappear while you’re reading it.

Second, the screener is where honesty has the most direct consequence. If you claim to use a product type you’ve never used, the recording will show it within a minute. You won’t know where things are, you won’t recognise the conventions, and you’ll narrate like a first-time user. The client will likely rate the test poorly or reject it, and the platform’s rating system remembers. Answering screeners accurately costs you some tests. Answering them inaccurately costs you your standing.

For the hourly maths, screener time is real time. If you spend three minutes each on five screeners to land one test, that’s fifteen unpaid minutes attached to that test’s pay. The screener load is often the biggest hidden cost in usability work, because tests are scarce relative to the number of testers and screeners are how the scarcity gets rationed.

The practice test and getting approved

Most testing platforms don’t let you straight in. You sign up, and then you record a practice test, sometimes called a qualification or sample test. It’s a short task on a sample site, recorded exactly like a real test. Someone at the platform reviews it and decides whether to approve you.

What they’re checking is mostly mechanical. Is the audio clear enough to understand? Did the recording capture the screen properly? Did you keep talking? Did you follow the tasks? Did you give honest, specific reactions, or just say “this looks nice” every thirty seconds?

The practice test is usually unpaid. It’s an investment of perhaps twenty minutes to half an hour including setup, and some people fail it the first time. Common reasons include a quiet microphone or background noise. Long silences sink plenty of attempts, as do recordings that never captured the screen because a permission wasn’t granted.

Setup is part of that investment. Most platforms need a microphone, and many need either a browser extension or a desktop app that records your screen. Mobile tests usually need a recording app installed on the phone. Some tests want your webcam too, so the client can see your face. Getting all of that working on your device, with the right permissions, can take longer than the practice test itself.

It’s worth doing the practice test carefully. Find a quiet room. Test the microphone first. Close anything that might pop up on screen. Speak a little more than feels natural. Follow every task. The approval decision can determine whether you get access at all, and some platforms don’t make it easy to retry.

Count all of this in your effective hourly rate as a one-off cost. For deciding whether to join a platform at all, it belongs in the denominator. For comparing platforms you already use, it’s reasonable to leave it out.

Why these tests pay per test

Surveys usually present a time estimate and a reward, which invites per-minute thinking. Usability tests are mostly priced per test, with a stated expected length.

That makes sense from the client’s side. They’re buying a recording that covers a defined set of tasks. Whether you do those tasks in twelve minutes or eighteen doesn’t change what they get. Most platforms set test lengths within a band, and often there’s a minimum length so the recording is useful and a maximum so the client isn’t stuck watching an hour of footage.

For a tester, per-test pay creates a trade-off. Finishing quickly raises your per-minute rate on that test. But rushing tends to mean less narration, which makes the recording worse and risks a poor rating. A test that’s done quickly but rated badly can cost you more in future invites than it saved you in minutes.

The per-test model also means the headline hourly figure depends entirely on how long you actually take. Say, as a made-up example, a test pays a fixed amount and is described as taking about twenty minutes. If you take twenty, you get one hourly rate. If the site is slow, the tasks are confusing or the recording software crashes and you start again, you might take forty, and your rate halves for that test.

Moderated tests work differently, which the next section covers. They’re scheduled for a fixed time, so their per-minute rate is more predictable, although scheduling adds its own costs.

The practical takeaway is to treat the stated length as the client’s estimate and to track your real time from the moment you open the test until the moment you submit it.

Unmoderated versus moderated sessions

Usability testing comes in two main formats, and they pay quite differently.

Unmoderated tests are the ones described so far. You get a set of written tasks, you do them on your own time, and the platform records your screen and voice. Nobody is watching live. They’re usually short, and most testers on most platforms will spend most of their time on this format.

Moderated tests involve a live researcher. You join a video call at a scheduled time. The researcher shares a prototype or a live site, gives you tasks and watches what you do, then asks follow-up questions. Sessions are longer, and they’re closer to an interview than to a recorded test.

Moderated sessions usually pay more per test, and often more per hour. The client is paying for a researcher’s time as well as yours, and each session is harder to arrange, so fewer are run. The screening can also be more thorough, sometimes with a short call beforehand to confirm fit.

They come with more overhead, though. You have to be available at a specific time, which may not fit around your day. You need a reliable connection for a video call. Some sessions get rescheduled or cancelled, and platforms differ on whether you get anything for a cancellation. And there’s often a longer screener or an application process before you’re confirmed.

For the hourly maths, count the scheduled session length, the time you spent getting set up and joined, any pre-call, and the screener. If a session runs over, count that too. If you were booked but it was cancelled at short notice and you’d arranged your time around it, that’s lost time, even if the platform didn’t pay for it.

Moderated work is where usability testing gets closest to paid interviews and focus groups. The deliverable is still behaviour on a screen, but with a person steering it.

Phone tests and clickable prototypes

A growing share of usability tests happen on phones, because that’s where many products are used. Mobile tests bring their own requirements, and they’re a common source of wasted time.

Recording a phone screen usually means installing the platform’s own app, or granting a screen-recording permission that the operating system treats as sensitive. On some phones that permission has to be re-granted for each session. Audio comes from the phone’s microphone, which picks up more background noise than a headset. Notifications are harder to suppress, because they’re part of the screen being recorded.

Some tests specify the device. A team testing an app update on one operating system has no use for a recording made on the other. Some specify a minimum screen size, or a recent operating system version. If your phone doesn’t match, the screener should catch it, but occasionally it doesn’t, and you find out partway through setup.

Prototype tests are another variation. Instead of a live site, you’re given a clickable mock-up built in a design tool. Only some parts work. Buttons that look real might do nothing, and the task instructions usually say which paths are built. Testers sometimes get confused, try a path that isn’t there, and think they’ve done something wrong. Narrating that confusion is useful to the client, since it tells them where users expected something to happen.

Desktop tests can have requirements too. Some need a particular browser because the recording extension only works there. Some ask you to share your whole screen rather than one tab. Some need a second monitor switched off so the recording isn’t confused.

All of this is setup time, and it belongs in the denominator. A test that takes fifteen minutes to do but twenty to get recording properly is a thirty-five minute test for the hourly maths. The good news is that setup gets faster once your device is configured, so it mostly hits your first few tests on a new platform or device.

The tester rating system

Almost every testing platform rates its testers. After a test, the client or the platform’s reviewers assess the recording. That rating, averaged over your history, decides how many tests you’re offered and sometimes which ones.

The criteria are usually some version of the same questions. Could they hear you? Did you keep talking? Did you follow the tasks? Did you give specific, honest reactions? Did the recording work? A high rating makes you more likely to see tests early, and to be invited to the better-paying ones. A low rating can mean fewer invites, or eventually removal.

This system gives you a lever. Most survey panels also score respondents, but their scores are built largely from automated checks you can’t see. Usability ratings come from reviews of your actual recordings, so they respond directly to how good your recordings are. Better narration leads to better ratings, which lead to more tests.

It also means one bad recording can hurt. If your microphone cuts out halfway through, or you get interrupted and forget to keep talking, a poor rating can drag your average down for a while. Some platforms let you see your rating and the feedback behind it. Read it when you can.

Ratings also interact with the first-come model. Testers with higher ratings are often notified sooner or given priority access, so they fill slots before others see them. That’s efficient for the platform and frustrating for new testers, who may see many tests close before they get a chance.

There’s no shortcut through this. The only reliable way up is accurate screeners and clean audio, plus constant narration and honest task-following. It builds slowly.

What a screen recording captures

Screen recording is the part of usability testing that deserves the most care, because the recording captures everything on screen for the length of the test.

That includes more than the site you’re testing. A notification from a messaging app slides in with a message preview. A browser tab shows your email subject lines. A saved password field autofills with your address. A bookmark bar lists personal sites. All of that ends up in a video that the client’s team may watch, share internally and keep.

Before starting any test, close every application you don’t need. Turn on your computer’s do-not-disturb mode, or its equivalent on your phone. Use a separate browser profile if you can, one with no saved logins, no autofill and no personal bookmarks. On mobile, check what’s visible in the status bar and notification shade.

Tests sometimes ask you to sign up or enter details. Read the instructions. Many provide test accounts or dummy details. If a task asks you to enter real payment information or real personal data and there’s no clear reason, you can usually stop and contact the platform, or say out loud that you won’t enter real details and use obviously fake ones instead. The client wants to see how you’d approach the form. Your card number is no use to them.

Webcam tests add your face and your surroundings to the recording. Check what’s behind you. Some testers keep a plain wall or a neutral background for this reason.

Many platforms also ask testers to agree to confidentiality terms, because you’re seeing unreleased products. Those terms usually prohibit sharing what you saw, taking screenshots or discussing the test publicly. Take them seriously. Breaking confidentiality is one of the quickest ways to lose access to a platform.

None of this affects your pay directly. It affects what you’re giving away in exchange for it.

Rejections and recordings that don’t count

Not every recording gets paid. Understanding why helps you avoid the common ones.

The most frequent cause is technical failure. The recording didn’t capture the screen, or the audio was silent because the wrong microphone was selected, or the upload failed. Platforms usually can’t pay for a recording that doesn’t exist. Checking your setup before each test, especially after software updates, prevents most of these.

The next most common cause is not following the tasks. Skipping a task, doing it on a different site, or rushing through without engaging can get a recording rejected. So can finishing far too quickly for the tasks to have been done properly.

Silence is another. A recording where the tester stops narrating for long stretches is much less useful, and some platforms treat it as unacceptable. Talking through confusion is the core of the job.

Screener mismatch is the one that tends to annoy clients most. If the test was for experienced users of a type of product and the recording shows someone who’s never used one, the client has paid for a recording they can’t use.

Occasionally, rejections are unfair. A client might reject a recording because they didn’t like the feedback, or because their own tasks were broken. Most platforms have a support process for disputing rejections. Use it calmly and with specifics, and you may get it overturned.

For the hourly maths, a rejected test is time spent for no pay. Count the minutes, count zero on the top line. If rejections happen often, the effective rate will show it, and that’s a signal to look at your setup or your narration before anything else.

The waiting time between tests

Usability testing has a supply problem that affects the real hourly rate more than any per-test figure does.

There are many testers and relatively few tests. Each test only needs a handful of recordings, and those slots are rationed through screeners, first-come access and rating-based priority. The result is that many testers spend more time looking for tests than doing them.

Checking a dashboard once an hour and finding nothing barely counts as working. Sitting and watching it for a notification does count. Where you draw the line is your call, but draw it consistently. Some testers keep two versions of their hourly rate, one counting only screeners and tests, the other counting time spent actively watching for work.

Notifications help. Most platforms send email or app notifications when a test you might match becomes available. Acting quickly on those matters because of the first-come model. That’s why this work suits people who’re usually near a device with a quiet space nearby, and suits less well anyone who can only test at a fixed time each evening.

Supply also varies by profile and region. Product teams test in markets they sell into, and many of the busiest testing platforms draw heavily from a few large markets. Testers elsewhere may see fewer tests or only those in English. Business software tests look for people in specific roles. Mobile tests need particular devices.

This is why two testers on the same platform can report wildly different experiences. One gets several tests a week. The other gets one a month. Neither is necessarily doing anything wrong. They’re just matched to different demand.

Working out what a test really pays

The per-test rate on a usability test is a real number, and it’s a different number from your hourly rate. To get that, you need the same method used for any research: total cash received divided by total time spent, over the same period.

Here’s a made-up example to show the arithmetic. None of it describes a specific platform.

Say that over a month you spend two and a half hours on screeners across twenty attempts, and pass eight. Of those eight, three had already filled by the time you opened them. You complete five tests. Four are unmoderated, each described as twenty minutes, and your actual times come to 25, 22, 30 and 18 minutes, 95 in total. One is a moderated session scheduled for forty-five minutes, which ran to fifty, with ten minutes of setup before it. One unmoderated test is rejected because the audio didn’t record.

Total time: 150 minutes of screeners, 95 minutes of unmoderated tests and 60 minutes around the moderated session. That’s 305 minutes, or just over five hours.

Now the pay. Suppose each unmoderated test pays a flat 10 dollars and the moderated session pays 30. Three unmoderated tests were accepted, so that’s 30 dollars, plus 30 for the moderated session. Sixty dollars.

Sixty dollars over just over five hours is roughly 11.80 an hour. The headline figure on an unmoderated test in this example was 10 dollars for 20 minutes, which reads as 30 an hour. The gap is screeners, filled slots, a rejection and tests that ran long.

Those are invented numbers. Your real ones will depend on your profile, region, rating and how many tests you can get. But the structure of the gap is typical.

How this compares with other research formats

Usability testing sits in an interesting place among paid research options.

Compared with online surveys, the per-test pay is usually larger and the tasks are often more engaging. You’re doing something rather than rating things. But supply is much tighter, and screening is still unpaid. Where a survey panel might offer something most days, a testing platform might only have a test for you occasionally.

Compared with focus groups and paid interviews, unmoderated tests are shorter and more flexible. You can do one whenever it arrives, without scheduling. The per-test pay is usually lower. Moderated usability sessions are closer to interviews in pay and format.

Compared with in-home product tests, usability tests are quicker and involve no physical product. They also take more of your immediate attention, because you’re performing on camera while the test runs.

Each format has different hidden costs. For surveys, it’s screen-outs. For focus groups, it’s scheduling and travel. For product tests, it’s the days of use and the diary. For usability tests, it’s screeners, filled slots and the waiting.

That’s why comparing formats by headline pay is misleading. The only fair comparison is effective hourly rate over a few weeks, calculated the same way for each. For some people, usability testing comes out as the best-paid research they do. For others, the scarcity makes it barely worth checking.

What to do if you want to try it

Start with the setup, because most early problems are technical. Get a decent microphone, even a basic headset, so your voice is clear. Find a quiet space. Install whatever recording software the platform needs and test it before your practice test.

Take the practice test seriously. Narrate constantly, follow every task and keep the screen clean. It’s the gate to everything else.

Answer screeners honestly. A test you can’t do well is a test that damages your rating. Losing a test at the screener is cheaper.

Protect your screen. Separate browser profile, notifications off, other apps closed. Use dummy details whenever a task asks for personal information without a clear reason.

Keep a simple log with the date, screener time, whether you passed, whether the test was still open, test time, and whether the recording was accepted. Add the cash that actually lands each week. After a month, divide.

Then decide. If the effective rate is worth it to you, keep going and let your rating build. If it’s too low because of scarcity, it’s still worth staying signed up and acting on the occasional notification, since the tests themselves can be decent pay for the minutes spent inside them.

Keep expectations grounded. Usability testing is a way to get paid reasonably for spare time when the work turns up, and almost nobody gets a full-time income from it, because there simply aren’t enough tests.

For more on how research pay actually works, from screen-outs to account health to getting paid, head back to the Survey Farm home page.