How to Test Whether People Understand Your Client Intake Questions

Define a usable answer before the session

Write a private note for each question: what fact or judgment is needed, who can reasonably know it and what decision will use it. For a website availability date, specify whether the team needs a firm external deadline or an aspirational target. Those answers can require different planning even when the dates match.

Also define what the question must not imply. An intake answer should not accidentally become a promise that a studio has accepted the deadline. If the team only needs to start a scheduling conversation, the question and surrounding copy should support that limited purpose.

Use this note as a comparison point, not a script to teach participants before they answer. Showing your definition first would conceal the very ambiguity the test needs to expose. If colleagues cannot agree on the information needed, resolve that business decision before polishing the wording.

Choose people who bring the relevant differences

Invite people who could plausibly complete this intake, including differences likely to affect the answer. A first-time website buyer may interpret technical terms differently from a marketing manager. Someone requesting a quote may have less information than the person responsible for approving it. Colleagues who already know the internal vocabulary are useful for rehearsal, but cannot stand in for every intended respondent.

Explain the purpose of the session and how notes or recordings will be used; obtain agreement before recording. Make clear that the wording is being tested and that uncertainty is useful feedback. Keep unnecessary personal or confidential project details out of the test record.

Use a realistic context without supplying the answer. A fictional project can protect sensitive details, but it cannot reveal everything about whether someone could find the information in their actual work. Record that limitation. Include the surrounding instructions and preceding questions, because an isolated sentence may be understood differently in the real sequence.

The CDC describes cognitive interviewing as a way to investigate how respondents interpret and answer questions. Its purpose is to uncover problems in the response process; it is not a method for estimating how common those problems are across all clients.

Let the first answer happen, then ask neutral follow-ups

Ask the participant to read and answer as they ordinarily would. Avoid explaining unfamiliar terms or pointing toward a preferred response. Note requests for help and any assistance you provide. An answer produced after your explanation is different evidence from an answer produced without help.

After the answer, ask for the question in their own words. Follow with a prompt suited to the uncertainty: “What does launch mean here?”, “What information did you use to choose that date?” or “Was there an answer you wanted to give but could not?” Explore the explanation rather than treating a quick answer as proof of understanding.

Avoid “Was that clear?” and “You understood that as the website going live, right?” The first can produce a polite verdict without revealing meaning; the second supplies the interpretation. “What did you take that to mean?” gives the participant room to expose a difference.

GOV.UK’s moderated-testing guidance recommends neutral task instructions and leaving room to observe and listen. Apply that principle here: keep an observation of what the participant did separate from the explanation they later offer. A pause alone does not tell you why answering was difficult.

Example: a valid date, a different meaning

Hypothetical example: a web studio asks, “When is your launch?” The studio wants to know when a replacement website must be available to customers. A participant enters 15 June because that is when the business plans to announce its new identity. They expect the site itself to be ready in July.

The date field accepts the answer, and the participant reports no difficulty. The mismatch appears only when the interviewer asks what will happen on 15 June. The problem is the meaning of launch, not the participant’s ability to enter a date.

The studio revises the question to “When would you like the new website to be available to customers?” It asks separately whether that is a target or a deadline tied to an event. If the date is undecided, the intake needs an honest way to communicate that rather than forcing an invented date.

The new wording is a possible fix, not evidence that the problem is solved. Try it with people who have not heard the explanation, including someone with an event deadline and someone still exploring the project. Check what each date refers to and how they describe its flexibility.

Diagnose the obstacle before changing the control

If the participant interprets a key term differently, revise the term or specify its scope. If they understand the question but cannot obtain the information, shorter wording will not solve the problem. Consider asking later, inviting the appropriate person to supply it or accepting uncertainty where the decision allows it.

If they know their answer but cannot express it through the available choices, inspect the response format. A request may cover two services, or the deadline may still be undecided. Adding an “Other” choice can make submission possible while leaving the team without information it needs. Decide whether the missing distinction requires a clearer choice, a separate question or a short explanation.

If the answer combines two judgments, separate them when each changes the next action. “Are the content and branding ready?” cannot distinguish missing copy from an unfinished identity. If participants worry about the consequences of answering, examine the explanation of how the answer will be used as well as the question itself.

Keep interface obstacles distinct from interpretation problems. Difficulty reaching a control or noticing an instruction calls for usability and accessibility investigation. Rewording a label may help recognition, but it cannot establish that the control works with the person’s device or assistive technology.

Keep evidence that makes the repair checkable

For each finding, retain the exact question version, relevant context, initial answer, the participant’s explanation and any help given. Add your interpretation and proposed change in separate notes. Use brief, de-identified excerpts only where they are needed to explain the issue; restrict access to the underlying material.

Write a finding such as “The participant used the announcement date; the question needs the website availability date.” That supports a particular repair. “People do not understand deadlines” goes beyond the evidence and makes it harder to choose a useful change.

Look for differences as well as repetition. A term that works for experienced buyers but fails for first-time buyers may require plainer wording for the whole intake. One credible misunderstanding can warrant a low-cost correction when the answer has serious consequences. It still does not establish a population failure rate.

Do not turn interview counts into a conversion forecast. These sessions can reveal plausible mechanisms behind bad answers. They do not show that a wording change will increase bookings or tell you the share of all visitors who would misunderstand.

Retest the repair and the decision it supports

Keep the revised question in its actual sequence and include relevant answer choices and instructions. Ask fresh participants to answer without your explanation. Returning participants can help compare wording, but familiarity with the intended meaning can conceal a problem that remains for newcomers.

Check whether people now describe the needed concept, can obtain or honestly qualify the information and can express their answer. Then have the receiving team interpret a set of test answers. Clear wording has limited value if the team still treats every target date as a confirmed deadline.

If the revision fixes one case but breaks another, refine the distinction rather than declaring success from the average reaction. Preserve unresolved questions and decide whether a human follow-up is necessary before acting on the answer. The Census Bureau describes a cycle of diagnosing problems, revising wording and testing again; a successful submission alone is not that cycle.

Put the findings into a focused intake flow

In QuizFlow Labs, a Text Response block lets participants explain context in their own words. It can suit a question such as what an event deadline depends on. When the next step needs a clear choice, ask that choice explicitly rather than expecting a paragraph to function as a selected answer.

Test the final question in the experience people will use, including on a phone. Keep comprehension testing alongside checks of controls, validation and the eventual next step. Each addresses a different way that an apparently complete intake can fail.

Start with one question whose answer changes a real decision. Define the information needed, observe how people answer, repair the specific mismatch and retest. The goal is an answer both the client and the receiving team understand well enough to use.