Use AI-generated customer interviews to prepare questions and challenge assumptions, while keeping their answers separate from evidence collected from customers. A convincing simulated interview can help a team imagine a problem. It does not establish that a customer has experienced it, how often it occurs or whether fixing it should take priority.
This distinction matters when a small business cannot recruit participants quickly, or an enterprise product team needs an early view of an unfamiliar market. Synthetic respondents are generated stand-ins for people. They may offer useful language and possibilities, but their profiles and statements do not become fieldwork because the output resembles a research transcript.
Our editorial recommendation is to treat every generated response as an input to a research plan. Before it reaches a roadmap or investment brief, state what would need to be checked with people, product behavior or another relevant source.
Matching the headline can conceal missing variation
In an October 16, 2026 practitioner comparison, Nielsen Norman Group posed a UX-terminology question to 120 synthetic respondents and compared their answers with an earlier survey of 604 tech and design professionals. Both datasets supported the same broad conclusion about the dominant terminology, but synthetic responses contained fewer distinct alternatives.
The comparison has important limits. The human and synthetic samples had different role compositions, and the platform sometimes reworded the question and used an interview format. It was one question, not a general validation of synthetic research. The synthetic responses were generated in February 2026; the October publication date is not the date of a new product test.
For a business reader, the useful distinction is between recovering a common answer and discovering an unexpected one. A dataset that looks adequate for a broad headline may still be unsuitable for finding an overlooked need. This is not a claim that every synthetic system will miss the same answers.
A persona label does not establish representation
A separate paper by Angelina Wang, Jamie Morgenstern and John P. Dickerson studies how demographic prompts can misrepresent groups and reduce their internal variation. It compares free responses from people in the United States with responses from four language models. The inspected version is dated February 2025, and its model experiments were conducted in 2023.
The authors find problems with both portrayal and variation, while discussing mitigations that reduce rather than remove the harms. They also acknowledge supplementary uses. This is not a test of current commercial customer-research platforms or a measurement of your customer base.
The practical implication is to avoid assuming that a detailed generated profile establishes coverage. Giving a simulated respondent an age, job, country and personality does not demonstrate that its answers represent people with those characteristics. For research about differences between customer groups, ask what comparison with relevant human evidence supports that use.
Turn a simulated complaint into a question
Imagine a hypothetical supplier of office equipment planning a customer portal. The team asks an assistant to simulate interviews with purchasing coordinators. An invented response says that repeatedly checking delivery dates is frustrating and that automatic notifications would solve the problem.
This example is fictional. No customers were interviewed, no assistant was tested and no demand was measured for this article.
The response contains several separate propositions: people check delivery dates repeatedly; this creates a meaningful cost; the information is available and reliable; notifications would reach the right person; and notifications would improve the situation. A fluent interview answer can bundle all of them into one appealing story.
Convert that story into a research question: when a coordinator last needed a delivery update, what triggered the check, where did they look, what happened next and who needed the answer? The aim is to learn about a real sequence of events before presenting the proposed solution.
Do not begin by asking people whether automatic notifications would be helpful. That question tests a reaction to your framing. A recent-event walkthrough may instead reveal that the difficult part is reconciling conflicting dates, forwarding updates to a site manager or identifying which purchase order a message refers to.
Those alternatives are possibilities to investigate, not findings we claim customers will report. They illustrate why generated answers should expand a research plan rather than settle it.
Keep the evidence type attached to the claim
A decision brief should let its reader distinguish what was generated, said, observed and inferred. Our proposed reporting table uses the fictional portal project to show the difference:
| Material | Honest description | What it does not establish |
|---|---|---|
| Generated interview answer | A simulated coordinator suggests delivery notifications | That any customer requested them |
| Statement from a recruited participant | That participant describes a recent delivery-checking problem | How common the problem is across customers |
| Observed task with a prototype | A participant completes or struggles with the tested task | That the feature will be adopted in everyday work |
| Product or service records | Recorded events under the stated definitions and coverage | The customer’s motive without further evidence |
The rows are proposed evidence categories, not results from an actual study. A real brief would identify the source, date, recruitment or collection method, and scope for each claim.
Keep synthetic responses out of the participant count. Running more prompts creates more generated material; it does not recruit more customers. Do not put an invented quotation in a customer-quote slide unless its simulated status is unmistakable there, including when the slide is copied elsewhere.
If an assistant summarizes actual interviews, preserve links to the underlying records and keep those summaries distinct from newly invented responses. Our guide to preserving disagreement in AI feedback summaries addresses a related problem: a smooth summary can hide differences that matter to the decision.
Use simulation to improve preparation
Nielsen Norman Group’s June 2024 practitioner guidance describes possible uses in desk research and hypothesis generation while cautioning against replacing real-user research. Its authors evaluated simulated interviews against earlier studies. This guidance comes from the same organization as the October comparison, so it is not an additional independent replication. Historical tool descriptions should not be read as current feature guarantees.
For the hypothetical portal team, a bounded assignment could ask AI to list assumptions in the notification concept, suggest neutral follow-up questions and identify customer situations the draft interview guide omits. Ask for uncertainty and competing explanations rather than a verdict on whether to build the feature.
A team member who understands the domain should review the proposed questions for relevance, leading wording and unsupported premises. Useful preparation might expose an unanswered operational question: does the supplier even receive delivery updates early enough to notify customers reliably? That can be investigated with the service team before recruiting anyone.
Keep the preparation output visibly labeled. If the final brief says that customers need notifications, the evidence must come from appropriate research or operational investigation, with its limitations stated. A simulation’s role in suggesting the question does not make it the answer’s source.
Ask what a validation claim actually covers
If a provider says its synthetic respondents have been validated, request the task, target population, human comparison data, model or product version, and outcome measure. Determine whether the evidence concerns a broad average, subgroup differences, unusual responses or prediction of behavior. Those are different targets.
Also ask whether the human data used to assess performance were separate from data used to build or tune the simulation. A system fitted to known answers needs an assessment beyond reproducing those answers before its performance can justify use on new questions. This is our evaluation recommendation, not a guarantee that one holdout exercise establishes general reliability.
For a specific proposed use, define in advance which errors would change the business decision. Missing a rare but serious workflow constraint may matter more than matching the most common preference. An aggregate match should not silently authorize claims about every customer segment.
Do not infer that the studies discussed here validate or invalidate every product. Their populations, questions, model dates and evaluation methods differ. They support asking for evidence suited to the intended claim.
Choose the next evidence before the next generation
A small business can begin with a bounded set of conversations about recent events and a clear statement that the sample is exploratory. A larger organization can involve its research team in recruitment, coverage and comparison methods. Neither should turn a convenient set of interviews into a market-wide percentage without an appropriate design.
If recruitment is delayed, record the unresolved assumption and consider a reversible exploratory step whose limits are explicit. Do not describe simulated approval as completed customer validation to make a planning milestone look finished.
For the portal example, the immediate next step is to inspect how delivery updates are produced and speak with relevant coordinators about a recent check. Keep the synthetic notification idea in the hypothesis column until that work provides evidence. The useful output of the simulation is then a better investigation, with a clear record of what the business still does not know.