How Stunt Double compares
A script checks the selector you wrote. A panel takes weeks to book. An actor opens your checkout in a real browser this afternoon and shows you the screen where it stopped. Here is where each approach fits, and where ours does not.
What an actor does differently
An actor is an AI user with its own browser, inbox and session. Three things follow from that.
Behaviour, not opinions
An actor opens your product in a real browser, with its own inbox and session, and does the task. What comes back is what it did.
Evidence on every step
Each check and each finding carries the screenshot of the moment and the reasoning behind it, and the whole run is recorded.
The same run, again
A checklist or an interview guide runs again after a fix, on a schedule, or on every deploy, without recruiting or rewriting anything.
Six approaches, side by side
Each of these answers a different question, and most teams need more than one. So which question are you asking?
Recruited usability testing
Moderated and unmoderated sessions with a recruited panel
- What it does well
- Real people with real stakes. It is the only way to learn whether someone would pay, or how a specialist reads your product.
- Where it stops
- Recruiting, scheduling, running and writing up a five-person round takes weeks, and a re-test after a fix starts over.
- With Stunt Double
- Actors cover the ground first, in an afternoon, so the sessions with people go on the questions only people can answer.
Scripted end-to-end tests
Playwright, Cypress and similar frameworks
- What it does well
- Fast, deterministic and cheap to run in CI. A script asserts exactly the same thing on every commit.
- Where it stops
- Someone writes and maintains every selector, and a script checks only what it was told to. It does not notice a confusing label or a step a person would abandon.
- With Stunt Double
- Keep scripts for exact assertions. Checklists cover requirements written in plain language, with a screenshot and the reasoning for each check, and no selectors to maintain.
Manual QA and bug bashes
A person clicking through the release before it ships
- What it does well
- A person notices what nobody wrote down, and judges a flow as a whole.
- Where it stops
- It does not scale to every deploy, locale and viewport, and what it finds lives in a spreadsheet or in somebody’s memory.
- With Stunt Double
- Stunt Double takes over the repeat passes. A checklist runs the same requirements on every deploy or on a schedule, from the cities and devices you pick, and keeps the evidence of each run.
Session replay and product analytics
Funnels, heatmaps and recordings of real traffic
- What it does well
- Real behaviour from real customers at scale, with the numbers to show what changed after a release.
- Where it stops
- It needs traffic, so it says nothing about a prototype or a preview build. It shows where people dropped off, not what they were trying to do.
- With Stunt Double
- Use actors before launch and on every preview deployment. Once analytics shows a drop-off, run a checklist against that page to reproduce it.
Survey-style synthetic personas
A language model asked to answer as a persona
- What it does well
- Instant and cheap for an early read on a concept, a message or a name.
- Where it stops
- The persona describes what it would do. It never opens the product, so there is no click, no stuck moment and no screenshot to check.
- With Stunt Double
- Actors drive a real browser through the real product and report what they did, with a screenshot of every step.
Design critique and expert review
A colleague or consultant reviewing screens against your standards
- What it does well
- Experienced judgement, with the context of your brand and your roadmap.
- Where it stops
- It depends on who is free this week, and standards drift between reviewers.
- With Stunt Double
- Design reviews apply your guidelines the same way every time, on a page or a Figma frame. A person still decides what to act on.
When Stunt Double is the wrong tool
Actors are good at using a product and showing their working. These jobs need something else.
Code with no URL to visit
An actor needs a page to open. For a function or a service with no interface, unit and integration tests are the right tool.
Load and performance testing
An actor is one user in one browser. It will not tell you what happens when 10,000 arrive at once.
Exact assertions on every commit
A run takes minutes. When a check has to be exact and finish in seconds, keep it in your test suite.
Statistically significant evidence
Actors show you where a flow breaks. Whether a change moves conversion for real customers is a question for an experiment on real traffic.
Willingness to pay
Whether people would pay, and how much, needs a person with a budget.
Expertise and emotion
Deep expertise you cannot write down, like a radiographer or a bond trader, and decisions that turn on culture or emotion, need the real people.
Try it on one flow
Pick the flow you check by hand most often. Let an actor check it instead.