The real test of any feature isn’t whether it works — it’s whether people can use it.
You can build the most technically perfect setting in the world, but if users can’t find it, understand it, or trust what it does, it might as well not exist. That’s why good software design is empathetic: anticipating what people expect, how they navigate, and where they get lost.
For a long time, that empathy has been something only humans could supply. But what if we could simulate it?
What if, in addition to generating and running acceptance tests, our AI agent could step into the shoes of different users — exploring the interface not as a well-informed software tester, but as an end user trying to figure it out for the first time?
That’s the idea behind synthetic users.
Giving the Agent a Persona
Each user brings their own assumptions, habits, and quirks to an interface. Some are confident experimenters who click everything just to see what happens. Others are cautious, afraid of breaking something. Some skim text; others read everything twice. Some work fast; others carefully.
By giving the agent personas that emulate these differences, we can start to explore usability from multiple perspectives — without needing a live user in the loop.
A persona might represent a technically savvy developer, a visually impaired user relying on a screen reader, a non-native English speaker, or someone impatient and prone to abandoning tasks quickly. Each persona can be defined by a small set of behavioral parameters, such as:
- Technical ability — how much the user knows about WordPress or Divi.
- Accessibility requirements — whether they prefer text labels, tooltips, or structured navigation.
- Cultural and language factors — dictating which words feel intuitive or confusing.
- Personality traits — such as persistence, confidence, or risk tolerance.
Once equipped with this persona, the agent can begin a test not as an omniscient developer, but as a user on a mission.
It can describe, in its reasoning output, what it expects to find:
“I’m looking for a setting that hides arrows — it might be under layout or elements.”
It can narrate its confusion when things aren’t where it expects:
“There’s a toggle labeled ‘Show Slider Arrows,’ but it’s under a section called ‘Elements,’ which I didn’t expect. I almost missed it.”
And it can even decide when to give up:
“I can’t locate any control related to arrows within two levels of navigation. This feature feels hidden.”
The same test generation process that used to confirm functionality can now also surface friction.
Turning Tests into Usability Sessions
In essence, this transforms a standard acceptance test into a synthetic usability session. Instead of simply verifying that a feature works, the test observes how it’s found and understood.
Run once, the test gives technical assurance. Run ten times, with ten personas, it gives insight into usability.
Each run becomes a conversation between the agent and the interface — a dialogue that reveals what parts of the design are intuitive and what parts aren’t.
If every persona stumbles in the same place, it’s not a coincidence. It’s a design signal.
These runs could even be compared statistically. You might find that advanced users complete the task in two steps, while novice users take five. Or that users with accessibility constraints fail to find the setting altogether.
Those patterns, distilled from synthetic experience, can then guide how you design your next feature — what to rename, what to relocate, what to simplify.
AI-Driven Feedback for Better Design
One of the most immediate uses of synthetic users is in naming.
Naming settings in WordPress plugins is harder than it sounds. A name that makes sense to you as the developer may not be what users search for. For instance, “Hide Gallery Arrows” and “Show Slider Arrows” describe the same thing, but they evoke different assumptions.
A persona-based agent can test this directly. If most personas search for “hide arrows,” it’s a hint that the label should match that phrasing — or at least include it in the description.
The same applies to placement. If multiple personas go looking for the setting under “Layout” instead of “Elements,” it might be better placed there.
And because each persona writes out its reasoning, this feedback isn’t abstract. It reads like a usability transcript:
“I expected to find this option in the layout section since it affects the gallery’s appearance.”
“I didn’t understand that ‘arrows’ referred to navigation buttons until I saw the hover effect.”
This kind of feedback loop turns the test agent into a collaborator in design — a critic that sees your work through a variety of simulated eyes.
Exploring Variation and Choice
Synthetic users can also help compare alternatives.
When you have multiple candidate implementations — perhaps two ways to present the same control, or different default settings — you can run the same test across personas and measure which version leads to fewer dead ends or misunderstandings.
Maybe the first design passes the technical test but confuses impatient users. The second takes an extra click but feels clearer. The choice, then, becomes data-informed rather than speculative.
By the time you make your decision, it’s not just about what you think feels right — it’s about what a diverse population of simulated users experiences.
Toward More Empathetic Automation
What emerges from all this is a fascinating irony: by teaching machines to simulate people, we can make software that feels more human.
The goal isn’t to replace real usability testing — synthetic users won’t capture the emotional subtleties or creative adaptability of real humans. But they can augment it, providing a constant stream of structured insight that helps spot friction early and cheaply.
For a solo developer, that’s game-changing. It means usability testing isn’t a rare event; it’s a continuous, automated process woven into the act of building.
And over time, those synthetic voices — narrating their searches, their assumptions, their frustrations — start to shape your own design intuition. You begin to anticipate where confusion will arise, long before a user ever writes to support.
The same mechanism that once verified correctness now helps ensure clarity. And the AI that once learned to see your software can now help you learn to see it as others do.