User testing

Usero user testing is unmoderated and link-shared. You write a short task list, share an unguessable link, and the participant works through it on their own while Usero records their screen and microphone. When they finish, the screen replay and the audio are stitched together in the dashboard, transcribed, and analyzed, sitting next to the task checklist and the participant's note.

Be clear on the boundaries before you set one up:

• Unmoderated only. There is no live interview mode, no scheduling, and no moderator-present session. The participant runs the task list alone.
• You recruit. Usero gives you a share link. It does not provide a participant panel or a recruiting marketplace. You bring the participants.
• The reward is a manual ledger, not a payout rail. You set an amount and mark a session paid. Usero does not move money; you settle up off-platform (a gift card or a transfer).

1. In your project, open User tests and create a new test.
2. Give it a name, and write your task prompts (up to 20). These are plain text shown to the participant on screen as guidance. Tasks are guidance only and do not gate the reward.
3. Optionally set a reward: a flat amount and currency per completed session. This is what you intend to pay each participant; see Rewards for how payment actually works.
4. Optionally set an allowlist of participant emails (one per line, or comma-separated). When set, only those emails can start the test; everyone else is turned away. Leave it empty to let anyone with the link start.
5. Save. Usero gives you a share link at /ut/<slug>, where <slug> is unguessable.

Each test counts once, when you create it, against the monthly amount of user tests with real people on the plan of the project's owner. Participants are unlimited, so a test keeps taking sessions after the amount is used; only new tests wait for the reset on the 1st or an upgrade.

Send the /ut/<slug> link however you already reach users: an email, a DM, a message to a power user, a post to a small group. There is no built-in invite send and no panel, so distribution is yours.

What the participant sees:

1. The entry screen with the test name, the task list, and a consent checkbox.
2. They enter an email and tick consent. The page tells them their mic stays on until they tap Finish, even if they switch tabs or apps. If you set an allowlist and their email is not on it, they are turned away here.
3. They click Start. Usero begins recording the screen and asks for microphone access.

While the test runs, Usero captures two streams in parallel:

• Screen, via rrweb, the same engine behind Usero session replay. The DOM and events are recorded and replayed as a synced timeline, not as a video file.
• Microphone, flushed as audio chunks every few seconds to storage and concatenated into a single track when the session ends.

The microphone keeps recording when the participant switches to another tab or app, until they tap Finish. If the browser stopped the mic in the background (iOS does this), it restarts when they come back, in the same session and without a second permission prompt where the browser allows it. If it can't restart, the recording pill says "Mic blocked, tap to retry" or "Mic stopped, tap to resume" instead of "Recording", and tapping it tries again. Leaving the page and coming back, for example through a sign-in redirect, also continues the same session and picks the mic back up. This needs @usero/sdk 1.6.2 or later. Older versions stop the audio the first time the test tab is hidden, while the pill still reads "Recording".

During the test the participant can:

• Mute a segment of audio (the muted spans are recorded so the player can skip them).
• Drop a timestamped note at any moment, for "this is where I got stuck" markers.
• See the task prompts on screen as guidance.

The participant consents before any recording starts. Mask or exclude sensitive parts of your own UI with the same rrweb attributes the widget uses (data-usero-mask, data-usero-block); see the session replay docs for the masking reference.

Open a finished session in the dashboard to see the full picture:

• Synced replay + audio. The screen replay and the concatenated audio play together, so you watch what the participant did and hear what they said at the same moment.
• Transcript and AI analysis. The audio is transcribed and analyzed, so you can read the session and get a first pass at the themes without scrubbing the whole recording.
• Task completions. The tasks the participant self-reported completing, as a checklist. (Self-reported, and not a gate on the reward.)
• Participant notes and the end-of-session note, with timestamps that jump the player to the moment.
• Session metadata. Duration, and approximate location (country and city) from the request.

When the analysis for a session completes, its friction findings are filed into the feedback inbox automatically. The rules:

• Only friction files. Pain points, and observed behaviour where the product misbehaved, become inbox items. Praise, feature ideas, and neutral descriptions stay on the session page so the inbox keeps its signal.
• Every filed finding carries a severity (high, medium, or low). A finding the analysis would not put a severity on is not filed.
• Each finding links to its moment. The finding opens the session replay at the second the participant hit the problem. A finding with no identifiable moment is filed without a replay link rather than a made-up one.
• Findings are ordinary feedback. They attribute to the participant's email, show user-test as their source, and cluster with the same problem reported through your widget, Slack, or forms.
• At most one auto-PR per session. The highest-severity finding (high or medium only) can open a pull request unattended; every other finding keeps its manual Create PR button. Re-running the analysis does not file duplicates.

Once a test has finished sessions, their transcripts are searchable from Claude Code, Cursor or any other client connected to the Usero MCP server. The search_user_test_transcripts tool takes a test id and a phrase and returns the verbatim transcript segments that contain it across every session, with the line before and after for context, a replayAtMs for each, and a link that opens the session replay at that second. Filed insights whose title, description or quote matches come back alongside. It returns quotes, never a generated answer, so a claim like "three of five participants missed the export button" is grounded in lines you can click through to.

{
	"name": "search_user_test_transcripts",
	"arguments": {
		"clientId": "client_abc123",
		"testId": "ut_checkout_flow",
		"query": "cookie banner",
		"limit": 5
	}
}

For one session in full, call get_user_test_session with fullTranscript: true to get the whole transcript and its timed segments instead of the 2,000-character excerpt.

The reward flow records what you owe and lets you mark it settled. It does not transfer money.

1. You set a flat reward amount per test when you create it.
2. When a session finishes with audio, it moves to ready to pay. (Very short or mostly-muted recordings are flagged so you can review them before paying.)
3. The participant picks a payout destination (an email, for a gift card or transfer you send).
4. You click Pay on the session, which marks it paid and stamps the time. No money moves; you send the gift card or transfer yourself, off-platform.

Treat the reward field as a record of what you owe each participant, not as a payment rail. If you need automated participant payouts, a dedicated research platform is the better fit.

On a paid test you can switch on Referrals under the reward. You add referrers (anyone, tester or not), Usero emails each of them a link to your open tests, and they earn a bonus you set for every person they send who you pay. Bonuses use the same manual ledger as rewards. Setup, caps, fraud checks and the MCP tools: Referrals for user tests.

A test session is feedback like any other in Usero. A usability problem the test surfaces is classified and clustered with the same problem reported through your widget, Slack, forms, or imported GitHub issues. From a cluster you can open one GitHub pull request with a first pass at the fix:

1. Make sure GitHub is connected.
2. Open the cluster and click Create PR. Usero clones the repo, writes the change on a branch, and opens a pull request that links back to the feedback.
3. Review the diff like any other PR. Your CI runs, your reviewers comment, and you merge it through your own branch protection. Usero never merges for you.

• Referrals for user tests
• Session replay (recording engine + masking)
• Feedback clustering
• GitHub integration (AI pull requests)