AI Personas and Synthetic Users: Where They Mislead

A synthetic user can give you a detailed opinion about a checkout that nobody has actually used. That makes these systems useful for generating questions and dangerous for answering them. Fluent descriptions of frustration are not observations of frustration, even when they sound exactly like an interview transcript.

For working designers, the useful distinction is between simulation for preparation and research involving people. AI personas can help explore a design space cheaply. They cannot establish how your customers behave, how common a problem is, or whether a proposed change will improve conversion.

Define the decision before creating a persona

Start with the decision your team needs to make. “Should we test a clearer explanation of cancellation?” is a reasonable question for an exploratory exercise. “Will this increase annual subscriptions?” needs evidence from actual customers and an appropriate evaluation design. Writing the decision down prevents a speculative conversation from quietly becoming a research finding.

Give the model a bounded role: review a flow for possible misunderstandings, suggest interview probes, or identify missing scenarios. Ask it to distinguish provided facts from assumptions. If the brief says customers manage several client accounts, it may explore account-switching mistakes. It should not invent a percentage of customers who make them.

Use the UX research tools directory when planning how to investigate those questions with people. Select tools for recruitment, observation, and analysis rather than treating persona generation as a substitute for the whole research process.

Ground scenarios without manufacturing people

Build scenario cards from anonymised research themes, support categories, and documented product constraints. Include goals, relevant experience, environment, and known barriers. Avoid giving a character a decorative biography that encourages stereotypes without changing the task. A busy support agent using a shared workstation is more useful than a fictional age and favourite coffee.

Keep source provenance beside each input. A support ticket is evidence that someone reported a problem, not that most users experience it. A sales request may represent a prospective buyer rather than a daily operator. Models tend to smooth these differences into a plausible average unless you preserve them explicitly.

Do not upload identifiable interview transcripts or confidential customer records without approved controls. Check retention, access, and contractual terms first. Prefer a small, redacted evidence summary. The GOV.UK user research guidance provides a grounded reference for planning research around real users rather than invented demographic profiles.

Include contradictions in the input. If experienced users want shortcuts but occasional users need explanation, preserve both needs. A useful simulation exposes trade-offs; it does not reconcile every disagreement into a reassuring persona everyone can approve.

Ask for hypotheses, not synthetic findings

A prompt should constrain both the task and the claims the model can make. Request possible failure mechanisms, assumptions, and follow-up questions. Do not ask it to produce a realistic interview and then analyse that interview as though it came from a participant.

Review this account-switching flow as a hypothesis exercise.
Use only the supplied product constraints and research themes.
For each possible confusion, return:
- The interface element involved
- The assumption behind your concern
- A question or observation that could test it with real users
Do not invent quotations, frequencies, or participant histories.
Label every concern as unverified.

Run a second pass asking what the first response overlooked or assumed without evidence. This is adversarial review, not independent replication: both outputs still come from a generative system, and agreement between them does not establish truth.

Save the prompt, input summary, output date, and reviewer notes. Repeated sessions may produce different concerns. Record useful differences as candidates for investigation rather than averaging generated responses into a satisfaction score. Ten simulated users are not a sample of ten customers.

Turn simulated concerns into testable design work

Suppose the model suggests that a long account name could obscure the active workspace on mobile. Convert that into a specific design check: render realistic long names, reduce viewport width, increase text size, and examine whether the current account remains identifiable. This is a reproducible interface test, independent of whether the fictional persona sounded convincing.

Use the CSS clamp calculator to explore bounded fluid heading sizes for these narrow-screen prototypes, then test the resulting CSS with zoom and long content. A calculated scale can help control layout, but it cannot tell you whether a user understands the account hierarchy.

Keep interface inspection separate from behavioural evidence. Designers can verify clipping, missing labels, and unreachable controls directly. Questions about trust, interpretation, and real-world interruption need observation or interviews. The W3C guidance on involving users explains why participation matters alongside technical evaluation.

Move promising hypotheses into a small research plan. Specify who should attempt the task, what would count as a misunderstanding, and what prototype limitations might distort the result. Pair this work with the AI microcopy workflow when a concern involves labels or recovery instructions rather than layout.

Report uncertainty where decisions happen

Label every output AI-generated hypothesis in the document itself, not only in the meeting where it first appears. Slides get copied, screenshots lose context, and a vivid invented quotation can become institutional memory. Better still, avoid generating fake participant quotations at all.

Maintain separate sections for observed evidence, expert inspection, and simulated concerns. A practical issue log records the concern, its source, the decision it could affect, the next validation step, and an owner. Do not attach participant counts or confidence percentages to generated opinions.

Agree on evidence thresholds before a stakeholder sees a persuasive simulation. Low-risk changes such as repairing clipped text may need inspection and regression checks. Changes to pricing, consent, onboarding requirements, or accessibility accommodations need stronger evidence and relevant specialist review. The Nielsen Norman Group research-method overview helps choose methods for different questions.

Judge the exercise by whether it improves the next real investigation: sharper tasks, better coverage, fewer leading questions, or a clearer prototype. Track which generated concerns were supported, contradicted, or left unresolved. This creates feedback on usefulness without pretending the model has become a calibrated representative of your audience. If the exercise repeatedly adds noise, stop using it for that decision type.

Key takeaways

• Use synthetic users to generate questions, not to claim customer behaviour.
• Ground scenarios in documented constraints and preserve their provenance.
• Mark generated concerns as unverified wherever they are shared.
• Convert plausible concerns into inspectable checks or real research tasks.
• Keep observed evidence, expert judgement, and simulation clearly separated.