Skip to content
be-human.ai
← Back to the journal

AI by industry

AI for UX Research Teams: Evidence Memory That Cites Sources

How a UX research agent turns interview notes, themes and past findings into a searchable evidence memory that cites the exact source session.

Be Human typographic cover with the title: AI for UX Research Teams: Evidence Memory That Cites Sources
Conceptual illustration created with AI · Be Human

AI for UX research teams works best as an evidence memory: an agent that holds interview notes, themes and past findings, answers questions from them, and names the source session behind every claim. It does not replace the researcher's judgment. It makes sure that what the team already learned stays findable, checkable and usable when the next decision arrives.

Key takeaways

  • An evidence memory stores sessions, excerpts, themes and decisions as linked records, not as a pile of slide decks.
  • Every answer should point to a session, a participant reference and a place in the notes, or say plainly that no evidence exists.
  • Researchers keep interpretation, consent and the final word on what a theme means. The agent retrieves, compares and drafts.
  • Start with one question type and a small set of past studies, and test the citations before widening access.
  • Permissions, retention rules and review logs matter as much as the model, because research data is personal.

What is an evidence memory for UX research?

An evidence memory is a structured body of research that an agent can search and quote from. It is different from a shared drive with a search box. A drive finds files. An evidence memory finds the specific moment in a specific session where a participant did or said something, and shows how that moment was later grouped into a theme and used in a decision.

A useful memory has four layers, each linked to the one below it:

  • Sessions: one record per interview or usability test, with study name, date, method, a pseudonymous participant code, consent scope and a pointer to the recording or transcript.
  • Excerpts: short passages with a timestamp or page reference and the tags your team already uses.
  • Themes: claims written by researchers, each linked to the excerpts that support it.
  • Decisions: what the team changed, deferred or rejected because of a theme, and who agreed.

The agent sits on top of these layers. It uses retrieval, the approach described in the AWS explainer on retrieval-augmented generation, where a model answers from an approved set of documents instead of from general knowledge. The practical result is that the agent's answers are bounded by what your team actually recorded.

Why do findings stop being used after the readout?

Most research is consumed once. A readout happens, a deck circulates, and the decision gets made. Six months later the deck is in a folder nobody opens, the researcher has moved to another project, and the raw notes sit in a tool only the original team understands. The real index of the research was a person's memory, and that index does not scale or stay.

The cost shows up in small, repeated ways. A new product manager commissions a study that mostly repeats an earlier one. A designer cites a finding from a deck without knowing it came from a single prototype session. A stakeholder remembers a quote slightly differently each time it is retold, and the nuance drifts.

Illustrative scenario: a product manager asks whether small business owners understand the invoice export step. The agent returns excerpts from three sessions across two earlier studies. It notes that two sessions used a prototype and one used the live product, that one participant described the same step as confusing in a later session, and that the team's theme on this topic was written before the export screen changed. Each point carries a reference the researcher can open. The manager gets a grounded starting point, and the researcher gets a short list of what to verify instead of a day of digging.

The same pattern applies wherever customer signal piles up. Customer success teams hold their own version of it in renewal notes and health conversations, and product groups described in software development teams often need research evidence at planning time. The memory is most valuable when it can be asked questions from several of those directions, with each source type kept distinct.

How does the agent cite the source session every time?

Citation is a design rule, not a hope about model behavior. Three pieces make it dependable.

First, stable identifiers. Every session and excerpt gets an ID that does not change when files are renamed or moved. The citation names the study, the session, the participant code and the position in the notes or recording. Anyone clicking through should land on the supporting passage in a few seconds.

Second, just-in-time retrieval. Anthropic's guidance on context engineering for agents argues for loading only the information relevant to the task, at the moment it is needed, rather than filling the context with everything. For research, that means the agent pulls the handful of excerpts that match the question, plus the themes they belong to, and reasons only over those.

Third, written answer rules. A short set of rules the agent follows on every response:

  • Make a claim only if a retrieved excerpt supports it, and attach the reference right after the claim.
  • Separate what a participant said or did (observation) from what the team concluded (interpretation).
  • Mark paraphrase as paraphrase and quote only text that exists in the record.
  • Show conflicting evidence next to supporting evidence, not after it.
  • State the age, method and study context of each source, since a prototype test from long ago says something different from a recent live-product interview.
  • If nothing relevant is found, say so and suggest what kind of study would answer the question.

That last rule matters most. A research assistant that always produces an answer will eventually produce a fluent one with nothing behind it. An agent allowed to say that it found no evidence is far more useful to a decision maker.

How do you build one? A step-by-step plan

Keep the first version small enough that a researcher can check all of it by hand.

  • Pick one question type, such as what do we already know about a topic before a roadmap review.
  • Choose a small set of past studies that a researcher knows well enough to judge the answers.
  • Normalize the records so each session has study, date, method, participant code, consent scope and a link to the raw material.
  • Split notes into excerpts with timestamps and your existing tags. Link each researcher-written theme to the excerpts that support it.
  • Write the answer rules above and give them to the agent as fixed instructions, not suggestions.
  • Test with questions whose answers you already know. Open every citation and confirm the passage says what the agent claims. The Anthropic article on evals for AI agents is a good model for turning these checks into a repeatable set that you rerun after every change.
  • Release to a small group, review the log of questions each week, fix gaps in the records, then add more studies.

The order matters. Teams that connect every repository first and test later end up with an agent that sounds authoritative and cites loosely. Teams that begin with a few trusted studies learn quickly where the records are thin.

What should stay with researchers, and what needs guarding?

Research data describes real people, often in detail. The agent should make good practice easier, not weaken it.

Researchers keep these responsibilities:

  • Deciding what a pattern means and whether it is strong enough to act on.
  • Writing and revising themes. The agent can propose a draft grouping, but a person approves it before it enters the memory.
  • Judging whether a past finding still applies to a changed product or audience.
  • Handling consent, including what participants agreed to and what happens when someone withdraws.

The system needs these safeguards:

  • Permission checks on every retrieval, based on who is asking. The OWASP authorization guidance recommends least privilege and enforcement on the server side, which here means the agent cannot read sessions the requester is not allowed to see.
  • Consent scope stored with each session, so material gathered for one purpose is not quietly reused for another.
  • Pseudonymous participant codes in the searchable layer, with the key linking codes to identities held elsewhere under tighter control.
  • Treatment of transcripts and imported documents as data, never as instructions. A participant who says ignore your rules in a recording should have no effect on the agent.
  • A deletion path: when a participant withdraws, their records, excerpts and any theme that depends only on them are updated, and the change is logged.
  • A read-only relationship to raw sources. The agent can cite them but cannot edit or delete them.

If your team operates in a regulated sector, or collects sensitive topics such as health or finances, involve whoever owns privacy before the first study enters the memory, not after.

How does Be Human run this for a research team?

Be Human treats the agent as one defined role with its own memory, tools and limits. For a UX team that role is usually a research librarian: it answers evidence questions, drafts theme summaries for review and flags stale or thin findings. A first engagement defines that role, the records and tools it needs, the approval boundaries (for example, theme changes go to a researcher before they are stored) and an observable success criterion, such as whether sampled answers cite passages that actually support the claim, as judged by a researcher.

After launch, managed operations can include monitoring of questions and failures, recurring evaluations of citation quality, integration maintenance when your research tools change, permission review and controlled improvements. The agent's identity, memory and access stay under your team's control, and the service is delivered remotely in English and Portuguese.

If you want to find the first task worth handing to an agent, take the free Be Human AI diagnostic.

Frequently asked questions

Can an AI agent replace UX researchers? No. The agent is good at retrieving, comparing and drafting from existing records. Deciding what evidence means, running new studies, handling participants with care and persuading stakeholders remain human work, and the agent gives researchers more time for them.

What do we need before starting? You need past research in a form that can be split into sessions and excerpts, even if it is rough, plus a person who can judge the answers. Consent information for each study is also required, because it determines what the agent may surface and to whom. Clean tagging helps but can be improved while the first version runs.

How do we stop the agent from inventing quotes? Restrict it to answering from retrieved records, require a reference after every claim and only allow direct quotation of text that exists in the excerpt. Then test this by opening citations in a sample of answers on a regular schedule. If a quote cannot be found at its cited location, treat it as a defect and fix the retrieval or the rules.

Do we have to replace our current research repository? Usually not. The agent can read from the repository you already use if the records have stable identifiers and the permissions are clear. The main work is making sessions, excerpts and themes consistent enough to link, not moving them to a new tool.

Your next step

See where an AI agent fits in your company first.

Take the free Be Human AI diagnostic. A few questions about your work show which task to hand to an agent first, what it needs to know and where a person approves.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.

Less busywork. More room for you.

Bring us the work you wish you had time for.

Book a call to try a personalized AI agent free for 7 days ↗Or take the free AI diagnostic →