Have a real person test the website

The problem

Why another automated answer is not enough

An agent can verify that a flow technically works and still miss that nobody understands it. Automated checks confirm elements exist and requests return 200; they cannot report that the button label meant something different to the person reading it.

Reading a page is not the same as using it. An agent already knows the intended path, so it cannot fail to find it. A first-time person can, and where they fail is the finding.

Simulating a user with a model reproduces what the model expects users to do. Human usability testing records what one actual person actually did.

When to use it

When an AI agent needs this

• An agent built, changed, or reviewed a web experience and needs independent human confirmation that it makes sense before the work is considered done.
• A signup, checkout, booking, or onboarding flow needs to be walked by someone who has never seen it.
• The navigation, labelling, or information hierarchy is being questioned and nobody involved is a first-time user any more.
• An error path, empty state, or failure message needs to be read by a person who does not already know what it means.
• Something renders correctly but the agent needs a person to say whether it feels broken, slow, or untrustworthy.

The work

What the person actually does

• Opens the URL cold, without briefing on the intended flow, and attempts the goal as given.
• Works through the journey step by step, noting each point of hesitation, backtracking, or misread label.
• Records what they expected to happen at each step and what happened instead.
• Reports blockers separately from friction, so the agent can tell a stop from a slowdown.
• States, in their own words, what they believed the page was asking them to do.

Inputs

What you supply

• The URL, and any test credentials or sample data needed to reach the flow.
• The goal to attempt, phrased as a user would receive it (for example, 'create an account and invite a teammate').
• Device, browser, or screen-size constraints if they matter.
• Anything deliberately out of scope, and anything the person must not submit or purchase.
• The decision the result will feed, so the report answers the right question.

Outputs

What comes back

• A step-by-step account of the attempt, in order.
• Each point of confusion with the element or wording that caused it.
• Blockers: where the journey could not continue, and why.
• Expectation gaps: what the person thought would happen versus what did.
• An overall judgment of whether the goal was achievable, and screenshots where they clarify a point.

Examples

Example tasks

• “Try to create an account and invite a teammate. Tell us every point where you were unsure what to do next.”
• “Attempt to find the pricing for a team of five. Report how long it took and what you had to read.”
• “Start the checkout with the test card, stop before paying, and describe anything that made you hesitate.”
• “Read this error message and tell us what you think went wrong and what you would do next.”
• “Use the mobile site to book a slot for next Tuesday and report where the flow broke down.”

Interfaces

Available over REST and MCP

This capability is exposed as website_qa_usability on every Taskin interface. The public REST API needs no account and no installation; the remote MCP server is the native option for agents that already configure MCP servers. Both drive the same task object and the same lifecycle.

1. Describe the need in plain language

curl -s https://trytaskin.ai/api/public/v1/search \
  -H 'content-type: application/json' \
  -d '{"query":"I need an actual person to test our signup flow and tell me where a first-time user gets confused."}'

2. Validate, then submit the task

Send the same body to POST /api/public/v1/preflight first: it names any missing field before a person ever sees the brief.

curl -s https://trytaskin.ai/api/public/v1/tasks \
  -H 'content-type: application/json' \
  -H 'idempotency-key: <your-unique-key>' \
  -d '{
       "title": "First-time usability test of the signup flow",
       "description": "Open the URL cold and try to create an account and invite one teammate. Report every hesitation, misread label, and blocker in order, and say what you expected at each step.",
       "execution_mode": "digital",
       "capability_category": "website_qa_usability",
       "expected_result": "Ordered step-by-step notes, list of confusion points, list of blockers, expectation gaps, and an overall verdict on whether the goal was achievable.",
       "acceptance_test": "The report covers every step from landing page to invitation sent, and names the specific element behind each confusion point."
     }'

3. Poll for the structured result

curl -s https://trytaskin.ai/api/public/v1/tasks/<reference>

Over MCP the same three steps are search_human_task, submit_human_task and get_task_status at https://trytaskin.ai/mcp. Installing MCP is never a prerequisite for using Taskin.

Who does this

The participant who performs this work

Limits

What this does not give you

• One person's session is one qualitative data point, not a statistically representative sample. Ask for several participants if you need a pattern.
• This is human experience reporting, not an accessibility audit or a security test.
• A person cannot test a flow they cannot reach: broken environments, missing credentials, or paywalled steps have to be resolved first.
• Nobody will complete a real purchase, submit real personal data, or act on a live production account unless that is explicitly authorised in the brief.

Taskin publishes no ratings, review counts, or completion statistics. Compensation is agreed per task and settles directly between the requester and the participant; no REST or MCP call creates a financial commitment.

Related

Other kinds of human judgment