Real user research, ready by this afternoon
Cast a panel of actors to work through your product in a real browser and report what they did, where they stopped and why. Screenshots attached.
The same tasks you would give a person
Five actors ran this guide at the same time. The round took an afternoon.
Parlour is a demo app simulating a restaurant booking flow. Every capture on this page is from a study run against it.
Actionable insights
When the last session ends, the interviews are synthesised into themes, each backed by the evidence behind it: the sessions it cites, their quotes, the screenshot of every moment, and a highlight video cut from the sessions.
Guests need the full cost before commitment
3 of 5- First-time diner
The deposit only became clear at the last step.
- Guest booking in another currency
The amount needs an AUD label before payment.
- Sceptical venue manager
- First-time diner
Confirmation must support the next service moment
3 of 5- Regular who knows the shortcuts
- Screen-reader guest
- Sceptical venue manager
Staff need those requests surfaced as structured service notes.
Selection state is not equally perceivable
1 of 5- Screen-reader guest
The selected time was not announced.
- Screen-reader guest
From a question to a report in five steps
We take care of the parts that slow research down. The parts that make it good are still yours.
Step 1: Start with a question
Should the new signup ship? Which pricing page do we keep? Start with the decision you need to make, and the findings will point you to it.
Step 2: Pick who you want to hear from
Someone opening your product for the first time on a phone. A regular who knows every shortcut. Someone using a screen reader, or paying in another currency. Every actor keeps their personality, device and memory from one round to the next.
Step 3: Ask what you want to know
Add your questions and the tasks you want them to try, or paste in your brief and edit what we draft for you. Whatever is in the guide is what gets asked.
Step 4: Point it at your product
Production, staging, a preview deploy, a Figma prototype or a Claude artifact. Give actors a login and they will sign in, and each one has an inbox for the confirmation code that follows.
Step 5: Read the findings, then run it again
Ship the fix and run the same guide again. Actors remember the last round, so you can see exactly what changed instead of starting from scratch.
Five interviews, running at once
Participants run side by side rather than one after another, so a five-person round takes an afternoon. Transcripts arrive as they happen.
What comes back from a round
Hours, not weeks
There is nothing to screen, schedule or chase up. Sessions run side by side, and the report starts the moment the last one ends.
Compare round to round
Run the same guide on the next build with the same panel, and you can see what actually improved.
Cast the users you could never recruit
A screen reader user. A slow phone. Another country, another currency. Someone who has never heard of your product. Adding one is adding an actor.
Proof you can stand behind
Every theme comes with its sessions and screenshots, and every recommendation with the step it came from, so your findings hold up when someone asks how you know.
Answers before you build
Test a Figma prototype and catch the confusing parts while they are still cheap to change.
Works where you already work
Start a study from the dashboard, from Claude, from Slack or from any MCP client, and send the findings straight to Linear.
Where the week goes
A five-person round, step by step: a recruited panel beside Stunt Double.
- Recruit five participants
- Recruited panel5 to 10 daysStunt DoubleA few minutes
- Schedule and run the sessions
- Recruited panel1 to 2 weeksStunt DoubleA few hours, all at once
- Transcribe and tag
- Recruited panel2 to 4 daysStunt DoubleAs it happens
- Write up the findings
- Recruited panel3 to 5 daysStunt DoubleReady when the last session ends
- Run it again after a fix
- Recruited panelStart overStunt DoubleRun the same guide again
- Add a hard-to-find participant
- Recruited panelA new recruitment briefStunt DoubleAdd another actor
Your next user is an agent
Some of what goes through your signup, checkout or booking flow is already an agent acting for a person: a shopping assistant, a browser agent, an automation filling the form. It reads your labels, follows your focus order and gives up on the same steps a screen reader does. Nobody is watching it try.
Cast an agent as the user
An actor is an agent driving a real browser. Give it the task an assistant would be given, and watch it attempt your flow: every page, every field, and the step where it stops.
Observable orchestration
Every run is a sequence you can read: the pages it opened, the actions it took, the decisions it made and the moment it gave up, with a screenshot at each step. Put a checklist in the deploy loop and it runs on every change.
Serve both kinds of user
The fixes are mostly the same ones that help a screen-reader user: labels that say what a control does, selection that is announced, costs shown before commitment. One round finds them for people and agents at once.
See how agents already experience real websites, on the Stunt Double Index
Make every conversation with a customer count
Let actors cover the ground first, so the time you spend with real people goes on the questions only they can answer.
Actors enable
The answers you can get today, before you book a single call.
- Onboarding, signup, checkout and finding your way around
- Whether people understand your pricing
- Copy, labels and error messages
- Prototypes and preview builds, before you have users to ask
- Accessibility, devices and locations
- Checking that a fix actually fixed it
- Finding the questions worth asking a real person
More impactful conversations
The conversations that are worth their time, and yours.
- Whether they would actually pay, and how much
- Deep expertise you cannot write down, like a radiographer or a bond trader
- Culture and emotion, when that is what the decision turns on
- The follow-up questions your synthetic round surfaced
Questions people ask
Is this the same as asking a chatbot what it thinks of my site?
No. A chatbot reads your page and gives you an opinion. An actor opens a real browser, works through your guide, presses your real buttons and runs into your real errors. Then it tells you what happened, and you can watch the session yourself.
How realistic are the actors?
Each one has a background, a location, a device and things they already know, and you can add to that: research you have already done, common support questions, a customer segment. Use the same panel across studies and your results stay comparable over time.
What can I test?
Anything with a link. Production, staging, a Vercel preview, a published Figma or Figma Make prototype, a Claude artifact or a v0 link. Actors can sign in with a login you give them, and each has an inbox for confirmation emails and one-time codes.
How long does a study take?
Participants run at the same time rather than one after another, so a five-person round takes an afternoon. Transcripts come in as they happen and the report is ready when the last session ends.
Can I collect feedback from my own team and stakeholders too?
Yes, with inline comments. Add one script tag to your site or staging environment and anyone reviewing a page can press c, click the thing that confused them and say why. Each comment arrives pinned to that exact spot, with a screenshot of what they saw, the page, the screen size and the build. It all lands in the same place as what your actors found, so you have one list to work through rather than two.
Does this replace talking to customers?
It makes those conversations count for more. Actors take care of the ground work, so by the time you sit down with a customer you already know where people stall and what confused them, and you can spend the hour on the questions only they can answer.
Run your first study
Five participants, one afternoon, and the report when the last session ends.