AI for UX Designers: Research Synthesis and Test Summaries

A small UX studio can use AI to synthesise research by feeding it cleaned, anonymised notes one session at a time, asking for tagged observations with note IDs, grouping them into themes, and then checking every theme and quote against the raw material before it reaches the client. AI drafts; a designer decides what the evidence supports.

The common failure is asking one big prompt to "summarise all the interviews". You get a fluent, plausible report with no trail back to what anyone said, and a client who asks "where did that come from?" finds you have no answer. The workflow below keeps a trail at every step, so speed does not cost you credibility.

Follow me on Instagram@sagnikteaches

The studio setup this workflow assumes

Picture a four-person studio with two researcher-designers, a lead and a part-time project manager, running a round of eight 45-minute interviews and five 30-minute usability sessions for a client's booking app. All figures here are illustrative. Before AI, the team spends roughly two days per round turning notes into a deck. The aim is not to cut that to zero but to move the time from typing and sorting to checking and thinking.

Connect on LinkedInSagnik Bhattacharya

You need three things in place before any note touches a tool:

Subscribe on YouTube@sagnikteaches

• A consent form that covers processing. Read yours. If it says recordings are shared only with the research team and client, a third-party tool is outside that unless you say otherwise. Fix the form for future rounds and redact for this one.
• A tool decision you can defend. Business-tier chat assistants (ChatGPT Business, Claude Team) do not train on your content by default, according to the vendors' own business terms. Individual plans let you switch training off in settings, but that setting belongs to one person, not the studio. Both business plans need at least two seats. For a studio, a shared team plan is the cleaner route; see what to check in an AI tool's privacy terms.
• A naming scheme for notes. Every session gets an ID (P01 to P08 for interviews, T01 to T05 for tests) and every paragraph a number inside it. This is what makes quote checking possible later.

Specialist research repositories such as Dovetail now include AI summaries and chat. Its pricing page currently lists a Free plan at $0 for individuals, limited to one project and one channel, with AI chat and automatic summaries inside that project, and an Enterprise plan on custom pricing with unlimited projects and AI agents. One project means one client study at a time, so the free tier suits a trial round rather than a studio's whole workload. A repository earns its place when you run research continuously for several clients; for a project-based studio, a chat assistant plus a spreadsheet is enough to start.

Step 1: Clean and anonymise before upload

Transcripts from recording tools are messy: filler words, the product name misspelt, two speakers merged. Spend ten minutes per session on this, because everything downstream inherits the errors.

1. Replace participant names with the ID (P03), employers with "[employer]", and any phone numbers, emails or addresses with "[redacted]".
2. Label speakers as "Interviewer" and "P03". A transcript where the AI cannot tell who said what will attribute your questions to the participant.
3. Add the session context as a header: date, participant segment (for example "occasional user, books monthly"), and the task list for usability sessions.
4. Number each paragraph or timestamp block: P03-01, P03-02 and so on.

You can use the AI to do a first redaction pass, but treat it as a first pass only: names are easy, but a sentence like "I run the third-floor clinic on the corner" identifies someone without any name in it. A human skims every file before upload. If you are not comfortable uploading even redacted material, keep this step manual and use AI later on the observation list only.

Step 2: Turn each session into tagged observations

Work one session at a time. A single prompt over thirteen sessions makes the model average them; one session at a time keeps each participant's words separate and the output small enough to check.

You are helping a UX research team. Below is an anonymised transcript with numbered blocks.

Task: list every distinct observation about the participant's behaviour, goals, problems or workarounds.
For each observation give:
- ID: the block number(s) it comes from
- Type: behaviour / goal / pain point / workaround / quote-worthy statement
- Observation: one sentence, stating what they said or did, without interpretation
- Verbatim: the exact words from the transcript, if any (otherwise "none")

Rules: do not infer motives. Do not merge observations from different blocks. If something is unclear, say "unclear" rather than guessing.
Transcript:
[paste]

A realistic sample output for one block, labelled illustrative:

ID: P03-14
Type: workaround
Observation: Books appointments by phone after the app rejected her card twice.
Verbatim: "I gave up and rang them, it was quicker."

What you fix: the model sometimes writes "gave up on the app in frustration". Strike "in frustration" unless she said so; that is interpretation. Paste the cleaned lists into a spreadsheet with columns for ID, type, observation, verbatim and theme. One row per observation, about 40 to 70 rows per interview, is normal.

Step 3: Group into themes with a rule against averaging

Now give the model the combined observation list, not the transcripts. Ask for groupings that name the pattern and count distinct participants, not mentions.

Here is a table of observations from 8 interviews (IDs start with P01 to P08).
Group them into candidate themes. For each theme give:
- A short name phrased as a problem or need
- The observation IDs that belong to it
- The number of DIFFERENT participants represented
- One observation that seems to contradict or complicate the theme, if any
Do not create a theme supported by only one participant unless it describes a serious failure (payment, safety, data loss). Put those in a separate list.

Counting participants rather than mentions matters. One talkative participant can mention card errors six times; that is one person. A client who reads "card errors came up 14 times" will assume wide impact.

Illustrative result for the booking app: five themes emerge. "Payment failures push people to the phone" has P02, P03, P05 and P07, so four of eight. "Unclear cancellation rules" has three. The model also flags that P06 contradicts the first theme because P06 never tried to pay in the app at all. That contradiction goes in the report; a good synthesis includes the participant who does not fit.

The human pass that cannot be skipped

Print or project the themes with their observations and spend 30 to 45 minutes as a team. Move items, split a theme that mixes two problems, merge two that are really one. Ask of each theme: what would make me wrong? In practice this pass catches the AI's habit of grouping by topic ("payments") when the real pattern is a cause ("error message gives no next step"). Record any changes in the spreadsheet so the final theme list is yours, not the model's.

Step 4: Check every quote against the source

This is the step that protects your reputation. Models paraphrase while appearing to quote, tidying grammar and sometimes merging two sentences. For each quote that will appear in the deliverable:

1. Take its block ID from the spreadsheet.
2. Search that block in the original transcript for the exact string.
3. If it differs, correct it to the original or mark it as a paraphrase without quotation marks.
4. Mark the row "verified" with the checker's initials.

For a report with 15 quotes this takes about 15 minutes. A single invented quote discovered by a client costs far more than that. For more on tidying quotes into usable stories, see turning customer interviews into case studies, which covers the consent side as well.

Usability test summaries: a different shape of data

Interviews give you opinions and stories; usability sessions give you task outcomes. Treat them differently. For each session, record the task, the result (completed, completed with help, failed, abandoned), time taken, and the moment things went wrong. Take this tally from the facilitator's log, because a chat model cannot see the screen unless you give it a recording and a tool that handles video, and even then an observer's log is the better record.

Use AI for the narrative around those numbers. Give it a table like this one (illustrative):

Then ask for severity ratings with reasons using a scheme you define yourself, for example a 1 to 4 scale: cosmetic, minor, serious, blocker. Without definitions, models rate everything "high". With a sample size of five, say plainly in the report that these are qualitative findings, not percentages of your client's users. Write "3 of 5 participants" and never "60% of users".

Sample prompt for the narrative:

Using the task table and the observation list for sessions T01 to T05, write a findings summary.
For each task: result, the problem in plain words, the observation IDs that support it, and a severity (1 cosmetic, 2 minor, 3 serious, 4 blocker) with a one-line reason.
Do not recommend a design solution. Do not mention numbers that are not in the table.

Keeping recommendations out of this prompt is deliberate. Recommendations are your professional judgement, shaped by the client's constraints and what you know of the product. Ask the AI for design options in a separate step if you want brainstorming, and label them as options.

Writing the client report

A layout that works for small clients and avoids a 60-page deck:

1. One-page summary: three to five findings, each with severity, the evidence count (participants) and one verified quote.
2. Method in three lines: who, how many, how recruited, and the AI-assisted steps stated plainly.
3. Findings pages: one per theme with observation, evidence, severity and your recommendation.
4. Appendix: the task table, the contradicting cases, and a link to the observation spreadsheet if the client has agreed to share it.

The AI can draft the plain-English paragraphs on each findings page from your checked spreadsheet. Give it your table, not the transcripts, so it can only write what you have already validated. A good test: every sentence in the draft should be traceable to a row. If a sentence has no row, delete it or find the evidence.

Five more situations and how to handle them

A participant contradicts the team's favourite idea. Make the AI work on the contradiction: ask it to list every observation that weakens the theme the lead likes best. This reduces confirmation bias, which AI otherwise amplifies when you ask leading questions like "find evidence that users want a dashboard".

The transcript is poor. Auto-transcription of accents, jargon and cross-talk goes wrong. When a block reads oddly, listen to the audio for that block. Ask the model to flag low-confidence passages ("mark any block where words look mistranscribed") rather than silently repairing them.

A client wants a stakeholder-friendly one-pager. Ask for a version for a non-designer in 150 words, from your verified findings only, then edit. This is a good low-risk use because the checking is already done.

Interviews are in several languages. Translate each session with the model, but keep the original-language verbatim next to the translation in the spreadsheet, and have a fluent speaker verify the quotes that reach the client.

A participant shares something sensitive. If a transcript touches health, money trouble or anything the person would not expect the client to see, remove it at Step 1, whatever the model could do with it. Your consent promise governs, not the tool's capability.

A before and after on one messy block

Here is a raw block as a transcription tool might produce it (illustrative):

P05-22  yeah so um I I tried to like put the deposit thing in and it just said error and then I thought maybe it was my bank so I tried the other card and same thing and honestly my wife does the booking usually so

A weak extraction reads: "P05 was frustrated by payment errors and prefers not to use the app." Two claims there are unsupported: "frustrated" and "prefers not to use". A good extraction reads: "Tried two cards for the deposit, got an error both times, no next step mentioned. Says his wife usually does the booking." The second line is less dramatic and much more useful, because it hints at a different user (the household booker) that the team had not recruited. That is the sort of thing a designer notices and a summary averages away, so add a column for "unexpected" in the spreadsheet and ask the model to flag anything that does not fit the brief's assumed user.

Mistakes that show up on real projects

Summarising a summary. A team pastes the model's session summaries into a second prompt and asks for themes. Detail drops out at each pass, and rare but serious problems vanish. Always go back to the observation list, which is closer to the source.

Letting the model rename the client's vocabulary. Participants say "the deposit thing"; the client calls it "pre-authorisation". The model silently picks one. Keep the participants' words in the verbatim column and add the client's term only in the recommendation.

Treating a tidy report as a validated one. A well-written paragraph feels more certain than a scrawled sticky note. Ask each reviewer to read the evidence column first and the prose second.

Running the whole round through a free personal account. It is quick, but the data sits under one person's settings and history. If that person leaves, so does the project record. Use a studio-owned workspace and keep the spreadsheet in shared storage, as you would any other client file.

Adapting it to a one-day sprint

Some clients want five sessions on Tuesday and findings by Thursday. Compress the workflow rather than skipping the checks. Have one designer extract observations during the day while sessions run, a second person group them straight after the last session, and the whole team do the 30-minute challenge pass the next morning. Cut the report to the one-page summary plus the task table, and say in the method line that the findings come from a short sprint with five participants. Quote verification still happens; it only takes 10 minutes for six quotes. What you drop is the appendix and the contradiction analysis, and you tell the client those are not in this round.

Keeping a research log the next project can reuse

At the end of each round, save three things in the client folder: the final observation spreadsheet with its verified flags, the prompts you actually used (with edits), and a half-page note on what the model got wrong this time. After three projects that note becomes your studio's own checklist, for example "always check it has not merged the interviewer's question into the answer" or "it rates anything involving payment as a blocker, so apply our definitions". Prompts that survive three projects go into a shared document, and a business-plan project or shared workspace can hold them so a new hire starts from the same instructions. Delete raw transcripts when the contract says to; the anonymised spreadsheet can usually stay as your working record, but confirm that with the client in writing.

Time and cost for the example round

For the illustrative round of 13 sessions: cleaning and redaction about 2.5 hours; observation extraction about 1.5 hours including checks; theme grouping 30 minutes plus a 45-minute team pass; usability task table 1 hour; quote verification 15 to 30 minutes; report drafting and editing 3 hours. That is around 10 to 11 hours of work against the studio's previous two days (about 16 hours) for the same round. Treat that as a guess to test on your own project, not a promise. Tool cost: ChatGPT Business and Claude Team both list Standard seats at $25 a month, or $20 a month billed annually, with a two-seat minimum, so the shared studio workspace starts at $40 to $50 a month. Claude Pro for a single researcher is $20 a month ($17 billed annually), and the Dovetail free tier is enough to try one project. Check each vendor's page before you commit, because seat prices and plan names change.

How to check the synthesis is sound

• Pick three findings at random and trace each back to raw transcript blocks. If any trace fails, redo the step for that theme.
• Count: every theme's participant number should match a manual count of the IDs.
• Look for a missing theme: reread two transcripts cold and ask whether anything important never appears in your report.
• Read severity ratings aloud to someone who has not seen the data. If they would rank them differently, discuss why.
• Ask the client one question after delivery: did anything in this report surprise you? Surprise is the sign the research did its job.

If you would like help setting this up around your studio's own clients, that is what my AI implementation consultation covers. For the conversations around the research, see AI for client research before discovery calls and how coaches turn session notes into follow-ups, which uses the same note-then-check pattern.

Questions studios ask before using AI on research

Do I need participant consent to put transcripts into an AI tool?

Check your consent form and the client's contract first. Many forms only cover the research team and the client. If the wording does not mention processing by a third-party tool, either amend the form for future sessions or redact names and identifiers before upload. Ask the client's legal contact when unsure.

Can AI replace affinity mapping on a wall?

It can produce a first set of groupings in minutes, but the team should still move, rename and challenge them. The sorting is where designers build shared understanding of the data, so keep at least one human pass, even a short one.

How do I stop the AI inventing user quotes?

Ask for quotes only with a note ID, then search the source transcript for each one. A quote that cannot be found word for word is deleted or marked as a paraphrase. Do this check on every quote that reaches the client.

Should I tell the client I used AI?

Yes, in one line in the method section and in your terms, saying which steps AI assisted and that a designer checked every finding against the raw notes. Clients rarely object when the checking is clear.

Further reads

• How Interior Designers Use AI for Mood Boards and Presentations — Another design-studio workflow where client approval matters.
• Questions to Ask Before Buying AI That Touches Client Data — Questions to put to a vendor before research data goes in.
• Using AI for Product Design: Client Feedback Rounds and Revisions — Handle the client feedback that follows your findings.
• Design Studios Using AI: Briefs, Moodboards and Client Revisions — Briefs, moodboards and revisions in the same studio setting.
• How to Mention AI Use in Client Contracts and Proposals — Wording for telling clients how AI is used on their work.
• Using AI in Management Consulting: Synthesise Stakeholder Interviews — A practical interview-to-theme workflow with a coded example, evidence table and contradiction check.
• AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.

Sources: Dovetail pricing page; ChatGPT Business pricing page and OpenAI data controls help article; Claude pricing page; all checked 4 November 2026.