How to Use AI in UX Research Without Replacing Research

September 12, 2026
 · 
25 min read

AI can prepare interview questions, organise notes, identify recurring themes, and create an elegant summary.

It can also write:

Users need a simple, intuitive process that saves time and reduces frustration.

A sentence so universal that it could apply to a banking app, an oven, an equipment-booking system, and probably a television remote control.

The problem is not that AI is useless in UX research.

It is extremely useful.

The problem begins when assistance with research is mistaken for evidence.

A model can:

  • help prepare a study,
  • organise material,
  • suggest alternative interpretations,
  • identify gaps,
  • speed up documentation,
  • make findings easier to communicate.

It cannot:

  • observe the behaviour of someone it has never met,
  • confirm why a user made a particular decision,
  • determine how frequently a problem occurs,
  • represent a real user group,
  • turn a generated statement into a research quote,
  • create an insight without source material.

In The AI Workflow for Product Designers: Lead, Expand, Refine, Elevate, I described a workflow in which the designer sets the direction, AI expands the possibilities, and the human then verifies, selects, and interprets the material.

In UX research, this division of responsibility is particularly important.

AI can support the research process. It cannot be treated as a participant, an observation, or evidence.

AI-Assisted Research Is Not AI-Generated Research

There is a fundamental difference between these two approaches.

AI-Assisted Research

You have real material:

  • participant statements,
  • observations,
  • survey results,
  • support tickets,
  • product data,
  • test notes,
  • recordings,
  • process documentation.

AI helps you:

  • prepare an analysis plan,
  • organise the material,
  • identify recurring patterns,
  • separate observations from interpretations,
  • create working categories,
  • compare segments,
  • write a summary.

AI-Generated Research

You do not have enough material, so you ask:

What problems do university students experience when borrowing equipment?

The model responds:

  • difficulty checking availability,
  • a complicated process,
  • unclear rules,
  • long waiting times,
  • communication problems.

All of these problems are possible.

None has been confirmed by your research.

These are not findings.

They are hypotheses that may help you prepare a study.

This distinction should remain visible throughout the entire process.

AI Does Not Speak to “The User”

One of the most tempting uses of AI is asking the model to “act as” a user.

You are a university student using an equipment-booking system. Tell me what frustrates you.

You will probably receive a plausible, coherent, and detailed response.

It may even sound more interesting than some real interviews in which the participant says:

I don’t know. I think it’s fine.

The generated statement is still not a user statement.

The model:

  • has not used the product,
  • does not have a specific context,
  • does not experience the consequences of decisions,
  • does not know local rules,
  • does not remember previous experiences,
  • is not trying to complete the task under time pressure,
  • does not experience organisational constraints.

You can use a simulated perspective to prepare questions.

You cannot use it as evidence confirming a need.

Good Use

Generate possible assumptions about the problems students may experience when borrowing equipment. For each assumption, prepare a research question that could help test it. Do not present the assumptions as user needs.

Poor Use

Create a student persona and describe their needs based on typical behaviour.

The first instruction produces material for a study.

The second may create an attractive fiction with a name, photograph, favourite quote, and frustration so generic that it could apply to half the population.

What AI Can Support in UX Research

AI can be useful at almost every stage of a study:

  1. defining the objective,
  2. creating the plan,
  3. preparing the screener,
  4. creating the discussion guide,
  5. organising notes,
  6. coding material,
  7. synthesis,
  8. identifying contradictions,
  9. preparing the report,
  10. updating the research repository.

That does not mean it should perform every stage independently.

The closer you are to:

  • the source data,
  • interpreting intent,
  • making decisions,
  • communicating confidence,

the more human oversight is required.

Apply the Workflow: Lead, Expand, Refine, Elevate

The Lead → Expand → Refine → Elevate model helps preserve the correct division of responsibility.

Lead — Define What You Need to Learn

Do not begin with:

Prepare some research for me.

First define:

  • the decision the study should support,
  • the problem or hypothesis,
  • the participant group,
  • the material available,
  • the constraints,
  • the level of confidence you need.

Example:

We are designing a university equipment-booking process. We need to decide when users should see permission requirements: before selecting a date or only when submitting the reservation.

We are planning five interviews and a prototype test with students who borrowed equipment within the past six months. We do not yet have quantitative data about how frequently the problem occurs.

Help me prepare questions that will allow us to understand the current process, when users discover the requirements, and the consequences of informing them too late. Do not assume that the problem has already been confirmed.

Now AI knows:

  • which decision is being examined,
  • who it concerns,
  • what material will be available,
  • what it must not treat as fact.

Expand — Broaden the Research Plan

At this stage, AI can help identify:

  • alternative hypotheses,
  • questions you may have missed,
  • risks of bias,
  • different data sources,
  • potential segments,
  • scenarios to test.

Example:

Identify alternative explanations for the problem. Do not assume that the only cause is showing the requirements too late. For each possible explanation, prepare a question or research task.

The model may suggest that the problem comes from:

  • unclear language,
  • lack of awareness of the rules,
  • outdated information,
  • inconsistencies between channels,
  • an invisible permissions status,
  • different interpretations of the word “available”.

These are still not findings.

They are a way to avoid designing a study whose only purpose is to confirm the first idea.

Refine — Remove Suggestions That Do Not Support the Decision

AI may generate twenty questions.

The participant may begin regretting agreeing to the interview by question seven.

During the Refine stage, check:

  • whether the question supports the objective,
  • whether it suggests an answer,
  • whether it concerns a real experience,
  • whether the participant can answer it,
  • whether the answer could affect the decision,
  • whether the scope remains realistic.

You can ask:

Review the questions for bias, double-barrelled questions, leading language, and requests to predict future behaviour. Do not rewrite them yet. First identify the problem and explain how it could affect the participant’s answer.

AI can help perform the review.

You decide which questions remain.

Elevate — Add Contextual Knowledge and Your Own Judgement

The final research plan must account for things the model does not know:

  • organisational culture,
  • the participant’s relationship with the product,
  • the sensitivity of the subject,
  • the language users use,
  • previous findings,
  • recruitment limitations,
  • interview dynamics,
  • your moderation experience.

You may notice that a question is technically correct but should not appear at the beginning of the conversation.

You may know that participants do not understand the term “eligibility”.

You may need an additional question because the process differs between departments.

This is the layer you cannot obtain simply by adding:

Act like a senior UX researcher.

1. Defining the Research Objective With AI

A weak research objective sounds like this:

We want to learn what users think about the booking process.

That is extremely broad.

It may lead to a conversation about:

  • the appearance of the calendar,
  • the colour of the button,
  • the quality of the equipment,
  • collection-point opening hours,
  • experiences with university administration,
  • the entire education system.

A good objective identifies the decision.

Example:

We want to understand how students currently check equipment availability and borrowing requirements, and whether seeing restrictions before selecting a date helps them assess whether they can complete the reservation.

The objective still does not assume that the solution is correct.

It explains what you need.

Prompt for Clarifying the Objective

Help me turn a broad research topic into a specific objective that supports a product decision.

Topic: [paste topic].
Decision the team needs to make: [paste decision].
Available method: [interviews, tests, survey, data analysis].
Constraints: [time, number of participants, access to data].

Prepare:

  • a working research objective,
  • three research questions,
  • information this method cannot establish reliably,
  • assumptions that must not be treated as confirmed.

The final point is as important as the first three.

Good research does not only show what you can learn.

It also shows what you cannot conclude from it.

2. Preparing the Research Plan

AI can help create a structure covering:

  • context,
  • objective,
  • research questions,
  • hypotheses,
  • method,
  • participants,
  • recruitment criteria,
  • study scenario,
  • analysis approach,
  • risks,
  • limitations.

However, it should not select a method simply because it looks good in a table.

Five interviews will not answer:

What percentage of users abandon the process?

Quantitative data alone will not answer:

Why do users not understand the difference between confirmation and equipment readiness?

A usability test will not automatically confirm:

Does the feature solve an important problem?

The method must fit the question.

Prompt for Reviewing the Plan

Review the research plan below. For every research question, identify:

  • whether the selected method can answer it,
  • what kind of evidence the method can provide,
  • which conclusion must not be drawn,
  • which interpretation risk exists.

Do not suggest adding methods unless you explain the specific gap each additional method would address.

This can help reveal when one small study is trying to:

  • discover the problem,
  • confirm its scale,
  • evaluate usability,
  • assess desirability,
  • determine willingness to pay,
  • and probably settle the roadmap as well.

One study does not need to hold the entire product together alone.

3. Creating a Screener

AI can help formulate recruitment questions and criteria.

You still need to ensure that the screener does not reveal the “correct” answer.

Weak question:

Have you ever had difficulty booking university equipment?

A participant who wants to qualify quickly realises that “yes” is probably the promising response.

A better approach:

During the past six months, which of the following activities have you completed at your university?

  • booked a room,
  • borrowed equipment,
  • submitted a project,
  • contacted the administration office,
  • none of the above.

You can then ask about frequency, role, and the most recent experience.

Prompt for Reviewing the Screener

Review the recruitment questions for:

  • revealing the desired answer,
  • leading questions,
  • unclear criteria,
  • allowing someone without the relevant experience to qualify,
  • collecting unnecessary data.

For each issue, propose a more neutral version. Do not add demographic questions unless they are relevant to the research objective.

That final restriction prevents the screener from asking about everything simply because there is still room in the form.

4. Preparing an Interview Guide

AI can prepare an initial guide very efficiently.

It works best when you provide:

  • the objective,
  • the participant profile,
  • the available time,
  • the subject,
  • what you do not want to suggest,
  • which decisions the study should support.

A Good Guide Moves From Experience to Detail

Instead of beginning with:

Would you like to see the requirements earlier?

begin with:

Tell me about the last time you tried to reserve or borrow equipment.

Then ask:

  • Where did you begin the process?
  • How did you check availability?
  • Which information did you need?
  • When did you learn about the requirements?
  • What did you do when information was missing?
  • What was unclear?
  • How did the situation end?

First ask about real behaviour.

Only later move to reactions to the prototype or concept.

Prompt for Creating an Interview Guide

Prepare a working guide for a 45-minute interview with people who tried to borrow university equipment within the past six months.

Objective: understand the current process, information sources, when users discover requirements, and the consequences of being blocked.

Structure:

  • introduction,
  • contextual questions,
  • most recent real experience,
  • detailed process walkthrough,
  • problems and workarounds,
  • reaction to the concept,
  • closing.

Rules:

  • ask about behaviour before opinion,
  • avoid leading questions,
  • do not assume the participant experienced a problem,
  • do not ask participants to predict future behaviour when you can ask about past experience,
  • add no more than two neutral follow-up questions to each main question.

AI creates the draft.

You still need to check whether the interview sounds like a conversation rather than an interrogation conducted by an unusually polite form.

5. Reviewing Leading Questions

AI can help identify questions such as:

How frustrating was the lack of information?

The question assumes:

  • that information was missing,
  • that the situation was frustrating.

A better version:

What information was available at this stage?

Then:

How did that affect what you did next?

Another example:

Would showing the requirements earlier make the process easier?

Better:

What did you think when you saw the requirements in this location?

Or:

At what point would you expect to find this information?

Prompt for Auditing Questions

Review the guide and identify:

  • leading questions,
  • questions containing assumptions,
  • two questions combined into one,
  • questions that are too abstract,
  • questions requiring prediction,
  • questions that can only be answered with “yes” or “no”.

For each one, explain:

  • the problem,
  • the possible effect on the response,
  • a neutral alternative.

Not every closed question is a mistake.

Sometimes you need a specific confirmation.

The problem begins when the entire interview can be completed through a series of polite “yes” responses.

6. Preparing Usability-Test Tasks

AI can help assess whether a task:

  • reveals the solution,
  • uses interface language,
  • has a realistic context,
  • leads to a specific objective,
  • tells users where to click.

Weak task:

Find an available camera, check the requirements, and click Reserve.

That is an instruction manual for the prototype.

Better:

You need a camera for a project beginning next week. Check whether you can borrow one and try to reserve a suitable date.

The user has a goal.

They do not receive a map of the interface.

Prompt for Preparing Tasks

Prepare three neutral tasks for testing the equipment-booking process. Each task should:

  • include a realistic context,
  • have a clear objective,
  • avoid button and tab names,
  • avoid suggesting the path,
  • allow observation of whether the user notices the requirements and understands the status.

For each task, add:

  • the behaviour we want to observe,
  • the moment when the moderator should not help,
  • a follow-up question.

Do not assume that completing the task means the user understood the process.

Clicking the correct button does not always mean that the participant understands what they have done.

Sometimes it simply means the button was large and purple.

7. Organising Notes After the Study

After several sessions, you may have:

  • transcripts,
  • moderator notes,
  • observations,
  • quotes,
  • timestamps,
  • prototype issues,
  • team interpretations.

AI can help organise this material.

First, however, you need to separate the different types.

Observation

The participant returned to the equipment-details view three times.

Statement

“I don’t know whether I can reserve this or only see the date.”

Interpretation

Users do not understand the difference between availability and eligibility.

The first two are evidence.

The third is a conclusion that needs to be evaluated.

Do not put everything into one paragraph labelled “Insight”.

Prompt for Organising Notes

Organise the research material below while preserving a strict distinction between:

  • behavioural observation,
  • direct participant statement,
  • researcher interpretation,
  • open question.

Do not paraphrase quotes in a way that changes their meaning. Do not create insights. Do not combine different participants into one statement.

Preserve the participant identifier and task number for every item.

This is technically less impressive than:

Find key insights.

And considerably safer.

8. Coding and Grouping the Material

AI can help prepare working codes, especially when you have a large amount of qualitative material.

It may group fragments into topics such as:

  • availability,
  • understanding requirements,
  • trust in the status,
  • terminology problems,
  • process workarounds,
  • dependence on staff,
  • reactions to restrictions.

The risk is that the model may:

  • combine similarly worded but different problems,
  • ignore exceptions,
  • create a single narrative too quickly,
  • assign meaning that the participant never expressed.

Prompt for Initial Coding

Based on the material, propose descriptive codes. Each code should name what the participant said or did without interpreting motivation.

For every code, provide:

  • a name,
  • a short definition,
  • matching fragments,
  • participant identifiers,
  • cases that look similar but should not be combined.

Do not create higher-level themes or insights yet.

First describe the material.

Interpret it later.

Descriptive Code Versus Interpretation

Descriptive code:

Checks availability across several channels.

Interpretation:

Does not trust the information in the system.

The second version may be true.

It may also be wrong.

Perhaps the user did not know which system was current.

Perhaps that is simply their usual process.

Perhaps a staff member instructed them to check another channel.

Do not jump from behaviour to motivation without evidence.

9. Identifying Patterns Without Removing Differences

AI likes order.

Research does not always provide it.

You may have:

  • three people who did not notice the requirements,
  • one who noticed them immediately,
  • one who already knew about them,
  • two who did not understand the term,
  • one who understood the term but did not trust the data.

You do not need to turn that into:

Users struggle with eligibility requirements.

That summary removes important differences.

A better version might be:

Three of five participants began selecting a date without checking the requirements. One noticed them before opening the calendar, while another already knew the rules from previous experience. The issue therefore concerned not only visibility but also differences in prior knowledge.

This is still a small sample.

It does not represent all users.

But it accurately describes the material.

Prompt for Identifying Patterns

Based on the coded material, identify:

  • behaviours observed across several participants,
  • behaviours observed only once,
  • contradictions,
  • possible differences related to experience,
  • areas where the evidence is insufficient.

For every statement, provide participant identifiers and source fragments.

Do not use the words “users”, “most users”, or “typically” unless the material supports a claim about scale.

AI should show the path from the material to the summary.

Not only the final sentence.

10. Creating Insights

Not every observation is an insight.

Participants did not notice the information.

That is an observation.

The information was not visible enough.

That is a design hypothesis.

Users need larger text.

That is a solution disguised as a user need.

A strong insight connects:

  • behaviour,
  • context,
  • a cause or mechanism,
  • a consequence,
  • relevance to the decision.

Example:

Participants treated an available date as confirmation that they were eligible to borrow the device. Because training requirements appeared only after date selection, the restriction was interpreted as a system error rather than a consequence of the borrowing rules.

This insight shows:

  • how the participant understood the situation,
  • what created the false expectation,
  • how the problem was interpreted,
  • why the order of information matters.

AI can help formulate the insight.

It cannot independently confirm the mechanism.

Prompt for Creating Working Insights

Based on the observations and quotes below, prepare working insight statements. Each should include:

  • context,
  • observed behaviour,
  • possible mechanism,
  • consequence,
  • relevance to the product decision.

Separate:

  • elements directly supported by evidence,
  • interpretation,
  • confidence level,
  • source evidence.

If the mechanism is not clear from the material, mark it as a hypothesis. Do not turn a design recommendation into a user need.

Then read every insight and ask:

  • Does the material really show this?
  • Have I combined several different problems?
  • Has the mechanism been confirmed?
  • Is there another possible explanation?
  • Does the insight affect a decision?

11. Looking for Alternative Interpretations

One of the best uses of AI is challenging the first interpretation.

Assume that you observe:

Four people did not notice the training information.

The first conclusion:

The information is not visible enough.

Alternative explanations:

  • participants did not expect requirements at this stage,
  • the terminology was unclear,
  • users were focused on the calendar,
  • the information looked optional,
  • previous experience suggested a different process,
  • the test task directed attention towards the date.

AI can help broaden the interpretation.

Prompt for Challenging a Conclusion

For every working conclusion, prepare:

  • three alternative explanations,
  • evidence that supports the current conclusion,
  • evidence that could contradict it,
  • a question requiring further research,
  • a decision we should not make yet.

Do not select the most likely explanation without identifying the supporting source material.

This does not weaken the research.

It protects it from turning the first observation into the final truth too quickly.

12. Analysing Contradictions and Negative Cases

Teams often focus on the dominant pattern.

An exception may reveal:

  • another segment,
  • prior experience,
  • an important condition,
  • a problem with the method,
  • a limitation of the recommendation.

When four people had a problem and one did not, do not only ask:

Why did four people have the problem?

Also ask:

What was different about the person who did not?

Perhaps they:

  • had used the process before,
  • understood the terminology,
  • saw the information in another channel,
  • had a different permission level,
  • completed the task on another device.

Prompt for Analysing Exceptions

Identify cases that do not fit the dominant pattern. For each one, describe:

  • how it differs,
  • which contextual factor may explain it,
  • whether it challenges the current conclusion,
  • whether it suggests a segment or condition,
  • what cannot be determined from the available evidence.

Strong analysis does not remove disorder simply because the report looks better without it.

13. Combining Qualitative and Quantitative Data

AI can help bring together:

  • behaviours from usability tests,
  • interview statements,
  • analytics,
  • support tickets,
  • survey results.

However, their different meanings must be preserved.

Qualitative Data Can Help Explain:

  • what is happening,
  • why it is happening,
  • how the user interprets the situation,
  • which strategies they use.

Quantitative Data Can Help Determine:

  • how frequently something happens,
  • where users abandon the process,
  • which segments behave differently,
  • whether a change affected a measurable outcome.

One should not pretend to be the other.

Five interviews cannot determine the scale across the entire population.

A large funnel drop cannot explain the cause on its own.

Prompt for Triangulation

Compare the following sources without mixing their meaning:

  • interview findings,
  • usability-test observations,
  • analytics,
  • support tickets.

For every conclusion, identify:

  • which source supports it,
  • what kind of evidence the source provides,
  • whether the sources confirm one another,
  • whether a contradiction exists,
  • what still cannot be established.

Do not use a small qualitative sample to estimate the scale of a problem.

AI can help build an evidence map.

It should not flatten all sources into one list of “key findings”.

14. Preparing the Research Report

AI is very useful when transforming material into a report.

It can prepare different versions:

  • a full document for the team,
  • a brief executive summary,
  • a list of decisions,
  • material for developers,
  • backlog scenarios,
  • a stakeholder summary.

However, while shortening the material, you need to preserve:

  • limitations,
  • confidence level,
  • contradictions,
  • the distinction between observation and interpretation,
  • the number of participants,
  • issues requiring further validation.

Report Structure

Context

Why was the study conducted?

Decision

Which decision was it intended to support?

Method

Who participated, and what was done?

Limitations

What can the study not confirm?

Key Findings

What was observed?

Evidence

Quotes, behaviours, data, and examples.

Interpretation

What may explain the observations?

Implications

What does this mean for the product?

Recommendations

What does the team propose, and why?

Open Questions

What requires further investigation?

Prompt for Preparing a Report

Based on the approved observations, quotes, and conclusions, prepare a working research report.

Preserve the following structure:

  • context,
  • decision,
  • method,
  • participants,
  • limitations,
  • findings,
  • evidence,
  • interpretation,
  • implications,
  • recommendations,
  • open questions.

Rules:

  • do not add observations,
  • do not change the number of participants,
  • do not present interpretations as facts,
  • do not generalise findings to all users,
  • preserve contradictions,
  • connect every recommendation to a specific finding.

AI helps write the report.

The researcher remains responsible for whether it represents the evidence accurately.

15. Adapting Findings for Different Audiences

A Product Manager may need:

  • the decision,
  • the risk,
  • the recommendation,
  • the confidence level.

A developer may need:

  • behaviours,
  • errors,
  • exceptions,
  • dependencies.

A designer may need:

  • problems in the flow,
  • mental models,
  • reactions to messages,
  • scenarios.

A business stakeholder may need:

  • relevance to the process,
  • consequences,
  • constraints,
  • a decision requiring their support.

AI can change the format.

It should not change the level of confidence.

Prompt for Different Report Versions

Based on the approved report, prepare:

  1. a summary for the Product Manager,
  2. a list of design implications,
  3. a list of questions for the developer,
  4. a brief executive summary.

Every version must:

  • preserve the same findings,
  • include the limitations,
  • avoid increasing the confidence level,
  • avoid adding new recommendations.

At the end, identify whether any information important to the interpretation was lost during summarisation.

16. Research Repositories and Knowledge Retrieval

Over time, a team collects:

  • reports,
  • interviews,
  • test results,
  • support requests,
  • decisions,
  • hypotheses,
  • questions.

AI can help:

  • tag materials,
  • create summaries,
  • find related research,
  • identify recurring problems,
  • surface contradictory findings,
  • prepare research briefs.

The condition is a strong metadata structure.

Each item should include:

  • date,
  • product or area,
  • segment,
  • method,
  • number of participants,
  • objective,
  • status,
  • owner,
  • limitations,
  • link to the source.

Without this, AI may retrieve an excellent-sounding insight from a three-year-old study about a product that no longer exists.

Prompt for Comparing Studies

Compare the studies below while preserving their context. For every finding, identify:

  • date,
  • segment,
  • method,
  • product area,
  • supporting source,
  • limitations.

Divide the results into:

  • recurring findings,
  • contradictory findings,
  • segment-specific findings,
  • potentially outdated findings,
  • findings requiring renewed validation.

Do not combine research conducted with different groups into one shared insight without noting the differences.

17. Desk Research With AI

AI can help:

  • prepare a list of topics,
  • organise sources,
  • compare definitions,
  • create a review structure,
  • identify gaps,
  • summarise materials you provide.

It should not be treated as a source itself.

When you ask:

How do people with disabilities use booking systems?

you may receive general information.

You still do not know:

  • where the information came from,
  • whether it is current,
  • which group it concerns,
  • in which context it was collected,
  • whether it applies to your product.

Desk research still requires checking:

  • authorship,
  • date,
  • methodology,
  • context,
  • credibility,
  • limitations.

AI can help you read.

It does not remove the obligation to know what you are reading.

18. Synthetic Users and Synthetic Research

The term “synthetic users” sounds attractive.

It suggests that instead of:

  • recruiting,
  • scheduling,
  • moderating,
  • analysing,

you can ask a model for ten generated responses.

Faster.

Cheaper.

Without a participant who arrives fifteen minutes late and spends half the session trying to fix their microphone.

The problem is that a synthetic response is based on:

  • language patterns,
  • the supplied description,
  • existing assumptions,
  • stereotypes,
  • the most probable narrative.

Not on real experience with the product.

Synthetic users may be useful for:

  • testing an interview guide,
  • generating possible reactions,
  • preparing the moderator,
  • identifying assumptions,
  • testing an analysis structure.

They should not be used for:

  • confirming needs,
  • evaluating usability,
  • determining priorities,
  • establishing how frequently a problem occurs,
  • validating a solution,
  • replacing groups that are difficult to recruit.

The most dangerous result is not an obvious absurdity.

It is a realistic response that confirms exactly what the team already wanted to hear.

19. AI-Generated Personas

A persona can be valuable when it synthesises real behavioural patterns.

It is not valuable simply because it contains:

  • a name,
  • an age,
  • a job title,
  • a motto,
  • a photograph of someone looking thoughtfully into the distance.

AI can help structure a persona based on research.

It should not create a segment without data.

Prompt for a Research-Based Persona

Based on the confirmed patterns below, prepare a working segment profile.

Include:

  • context,
  • behaviours,
  • goals,
  • constraints,
  • coping strategies,
  • differences from other segments,
  • source evidence.

Do not add a name, age, photograph, quote, or demographic data unless they come from the research. Do not turn one participant’s statement into a characteristic of the whole group.

Such a profile may be less visually impressive.

It is more likely to be useful.

20. Privacy, Confidentiality, and Participant Data

Research material often includes:

  • personal data,
  • recordings,
  • health information,
  • financial information,
  • employment history,
  • internal processes,
  • confidential statements.

Before pasting material into an AI tool, check:

  • the organisation’s policy,
  • participant consent,
  • the tool’s terms,
  • how data is stored,
  • whether anonymisation is required,
  • legal requirements,
  • NDA restrictions.

Remove or replace:

  • names,
  • addresses,
  • contact details,
  • client names,
  • account identifiers,
  • details that could reveal the person’s identity.

Anonymisation does not always mean removing the name.

In a small organisation, the sentence:

The only person responsible for security in the Kraków office

may be enough to identify someone.

Prompt for Anonymisation

Identify elements that may directly or indirectly identify the participant.

Divide them into:

  • direct identifiers,
  • indirect identifiers,
  • contextual details that may enable identification,
  • sensitive information.

Propose neutral replacements that preserve the research meaning. Do not change the meaning of the statement.

Then review the result yourself.

AI does not know the full organisational context and may not recognise that an apparently harmless detail points to one specific person.

How Not to Use AI in UX Research

1. Do Not Ask for “The Most Common User Needs” and Treat Them as Findings

You may receive hypotheses.

Not evidence.

2. Do Not Generate Quotes

A quote should come from a participant.

Not from a model that can write very convincingly inside quotation marks.

3. Do Not Ask AI to Determine User Intent From One Behaviour

Clicking Back does not automatically mean frustration.

It may indicate:

  • checking information,
  • an accidental click,
  • a need to compare,
  • misunderstanding,
  • a desire to change data.

4. Do Not Turn Frequency in a Qualitative Sample Into a Population Percentage

Three out of five participants is an observation in the study.

It is not “60% of users”.

5. Do Not Let AI Smooth Away Contradictions

A contradiction may be more important than the dominant pattern.

6. Do Not Remove Limitations From the Executive Summary

A short report should not sound more certain than the full report.

7. Do Not Publish a Recommendation You Cannot Connect to Evidence

AI may create a very sensible recommendation.

You still need to answer:

What evidence supports it?

8. Do Not Use AI to Replace Groups That Are Difficult to Reach

Recruitment difficulty does not mean you can generate the experience of people:

  • with disabilities,
  • experiencing violence,
  • living with medical conditions,
  • belonging to a specific culture,
  • experiencing financial hardship.

The more sensitive and context-dependent the topic, the more dangerous it is to pretend that statistically plausible text represents real experience.

Checklist for Analysing Research Material With AI

Source

  • Does every fragment have a participant or another source?
  • Are the quotes exact?
  • Have observations been kept separate from interpretations?

Scope

  • Has the model generalised the findings to the whole population?
  • Have differences between segments been preserved?
  • Is the number of participants visible?

Interpretation

  • Have alternative explanations been considered?
  • Has the mechanism been confirmed?
  • Have exceptions been retained?

Confidence

  • Is it clear what is an observation?
  • What is an interpretation?
  • What is a hypothesis?
  • What is a recommendation?

Decision

  • Does the conclusion affect a specific decision?
  • Does the recommendation follow from a finding?
  • Is another source of evidence required?

Responsibility

  • Has the researcher read the source material?
  • Has the result been reviewed with the team?
  • Is AI the only entity that has “seen” the full dataset?

A Complete Prompt for Analysing Qualitative Research

The following prompt can help you begin the analysis without handing the interpretation of the entire study over to the model.

Help me organise material from a UX study.

Research objective:
[paste objective]

Decision the study should support:
[paste decision]

Method and participants:
[describe the method, number of participants, and criteria]

Limitations:
[paste limitations]

Analysis rules:

  • do not add observations,
  • do not generate quotes,
  • do not change the meaning of participant statements,
  • do not present interpretations as facts,
  • do not generalise findings to all users,
  • preserve participant identifiers,
  • mark missing evidence,
  • identify contradictions and exceptional cases.

Stage 1 — Organise the Material
Divide the content into:

  • observations,
  • direct quotes,
  • researcher interpretations,
  • open questions.

Stage 2 — Initial Coding
Prepare descriptive codes without interpreting intent.

Stage 3 — Patterns
Identify recurring, isolated, contradictory, and context-dependent behaviours. Attach sources to each one.

Stage 4 — Working Interpretations
For every pattern, prepare:

  • a possible explanation,
  • an alternative explanation,
  • supporting evidence,
  • missing evidence,
  • confidence level.

Stage 5 — Implications
Identify possible consequences for the product decision, but do not create a final recommendation.

Stage 6 — Gaps
Add a list of questions requiring further research or consultation.

Source material:
[paste anonymised notes or transcript]

After receiving the response, you still need to:

  • return to the transcripts,
  • verify the quotes,
  • evaluate the grouping,
  • challenge the interpretations,
  • account for the interview context,
  • connect the findings with other sources,
  • decide what actually matters.

AI Can Shorten the Process. It Should Not Shorten the Path to Evidence

The greatest value of AI in UX research is not that the model can “tell you what users want”.

It cannot.

The value lies in helping the researcher:

  • prepare the plan faster,
  • notice a biased question,
  • organise hundreds of notes,
  • maintain consistent codes,
  • identify contradictions,
  • challenge the first interpretation,
  • prepare material for different audiences,
  • document confidence levels more clearly.

This significantly reduces mechanical work.

It does not reduce responsibility.

The most important division is:

AI Can Help You Identify:

  • possible questions,
  • patterns,
  • gaps,
  • alternatives,
  • contradictions.

The Researcher Must Determine:

  • what constitutes genuine evidence,
  • what it means in the given context,
  • what cannot be concluded,
  • which decision follows from the material,
  • which risks are attached to the interpretation.

AI can organise the material. It cannot live the user’s experience for them.

Do Not Replace Research With Text That Sounds Like Research

A generated persona may look convincing.

A generated quote may sound natural.

A generated insight may have a perfect structure.

A generated report may contain headings, recommendations, and an executive summary.

None of these becomes evidence simply because it has been professionally formatted.

UX research requires contact with reality:

  • behaviour,
  • experience,
  • context,
  • constraints,
  • consequences.

AI can help describe that reality.

It should not invent it.


Do You Want to Use AI in Research Without Losing Control of the Evidence?

The Designer’s AI Playbook includes the Lead → Expand → Refine → Elevate model, a library of 50 UX prompts, and practical workflows supporting:

  • research-plan preparation,
  • interview-guide creation,
  • note analysis,
  • research synthesis,
  • assumption challenging,
  • documentation of confidence levels,
  • turning findings into decisions,
  • communicating results to the team.

The book shows how to use AI as a partner in organising, analysing, and developing research material—without turning generated responses into false research.

Explore The Designer’s AI Playbook →

My Books

Featured Image
Scalable products require scalable decision-making. Strong systems reduce ambiguity, clarify ownership, improve workflows, and help organizations operate under growing complexity.
Featured Image
Most product teams build features. Few build operational leverage. Strong systems reduce friction, clarify ownership, improve workflows, and scale organizational value.
Featured Image
Great UX design is not only about interfaces. It shapes operational reality through workflows, coordination, systems thinking, and organizational clarity.

© Zofia Szuca 2024
Brand and product designer