How to tell if a user is telling you the truth

You usually cannot tell whether a user is telling the truth by watching their face, listening for hesitation, or judging how convincing they sound.

Instead, assess the answer itself:

1. Ask about one recent event, not a general opinion or future intention.
2. Reconstruct what happened before, during, and after it.
3. Look for details you can compare with artefacts, product data, or another account.
4. Separate evidence of a problem from enthusiasm for your proposed solution.
5. Triangulate before making a consequential product decision.

This approach does not expose a liar. It produces answers that are more specific, testable, and useful—even when the participant is sincere but mistaken.

Why you cannot read honesty from behaviour

The strongest reason to stop reading body language is that people are poor at it.

Bond and DePaulo’s meta-analysis of deception judgements synthesised 206 documents involving 24,483 judges. Without special aids or training, people classified lies and truths correctly 54% of the time. They identified 61% of truths but only 47% of lies.

That result comes from deception studies, not user-research sessions. The setting is different, but the practical warning transfers: your impression that someone seems honest is weak evidence.

A separate meta-analysis of 158 potential deception cues found that many behaviours had no discernible relationship with deception and others had only weak relationships. A 2023 review reached the same broad conclusion: humans are barely able to detect lies from nonverbal cues, while more systematic verbal methods still require great caution.

Do not downgrade an answer because the participant looks away, pauses, fidgets, speaks slowly, or sounds nervous. Those behaviours can reflect memory effort, personality, language, disability, culture, stress, or the interview itself. They are not a reliable roadmap filter.

Most unreliable feedback is not a deliberate lie

When an interview misleads a team, the participant may have answered in good faith. Three ordinary mechanisms can still make the answer unreliable.

Social desirability

Participants infer what the interviewer wants. A customer may soften criticism when speaking to the founder who built the product, or praise an idea because rejecting it feels needlessly rude.

This is why leading questions are so damaging. “Would this save your team time?” reveals the preferred answer. “Tell me about the last time this task took longer than expected” gives the participant room to describe what actually happened.

Imperfect memory and explanation

People can remember the event incompletely and still feel certain about their explanation. Nisbett and Wilson’s influential paper on verbal reports of mental processes argued that people may have limited direct access to the higher-order processes behind some judgements and choices. Later work has debated how broadly that conclusion applies, so the useful lesson is not that every explanation is invented. It is that a confident reason should remain a hypothesis until other evidence supports it.

Prediction error

“Would you use this?” asks someone to predict how a future version of themselves will behave when time, money, colleagues, and competing priorities become real.

Teresa Torres makes the distinction concrete in her guide to story-based customer interviews: future-facing solution questions tend to produce answers from an idealised self. Specific stories about past behaviour reveal context, constraints, and unmet needs.

A participant can therefore be honest and wrong at the same time. Your method has to protect the decision from that gap.

Stop asking “Is this true?” Ask “What can this answer support?”

Interview statements have different evidential value. Treating them all as equally true or false throws away that distinction.

The goal is not to make every answer prove everything. It is to use each answer only for the claims it can reasonably support.

Five ways to make an interview answer more credible

1. Anchor the conversation to a recent event

Ask for one incident that the participant can reconstruct:

• “When was the last time that happened?”
• “Take me back to the last report you prepared.”
• “Tell me about the moment you decided to cancel.”

If the answer stays general—“we do that all the time”—gently narrow it: “Let’s use the most recent example. What was happening that day?”

Recent does not automatically mean true, and memory still has gaps. But a bounded event gives you something to examine. General opinions do not.

This is also why the distinction between open-ended and closed questions is not enough. The strongest opening question is usually both open and tied to a specific past event.

2. Reconstruct the sequence

Move through the event without suggesting the answer:

• “What happened just before that?”
• “What did you do next?”
• “Who else was involved?”
• “Where did the work move after that?”
• “What happened in the end?”

You are listening for a workflow, not interrogating the participant for inconsistencies. A sequence shows where the problem began, what the person tried, which constraints appeared, and what consequence followed.

Avoid repeated “why” questions that demand a tidy explanation. Neutral prompts such as “What made that important then?” or “What led to that step?” keep the answer connected to the event. See the guide to asking why without asking why for more examples.

3. Follow the participant’s words

Vague labels hide different experiences. When a participant calls something “slow”, “manual”, “confusing”, or “easy”, ask what the word means in that situation.

• “You said the hand-off was manual. What did you have to do?”
• “What made that screen confusing?”
• “You called the process slow. How long did it take that time?”

Do not translate the answer into your product vocabulary too early. “Manual” might mean copying data, waiting for approval, checking for mistakes, or persuading another team. Each points to a different opportunity.

4. Ask about behaviour and artefacts

Useful follow-ups include:

• “What did you do instead?”
• “Did you create anything to make that easier?”
• “Where did you record the result?”
• “What did the error message say?”

A workaround, calendar event, support ticket, document, or product trace can corroborate part of the story. Ask for artefacts only when appropriate, with the participant’s permission, and never encourage someone to expose confidential or personal information.

The absence of a workaround does not prove that the problem is unimportant. Some people tolerate pain, abandon the task, or lack permission to change the process. Artefacts strengthen an account when they exist; they are not a pass/fail test.

5. Separate problem evidence from solution evidence

Suppose a participant describes a painful monthly export and then says your automation idea sounds excellent. You have two different pieces of evidence:

• the past story supports the existence and shape of the problem;
• the positive reaction supports interest, not adoption.

Validate the solution with a method that includes a real trade-off: a usable prototype, an invitation to join a pilot, a change in workflow, payment, or observed use. The appropriate test depends on the risk you need to reduce.

This is the core lesson of The Mom Test for founders: compliments and future promises should not outweigh concrete past behaviour or meaningful commitment.

Use a credibility ladder, not a truth score

After the interview, label important claims by the support behind them.

1. Opinion: a preference, reaction, or interpretation.
2. Reported event: a specific past experience with a time and context.
3. Detailed account: a sequence containing actions, constraints, people, and consequences.
4. Corroborated account: part of the story matches an artefact, behavioural data, or another source.
5. Repeated pattern: similar evidence appears across relevant participants or data sources.

This is not a scientific scale, and the fifth level is not “true”. It is a practical way to prevent a vivid quote from carrying more weight than the evidence behind it.

Keep contradictory cases. If four participants describe one workflow and a fifth describes another, do not average the fifth away. Check whether role, company size, plan, experience, or context explains the difference. Qualitative research becomes more useful when it preserves variation instead of forcing consensus.

The interviewer changes the answer

Question wording is not the only source of pressure. The participant is also responding to who asks, what that person appears to want, and how private the conversation feels.

A 1999 meta-analysis of administration modes found less socially desirable responding in computerised interviews than in face-to-face interviews, while computer and paper questionnaires were broadly similar overall. A review of sensitive questions in surveys also found that self-administration can improve reporting of socially undesirable behaviours.

These studies concern questionnaires, sensitive topics, and older computerised interview formats. They do not prove that an AI interview automatically produces more honest customer research. Interface, privacy expectations, question design, study topic, and trust still matter.

The practical implication is broader: reduce the participant’s need to manage the interviewer.

• Explain the research purpose without revealing a preferred conclusion.
• Say that criticism is useful and questions can be skipped.
• Avoid defending the product or explaining the feature mid-interview.
• Use neutral follow-ups.
• Be clear about who will see the answers and how they will be used.
• Let someone without a personal stake moderate when the founder’s presence would add pressure.

Triangulate before changing the roadmap

An interview produces an account. A consequential decision needs more than one account.

Compare the story with the evidence available for the question:

• product events and usage frequency;
• support conversations or sales notes;
• billing, activation, retention, or cancellation data;
• workflow artefacts supplied with permission;
• usability observation;
• accounts from other relevant participants.

Nielsen Norman Group’s warning about self-reported behaviour is deliberately blunt: preference, remembered behaviour, and observed performance are not interchangeable. Interviews are valuable because they explain context and meaning. Analytics is valuable because it records what occurred in the product. Use each for the job it can do.

If the sources disagree, do not decide which one is “the truth” too quickly. The mismatch is often the next research question. A participant may use a feature frequently but still find it painful, misunderstand what counts as an export, share an account with colleagues, or describe a workflow that happens outside your instrumentation.

How Maren supports evidence-focused interviews

Maren turns a research objective into an adaptive interview and follows threads in each participant’s answers. That makes it easier to ask for a recent example, clarify vague words, and collect comparable stories without scheduling every conversation. Maren then creates interview summaries and synthesises themes across the completed interviews.

The tool does not turn an answer into ground truth. Teams still need appropriate participants, neutral objectives, transparent privacy practices, and external evidence for claims that require corroboration. Maren helps conduct and organise the conversations; researchers remain responsible for what the evidence can support.

Frequently asked questions

How do you know if someone is lying in a user interview?

You usually do not. Body language, hesitation, and confidence are unreliable indicators. Ask about a specific recent event, explore the sequence, and compare material claims with behaviour, artefacts, or other sources.

What is the strongest sign that user feedback is credible?

There is no single sign. A specific account that includes actions and consequences is more useful than a general opinion, and independent corroboration makes it stronger. One answer should still not establish how common a problem is.

Can users be honest and still give inaccurate feedback?

Yes. Memory is incomplete, people may not know every cause of their behaviour, and future intentions often fail to predict action. Treat explanations and predictions as evidence with limits, not as facts or lies.

Should I ignore what users say and only use analytics?

No. Analytics shows what happened in an instrumented system; interviews can reveal goals, constraints, workarounds, and meaning. Strong research combines them.

Make the answer testable

You do not need to decide whether a participant is an honest person. You need to decide what their answer can support.

Start with a recent event. Follow the sequence. Clarify their words. Ask about actions and artefacts. Then compare the account with other evidence before it changes the roadmap.

The most useful interview answer is not the one that sounds true. It is the one you can understand, bound, and test.