When a page is ready, most teams are asking the same question: what will someone do when they land here for the first time? The best answer comes from talking to real people. But that takes recruiting, scheduling and budget, and sometimes the page has no traffic yet, so there's no visitor data to look at either. In that gap, teams tend to rely on their own eyes.
Short answer: User simulation means a visitor you describe goes through your site in a real browser, says what they're thinking at each step, and answers your questions at the end. We find it useful before real research, on pages with no traffic yet, and on projects with no research budget at all. Its value lies in seeing how different personas react and using those reactions to develop ideas and hypotheses. A simulation gives you hypotheses, not results, and it doesn't replace talking to real users.
We run our simulations with Rubric, so that's the tool we refer to here. Rubric is our own company's product and this feature is still in beta, which is worth knowing before you read the rest.
When do we use user simulation?
We turn to simulation in three situations.
Before real research. On enterprise projects, it can take a while for the interview schedule to come together. In the meantime, a simulation gives the team a starting point for working out which questions to take into those interviews.
When a page has no traffic. A new page or flow has no measurement data yet, because there are no visitors to observe. This is where simulation fits best.
When there's no research budget. Not every project can fund research with real users. Simulation doesn't make up for that, but it's better than having no outside perspective at all.
In all three situations, what a team usually has to hand is its own opinions and its stakeholders' comments. Those opinions are valuable, but they all come from people who already know the product. The things that trip up a first-time visitor are often simple: a cart with no visible link, a form that only says "Invalid input", a price that can't be found.
What is user simulation?
A synthetic user is a simulated visitor. You describe who they are, and they move through public pages in a real browser, say what they're thinking at each step, and answer your questions at the end. The resulting record looks a lot like a think-aloud session from a usability test.
That's where the similarity ends. There's no real person involved, and a simulated visitor produces a plausible reaction based on the profile you wrote. So its words are best read as pointers to places worth looking at, not as evidence. We look at where synthetic users fit in research more broadly in how to do UX research with AI. A simulation doesn't test your product; it surfaces the questions worth testing. It gives you hypotheses, and real users make the product decisions.
Why does the real value lie in different personas?
What one simulated visitor says is a single point of view. Send different personas through the same page, though, and their comments begin to diverge. The reassurance an enterprise manager looks for, the step that stops someone who isn't comfortable with technology, and the message missed by someone who only glances at the page all lead to different ideas.
Reading those comments side by side brings questions to the table that the team hadn't thought of. That's the output we're after: a testable hypothesis, something you can phrase as "Does the price filter really come back empty, and how many visitors does that affect?" A simulation can't tell you whether the hypothesis is true. It only shows you what's worth testing. The answer comes from real people or real measurement.
How do we set up a simulation?
A simulation takes three steps. We do this with Rubric, but the logic of the steps doesn't depend on the tool.
Describing the visitor. We start by writing down who this visitor is, what they came for, and how comfortable they are with technology. The more specific the description, the more useful the session, because a visitor described only as "a user" tries to speak for everyone.
Writing tasks and questions. Next we decide what the visitor should try and what to ask them at the end. Tasks should stay close to the reasons a real visitor comes to the site, and questions should go to what the team genuinely wants to know.
Reading the session. When the session ends, you have a task-by-task record for a single page or the whole site. The report shows the visitor's profile, each task's outcome, their thinking step by step, screenshots, and blockers ranked by severity. We decide whether to take a finding seriously by reading the steps behind it.
Sessions are read by the person or people who look after that brand's UX. We typically try three or four personas in a study, because a single point of view isn't enough to produce a varied set of hypotheses.
Across these steps, AI runs the session and produces the record. The team decides which visitors to describe, which questions to ask, and which findings to take forward.
What did we see on an e-commerce site?
A simulation we ran on an e-commerce site shows well what a difference in persona can mean. We used two simulated visitors in this case. The first was a regular buyer on a phone who knew what they wanted. The second was a first-time buyer on a desktop, comparing prices and reviews and wary of anything unclear.
Both did the same four tasks: adding a product to the cart and reaching checkout, finding a current price and discount, using the price filter, and finding customer service details. At the end we asked how clear the path to the cart was, whether the discounts felt trustworthy, and what was missing. The visitors didn't pay, register or send any messages.
Six of the eight tasks were completed and two weren't. Seven reports came down to five blockers: two high, two medium and one low in severity.
The most instructive difference appeared at the cart button. The quick buyer on the phone saw no cart button on the listing card, and a small icon on the card took them to the sign-in page. The visitor on the desktop saw the button. The same page produced two experiences. The careful visitor, meanwhile, stumbled over whether the price was consistent, because the listing, the offer on the checkout page and the order summary showed different discounts for the same product. That inconsistency made the quick buyer question the price as well. With only one visitor, we would have been much less likely to see these two problems together.
The other blockers were of a similar kind. Choosing the lowest price range emptied the list, and neither visitor could tell whether the filter was broken. Two lines in the cart contradicted each other about free shipping, and the contact page didn't say which number to use for an order problem.
None of this is a verdict; all of it is hypothesis. A blocker doesn't prove that real visitors will get stuck in the same place. So the next step is to verify: does the filter really come back empty, and how many visitors does that affect? We ask a similar question about every blocker before anyone acts on it.
We've tried the same thing on our own site. In a simulation we ran on things.com.tr on 5 October 2026, the enterprise visitor said a direct contact form or phone number would be even more helpful for them. We noted that as a question too.
What is it good for, and what doesn't it replace?
User simulation is well suited to these jobs:
- You can use it to see where a first-time visitor gets stuck, before a new page is announced or before a redesign.
- You can use it to check a flow on a page that doesn't have traffic yet.
- It gives your team and stakeholders something concrete to discuss in the first week, in the form of comments from different personas.
There are two things it doesn't replace:
- It doesn't replace interviews and usability tests with the people who actually buy from you.
- It doesn't replace decisions that depend on real behavior at scale, because those need measurement data.
Where a decision is at stake, we talk to real people. A simulated visitor can get stuck on a screen, but it doesn't live through a company's buying process or the trust people place in a product. We explain which test method suits which situation in which usability testing method when.
There's one more limit. How far a simulated visitor gets on complex sites is still being improved, which is why the feature is in beta. So a result from a complex site should be read with more caution than one from a simple page.
Where does simulation sit in the process?
We're an AI native studio, which means a studio that builds AI into every step of the process. Simulation belongs to the Discover stage of that process, and it's the first of three steps.
Simulation first. A quick first read draws the team's attention to specific places and clarifies what to ask in real interviews.
Then interviews with real users. The hypotheses are tested with real people. Some are confirmed, others drop away, and the interviews bring up things no simulation showed.
Measurement after launch. Once the product is live, real behavior shows whether the problems seen in the first read actually happen.
On a project with no research budget, the second step is missing. In that case the hypotheses shouldn't be treated as results; they should be tested against measurement after launch.
For an enterprise team, the gain from this order is that the research budget goes on better prepared questions.
FAQ
Can you do usability testing with AI? AI can help you see in advance where a first-time visitor might get stuck. But to call it usability testing, real users need to try the product. We use simulation as preparation that produces hypotheses for testing.
Are synthetic users the same as personas? No. A persona is a description a team writes about its users. A synthetic user is a simulated visitor who takes such a description, actually goes through the site, and says what they're thinking.
Does simulation work on a page with no traffic? Yes. We run simulations on public pages, and a page doesn't need to have had any traffic.
Let's do the first read together
In short, here's who we are: a studio that works with AI and does design and development in one team. Things is one of the pioneering and leading companies in AI-driven design in Turkey. Since 2018 we've brought more than 50 products to life, and our work has won a Red Dot award.
If you'd like to talk about where to look first in your product, send a short note to hello@things.ist and we'll get back to you within 48 hours.
Design. Engineering. Mastery.