User Research Insights: Keep the Evidence

User research insights connect what you saw or heard to a clear claim about users in a defined context. A useful insight keeps its source support close enough for the team to check. It also states where the claim stops, including cases that do not fit the pattern.

This guide builds a fictional workshop-booking insight from source notes and a counterexample. The aim is a checked account of the problem, followed by a next step the team can review. Atlas can help compare permitted text; researchers still judge what the sources mean.

What makes user research insights useful

An observation records what happened: someone paused on a page, asked a question, or described a task. An insight adds meaning that helps explain a pattern in its setting. That meaning must stay tied to the research, rather than become a story that sounds plausible but has no support.

Teams use these terms in different ways. GOV.UK's analysis guide calls short statements about what the team learned findings or insights. Dscout's writing guide uses a narrower definition that stresses underlying motives. Agree on your team's terms, then make the support and scope clear whatever label you use.

In this guide, an insight is a short, bounded claim with linked evidence. It may help the team choose what to test, ask next, or explore in more depth. It does not need to promise a redesign. GitLab's handbook distinguishes informative insights from those that need an action, showing why not every useful finding has an immediate fix.

A good statement also lets a reader challenge it. If the claim refers to first-time users, show which sources came from that group. If it proposes a reason for an action, show the accounts that support the reason. The reader should not have to guess which part was observed and which part you inferred.

Separate source notes from your interpretation

Begin with the research question and the material you are allowed to use. Keep the task, study date, participant label, and source location with each excerpt. These details let a reviewer return to the context without relying on your memory of the session or a polished summary alone.

Record what you saw or heard before adding an explanation. GOV.UK's process asks teams to capture observations rather than what they think those observations mean.

A note such as “opened the help page after the booking screen” is narrower than “did not trust the service.” The latter needs more support.

Keep direct speech distinct from a paraphrase. Use quote marks only when the words match the source, and note where they came from. If the transcript is unclear, check the permitted recording or mark the uncertainty. Do not clean up a participant's words so much that the edited quote suggests a different meaning.

Next, group notes that appear to concern the same issue. Do not treat a group title as a proven explanation. “Booking status” is a topic; “users need to know whether their place is confirmed” is a claim you must check.

Our inductive thematic analysis guide covers a fuller method for developing patterns from data.

Preserve the original notes when you draft the claim. A short insight may omit details for ease of reading, but its linked evidence note should keep the task conditions, relevant excerpts, and any caveats. This allows the team to revise the meaning later without starting from a summary that has lost its source trail.

Check the pattern and its limits

Use explicit criteria to review a proposed insight: fit with the question, support from the source, independent cases, and evidence that challenges the claim. These prompts guide review; research quality still requires judgment. They help you see where a concise statement has become too broad.

Count sources with care. Several excerpts from one person may describe a rich account, but they are not several independent users. A transcript and a session note may also record the same event. Keep those links together so repeated documentation does not look like repeated behavior across the study.

Look for another account that could explain what happened. A pause might reflect uncertainty, a slow connection, or a distraction outside the task.

Dscout's guide stresses context and motivation, but the writer must still have support for any proposed motive. When the source cannot distinguish explanations, keep the question open.

Then look for cases that do not fit. Ask whether they weaken the claim or point to a different context. Someone who knew the service well may understand a screen that a first-time user found unclear. Our external validity guide covers the further question of where a finding might apply beyond those studied.

Do not infer population prevalence from a few research sessions. Repeated accounts can help you form a bounded interpretation without showing how common the problem is among all users. State the group and task you studied, and keep any counts as study descriptions unless the design supports a broader estimate.

Build a fictional insight evidence note

Imagine a made-up study of people booking community workshops. The researcher watched booking tasks and asked questions about them. All labels, excerpts, and source details below are fictional teaching material. They do not describe real users, an Atlas study, or a measured problem with lost bookings.

The team is checking a draft insight that people distrust the booking service. The note keeps two pieces of support for a narrower claim, one case that does not fit, and an open question. These play distinct roles in the reasoning, so a striking quote does not carry the whole claim by itself.

Table 1: Fictional evidence note: keep both support and the case that limits the claim, with locations a reviewer could inspect in a real study.

The corrected insight is that booking status was unclear to P1 and P2 during the observed task, while P3 understood it. Their accounts suggest a need to distinguish a confirmed place from any step still pending.

They do not establish distrust, show that all users struggle, or prove that the service caused booking abandonment.

The team can now test whether a clearer account of booking status helps people understand the next step. The proposed test remains untested. A usability test plan turns that question into tasks and observations the team can review.

GitLab's guidance links actionable insights to evidence and a clear next step; the worked note keeps that next step separate from the claim it is based on.

Keep the next step separate

Write the claim before naming a solution. A finding about unclear status does not force the team to add an email, change a button, or build a new dashboard. Each of those ideas carries assumptions. Keep the user problem clear so the team can consider more than one way to address it.

In its published Service Manual research account, the government team describes using draft guidance in research, making changes, and testing again with teams of different digital capability.

This is an original account of a research process, not a controlled estimate of the changes' effect. It shows a way to carry learning into further checks.

Choose a next step that addresses the gap in the evidence. If you lack context, ask a follow-up question. If the proposed explanation is weak, seek cases that could challenge it. If the problem is clear but the fix is uncertain, test the idea.

GitLab's handbook includes further research among possible actions.

Use stakeholder feedback to make the statement clearer without changing what the sources show. The Fountain Institute guide suggests refining insight wording with stakeholders.

A team may find one phrasing more useful, but agreement with the team does not add evidence for the underlying claim.

Compare supporting passages in Atlas

Use only consented transcripts and notes that you are permitted to process in the tool. Check the rules covering participant data before uploading. Remove names or restricted details as required, and retain only the context needed for the task. Permission to read a file does not always mean permission to share it with a tool.

Open the project containing those files and mention the relevant items with @. Name the study question and the claim you want to check.

Choose Project only to prevent new web or literature searches; earlier chat context remains available. Keep that context in mind when judging where a response's reasoning came from.

Ask for a comparison such as: "Find passages in these named notes that support or challenge the booking-status claim. Keep participant labels and source locations. Separate observations from proposed explanations, and mark questions the notes do not answer." Treat the output as a draft reading aid, not a completed research analysis.

Atlas citation-inspection capture showing ColPali by Manuel Faysse and colleagues (2025), released under CC0 1.0. No paper content was edited. The capture illustrates citation inspection, not the fictional booking study or an insight accuracy test.

Open the citations and check the source text yourself. Confirm that an excerpt says what the response claims and that nearby context does not change its meaning.

Our citation tracking guide explains why a source link still needs review. Search the original material when a missing passage could change the claim.

Correct the insight and retain its counterexample in a note. Select New, then Note, and wait for Saved before closing.

For larger source sets, our research synthesis guide explains how to keep claims tied to sources. Researchers decide whether the final interpretation fits the study and what the team should do next.

Review the claim with the team

Ask someone who observed the research to review the note with its supporting passages open. Have them check the task context, inferred meaning, and cases that do not fit. The claim should remain clear to a colleague who did not attend the session, without hiding the parts that still need judgment.

Agree on the final scope, any open question, and who owns the next step. Keep the evidence note linked when you share the insight. If later research changes the pattern, revise the claim and its boundaries together so the team can see what changed and why.

When several checked insights need a shared account of the study and its limits, use a UX research report to present them together.