Usability testing with real people is one of the most valuable things you can do for a website, and one of the most often skipped, because it takes time to recruit, run and analyse. AI personas, sometimes called synthetic users, promise to test a site in minutes, on every build. They're genuinely useful, but they're not a replacement for people. Here's what each can tell you, and how to use both.
What synthetic users are
A synthetic user is an AI agent given a persona and a goal. For example: "a busy parent on a phone, booking a Saturday swimming lesson." It navigates your site like a visitor would and reports where it hesitated, got confused or gave up, often with screenshots.
Run several personas, each modelled on a real audience segment, and you get a quick read on whether your key journeys work.
What synthetic users are good at
- Speed and frequency. They can test every staging build, not once a quarter.
- Obvious friction. Unclear labels, hidden buttons, confusing navigation, broken flows.
- Consistency. The same persona tests the same journey the same way each time, so you can compare builds.
- Coverage. Many journeys and devices, cheaply.
- Catching regressions. Spotting when a change broke something that used to work.
What they can't tell you
- Real motivation. Why someone would choose you over a competitor, or not.
- Emotion and trust. Whether the site feels credible, warm or intimidating to a real person.
- Context. The distractions, doubts and constraints of real life.
- Surprises. Real people do unexpected things that reveal assumptions you didn't know you'd made.
- Language nuance. How your audience actually describes their problem.
Side by side
| Synthetic users | Real usability testing | |
|---|---|---|
| Speed | Minutes | Days to weeks |
| Cost per round | Low | Higher |
| How often | Every build | A few times a project |
| Finds | Mechanical friction, regressions | Motivation, trust, surprises |
| Risk | False confidence if used alone | Too infrequent if used alone |
How to combine them
- Use synthetic users continuously to clear obvious problems before anyone else sees a build.
- Fix what they find, so real sessions aren't wasted on broken buttons.
- Run small real rounds at key points: after the first clickable prototype, before launch, and after major changes. Our guide to running a usability test on a small budget shows how.
- Feed real findings back into your personas, so they get closer to your audience over time.
Making personas useful
Personas are only as good as what they're based on:
- Ground them in real data: analytics, customer interviews, support tickets.
- Give each a specific goal and device.
- Include accessibility needs, such as keyboard-only navigation or low vision.
- Review their reports critically; treat them as leads to investigate, not verdicts.
Writing a good persona brief
A synthetic user is only as useful as its brief. A template:
| Field | Example |
|---|---|
| Who | A 38-year-old parent of two, first visit, on an older Android phone |
| Context | Booking a swimming lesson during a lunch break, ten minutes spare |
| Goal | Book a Saturday morning lesson for a six-year-old |
| Knows | Roughly what lessons cost locally; nothing about this school |
| Worries | Whether there's parking; whether they can cancel |
| Constraints | Slow mobile connection; won't create an account unless necessary |
| Success | A confirmed booking with a date, time and price |
Five briefs like this, each based on a real audience segment, cover most of a small business's visitors.
What a useful synthetic report looks like
A good report is specific enough to act on:
- Task: Book a Saturday lesson
- Result: Completed, slowly
- Hesitations: 12 seconds on the timetable page looking for Saturday; the day filter is below the fold on mobile
- Confusion: Price shown per term on one page, per lesson on another
- Gave up? No, but considered calling instead
- Screenshots: timetable page, pricing page
Each point becomes a ticket. Vague reports ("the site is a bit confusing") aren't worth much from AI or people.
Running a five-person usability round
When it's time for real people:
- Recruit five people who match your audience, not colleagues or friends who know the business.
- Write three or four tasks as realistic scenarios, not instructions.
- Ask them to think aloud as they go.
- Don't help. Note where they struggle, what they say and what they expected.
- Record the sessions (with permission) so the team can watch.
- Fix the biggest issues, then test again with five new people.
Remote sessions over video work well and keep costs down. Our guide to usability testing on a small budget goes into recruiting and scripts.
When to use which
| Situation | Best choice |
|---|---|
| Every new staging build | Synthetic users |
| Checking a fix worked | Synthetic users |
| First clickable prototype | Real people |
| Before launch | Both |
| Choosing between two design directions | Real people |
| Regression after a big change | Synthetic users, then real people if issues appear |
Watch out for false confidence
The biggest risk with synthetic users is believing a site works for people because it works for AI. Treat a clean synthetic report as "no obvious problems", never as "users will love it". Pair it with an accessibility check and real feedback.
How we use them at Zelvorm
Zelvorm's Ghost Users are five AI personas modelled on each client's real audience. They try the key journeys on every staging build and report where they hesitate or give up, with screenshots, so the team fixes friction before the client's review, and real user testing can focus on the questions only people can answer.
The short version
Synthetic users are fast, frequent and good at catching mechanical friction. Real usability testing reveals motivation, trust and surprises. Use AI personas on every build to clear the obvious, and small rounds with real people for what matters most.
