# Small Proof Studio — full text

> Small Proof Studio is an independent educational publication about customer discovery, low-cost prototypes, startup experiments, and evidence before expensive build decisions. It is not an incubator, accelerator, investor, coworking space, consultancy, manufacturer, grant program, school, or continuation of any former entity associated with this domain.

# How to Analyze Customer Interviews Without Overclaiming

> Analyze customer interviews by extracting specific observations, linking each one to its source, grouping related experiences and separating what participants said from your interpretation. Keep counterexamples and missing information visible. Then write a limited finding and choose the next decision or test it supports. A small interview round can improve a product decision; it cannot, by itself, establish market demand or a reliable market percentage.

Source: https://sparkholyoke.com/analyze-customer-interviews/  
Publisher: Small Proof Studio  
Published: 2026-09-07  
Updated: 2026-09-07

## How do you turn customer interviews into useful evidence?

Analyze customer interviews by extracting specific observations, linking each one to its source, grouping related experiences and separating what participants said from your interpretation. Keep counterexamples and missing information visible. Then write a limited finding and choose the next decision or test it supports. A small interview round can improve a product decision; it cannot, by itself, establish market demand or a reliable market percentage.

The goal is not a wall full of matching notes. It is an explanation another team member can inspect: here is what we heard, here is why we think it matters, and here is what remains uncertain.

This guide starts after the conversations. Use our [non-leading customer interview guide](/customer-interview-without-leading/) when you need help collecting better material first.

## What should you have ready before analysis?

Gather the research question, recruitment criteria, session notes and any recordings you are authorized to use. Keep the original question visible. Otherwise, an interesting side issue can quietly replace the decision the interviews were meant to inform.

Check the consent and data-handling plan before moving material into a shared workspace. The [GOV.UK Service Manual's consent guidance](https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research) emphasizes explaining the research purpose, collection, use, sharing and retention to participants. Its legal context is UK government research; obtain appropriate data-protection or legal advice for your own setting.

Use an approved workspace with restricted access. Remove unnecessary identifying details from analysis copies. A participant code is useful for organization but does not guarantee anonymity if the remaining story identifies the person or business.

Do not upload transcripts to an external summarizer merely because it is convenient. Confirm that the tool, access arrangements and processing are permitted by your research and privacy plan.

## How do you separate an observation from an interpretation?

Write one relevant observation per entry. Preserve enough context to understand it, and link back to the session or authorized source location.

The [GOV.UK analysis guide](https://www.gov.uk/service-manual/user-research/analyse-a-research-session) separates observations, findings and actions. It recommends recording what was seen or heard before deciding what it means.

For interview-only evidence, use “reported” or “described.” A participant recounting a process is not the same as a researcher watching that process happen.

Here is a fictional example:

- Reported experience: participant P01 described copying attendance totals from a booking export into two spreadsheets.
- Interpretation: maintaining separate reports may create repeated administrative work.
- Product idea: combine reports in a new dashboard.

Only the first statement belongs in the raw evidence field. The interpretation is a possible explanation. The dashboard is one proposed response, not something the interview proved necessary.

Use quotation marks only for words checked against an accurate source. If your note captures the meaning rather than the wording, label it a paraphrase. Do not improve a participant's sentence until it sounds like an endorsement.

## What goes in a customer-interview evidence table?

The following is Small Proof Studio's practical worksheet, not an official research standard. Use a document or spreadsheet you already have.

| Field | What to enter |
| --- | --- |
| Evidence ID | A unique label, such as E01 |
| Participant and session | A research code, not unnecessary contact details |
| Source location | Note section or authorized recording timestamp |
| Situation | The task, trigger and relevant context |
| Report or observation | A specific account or behavior, labeled accurately |
| Working interpretation | What it might mean, kept separate |
| Open question | What is missing or could change the interpretation |

Add more than one row for a participant when they describe different events. Keep the participant code on every row so repeated remarks do not become imaginary additional customers.

For example, E01 and E02 might both come from P01. They are two pieces of material from one person. If another observer wrote down the same episode, merge or cross-reference the duplicate instead of counting it as another occurrence.

The [GOV.UK note-taking guidance](https://www.gov.uk/service-manual/user-research/taking-notes-and-recording-user-research-sessions) likewise recommends single-point notes labeled with the participant and session. It also calls for reviewing material to remove personal or confidential information.

## How do you group notes without forcing agreement?

Begin with related tasks or situations, not proposed features. “Preparing an attendance report” is a useful starting group. “Needs our dashboard” has already decided the answer.

Read each entry in its original context when a grouping is uncertain. Split a broad group when it combines different jobs: correcting a count is not necessarily the same problem as formatting a report for another team.

Keep a separate space for contradictions and unanswered questions. Our editorial approach is to retain potentially important exceptions until someone has explained their relevance, rather than discarding them because they sit alone.

A note can challenge the main explanation without making the research useless. Someone whose existing tool handles the task well may reveal a configuration, working practice or participant difference worth understanding.

If team members disagree, write both interpretations and the evidence each uses. Voting for the more appealing story does not resolve the underlying uncertainty.

## What does a worked analysis look like?

Consider a fictional startup exploring attendance-reporting work for community workshop coordinators. Its question is whether manual copying between reports deserves a closer workflow study.

The six fictional interview summaries below are invented solely to demonstrate analysis. They are not actual customer research, quotations or evidence of demand.

| Participant | Fictional account | How to classify it for this question |
| --- | --- | --- |
| P01 | Describes copying totals into two spreadsheets after a recent event | Specific manual-copying account |
| P02 | Describes manually adding attendance counts to a separate summary | Specific manual-copying account |
| P03 | Says an existing report already supplies the needed totals | Counterexample to a universal problem |
| P04 | Describes copying counts between a booking export and a report | Specific manual-copying account |
| P05 | Explains that another organization handles attendance reporting | Outside the task-owning group |
| P06 | Calls reporting annoying but cannot describe a particular occasion | Insufficient detail about the proposed problem |

Three accounts describe manual copying. One describes an existing solution. One participant does not own the task. One account lacks enough detail. Three plus one plus one plus one equals six.

Do not rewrite this as “customers need a new reporting product.” No one has demonstrated the proposed product, compared an actual offer or made a purchase decision.

A defensible fictional finding is narrower: “Three participants described manual transfer of attendance counts; a fourth described a working existing report. We need to understand what differs between those workflows.”

## Why not turn the counts into market percentages?

The table accounts for the interviews conducted. It does not establish how common the problem is in a wider population.

Recruitment matters. Six people introduced by one contact may share a tool, working arrangement or professional circle. The example does not contain a sampling design that supports a market estimate. Keep the count tied to the round and name how participants were found.

Missing evidence also needs its own label. P06's general complaint is not proof of manual copying, but it is not proof that copying never occurs. P05 may know the sector while being the wrong person to describe this particular task.

Avoid silently deleting those two rows and presenting the remaining accounts as if every interview was equally relevant from the start. Explain the inclusion rule and retain the full research-round record.

Likewise, multiple people from one organization do not automatically establish independent accounts of different organizations' workflows. Record that relationship without sharing confidential identifiers unnecessarily.

## How do you turn a finding into a next decision?

Use the finding to narrow the next question, not to authorize the whole product build.

[Strategyzer's Learning Card explanation](https://www.strategyzer.com/library/capture-customer-insights-and-actions-with-the-learning-card) connects the tested hypothesis, evidence, interpretation and resulting action. You do not need to copy its card design to use the underlying discipline of making those links explicit.

For the fictional attendance example, a useful decision note would say:

- Decision now: study how the reported copying happens before building a dashboard.
- Reason: the interview accounts identify a possible repeated task but not its exact cause.
- Counterevidence: P03 already has a report that meets the need.
- Next question: does the difference come from available reporting, setup, required outputs or another constraint?
- Evidence needed: an authorized walkthrough using non-sensitive or properly approved material.
- What could change the direction: the existing reporting function solves the issue after a simple configuration change.

If the next uncertainty is whether someone understands a proposed sequence, a [paper prototype](/build-paper-prototype-test/) can support a different test. Do not present a successful interface walkthrough as proof that someone will purchase or adopt the service.

Choose one limited decision. “Investigate this workflow” is complete enough; “validated the startup” is not.

## What should you share with the team?

Share a short finding summary with links to permitted supporting material, rather than handing everyone raw recordings by default.

The [GOV.UK guidance on sharing findings](https://www.gov.uk/service-manual/user-research/sharing-user-research-findings) recommends explaining the essential facts, their importance and the next work. Adapt the format to the people making the decision.

A compact summary can contain:

- the question and who participated;
- the specific finding;
- supporting evidence IDs;
- counterexamples and limitations;
- the decision, owner and next review point.

Keep the fictional example label if you reuse this article's worksheet for a practice exercise. Do not let sample content enter a real report as if it came from interviews.

Before sharing, check whether quotes, business details or screenshots are allowed for that audience. Participation in a research conversation is not a blanket endorsement or permission for public marketing.

## How do you know the analysis is finished for now?

Ask another team member to trace the main finding back to its evidence. Can they tell which parts were reported, observed or inferred? Can they find the exception? Can they explain why the next action follows?

If the answer is no, repair the reasoning before adding more formatting. If the answer is yes, assign the next action and preserve the unresolved questions for the next round.

A useful analysis can conclude that more research is needed, that the question should change or that building should pause. The work earns its place by improving the decision, not by making every interview sound encouraging.

## Sources

- [GOV.UK: getting informed consent for user research](https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research)
- [GOV.UK: analyzing a research session](https://www.gov.uk/service-manual/user-research/analyse-a-research-session)
- [GOV.UK: taking notes and recording research](https://www.gov.uk/service-manual/user-research/taking-notes-and-recording-user-research-sessions)
- [Strategyzer: connecting observations, insights and actions](https://www.strategyzer.com/library/capture-customer-insights-and-actions-with-the-learning-card)
- [GOV.UK: sharing research findings](https://www.gov.uk/service-manual/user-research/sharing-user-research-findings)

## Frequently asked questions

**What is the difference between an observation and an insight?**

An observation records something seen or heard, with enough context to inspect its source. In an interview, a described event is reported experience, not direct observation of the event itself. An insight interprets that material. Keep the interpretation in a separate field so readers can assess whether the evidence supports it.

**Can I report percentages from a few customer interviews?**

Do not present counts from a small convenience sample as reliable market percentages. State the number of participants who described the relevant experience, how they were recruited and what evidence was missing. The fictional six-interview example is a record-accounting exercise, not a population estimate or evidence of product demand.

**How should I handle a customer who contradicts the others?**

Retain the account and examine what differs: the participant's role, tools, task, constraints or context. A working existing solution may explain why another participant struggles. Do not discard the contradiction simply because it weakens a preferred product idea. Record what further evidence would help distinguish the possible explanations.

**Do I need a complete interview transcript?**

Not necessarily. You need sufficiently accurate, source-linked material for the decision and permission to use it. Clear notes may support a limited finding, while an authorized recording can help check exact wording. If the wording cannot be verified, label it a paraphrase rather than presenting it as a direct quotation.

**What should I do after grouping interview themes?**

Write a limited finding that names the supporting accounts, counterexamples and gaps. Then choose the next decision or evidence-gathering step, assign an owner and state what could change the direction. A theme alone does not justify a feature. In the fictional example, a workflow investigation comes before building a dashboard.


---

# Build and Test a Paper Prototype

> Build a paper prototype around one task and learning question. Draw only the screens and states needed, using movable cards for menus, dialogs, errors, and confirmations. One facilitator gives the scenario while another person acts as the system, changing paper after each action. Use fictional data, readable labels, and safe cutting and adhesive practices. Record choices, hesitation, errors, workarounds, and completion without teaching. Separate observation from interpretation, revise one variable, and test again. Move to interactive tools when timing, input, accessibility, or system behavior becomes the question.

Source: https://sparkholyoke.com/build-paper-prototype-test/  
Publisher: Small Proof Studio  
Published: 2026-07-19  
Updated: 2026-08-26

## Build only enough interface to test one risky flow

Build a paper prototype by choosing one task, drawing the minimum screens or states needed to complete it, and preparing movable controls, overlays, and a test script. One facilitator acts as the system, swapping paper when the participant points or “clicks.” Observe without teaching, then revise the paper rather than defending it.

Paper is especially useful before visual polish or code makes a weak flow expensive to question. It cannot test load time, real accessibility behavior, device input, data integrity, or technical feasibility. A rectangle drawn around the word “magic” remains admirably low fidelity.

## Choose the test question and stopping point

Write one scenario and one learning question. For example: Can a first-time user find the correct order and change its delivery address? Define success as observable behavior, not “likes the concept.”

Limit the path to the starting state, key decisions, error or empty state where relevant, and completion. Do not draw the full product. Use neutral fictional data that resembles the real structure without exposing personal, client, regulated, or confidential information.

Recruit participants with relevant experience and explain the purpose, time, note-taking, recording, privacy, compensation, and right to stop. A paper interface may be informal; research consent should not be.

Browse [prototype workshop](/prototype-workshop/) for more small-proof formats.

## Use simple, safe materials

Useful materials include plain paper or index cards, removable notes, markers with readable contrast, transparent sleeves, tape, reusable adhesive, and a backing board. Create separate pieces for menus, dialog boxes, keyboards, notifications, and error messages so the “system” can respond.

Use scissors or craft knives only on a stable protected surface, away from the participant area, and according to tool instructions. Cut away from hands and bodies, store blades securely, and provide age-appropriate supervision. Use adhesives and markers with ventilation and surface protection as their labels require.

Rounded corners are optional. Keeping blood off the onboarding flow is not.

## Make every state legible

Write large enough for the participant and observer to read. Use consistent control names and obvious state changes. Include a back path, cancel path, loading or confirmation state where it affects the task, and an error response instead of allowing every action to succeed.

Do not make the prototype prettier than the question requires. Visual branding can bias a participant's reaction and consume revision time. Add accessibility considerations early—clear language, contrast, focus order concept, labels, and alternatives—but recognize that paper cannot verify screen-reader, keyboard, touch-target, motion, or device behavior.

Number each screen on the back so notes can identify it without revealing labels to the participant.

## Rehearse the human computer

One person facilitates; another can move the paper as the system. Practise the expected path and at least one unexpected action. Decide how the “computer” responds when a control is missing: usually with no change or a neutral request for the participant to show what they expect.

Do not explain where to tap. Ask the participant to think aloud only if that suits the method and does not overburden them. When they hesitate, wait. The paper interface is currently learning to take responsibility for its own labels.

Visit [customer discovery](/customer-discovery/) for neutral prompts and consent.

## Run the task without selling

Give the scenario, not step-by-step instructions. Ask the participant to indicate actions physically or verbally, then swap states promptly. Record first choice, navigation path, hesitation, errors, questions, workaround, completion, and comments.

Avoid praise that reveals the intended answer. Thank the participant without calling a particular action correct. After the task, ask what they expected, what felt unclear, and what they would do next.

Use our [non-leading interview guide](/customer-interview-without-leading/) for the debrief.

## Revise one variable and test again

Separate observation from interpretation. “Pointed to the heading three times” is observable; “did not understand navigation” is a hypothesis. Change the label, position, grouping, sequence, or state most directly connected to the behavior.

Save a photograph or version note before revising, with appropriate consent and no unnecessary participant information. Test the changed flow with another relevant participant rather than explaining it to the first until it sounds clear.

Move to an interactive prototype when the question depends on timing, input, focus, responsive layout, accessibility technology, or realistic system behavior. Move to code when technical feasibility or integration becomes the main risk.

The paper prototype is finished when it has answered the decision question, not when every future screen has been drawn. Recycle or securely dispose of sheets according to their contents. Cheap evidence has done its job; the markers may now return to arguing about who left a cap off.

## Frequently asked questions

**What can a paper prototype test?**

It can test a user's interpretation of labels, grouping, sequence, navigation, task flow, expected states, and basic error handling before code exists. It is less suitable for performance, real data behavior, responsive layout, device input, animation, precise visual design, or assistive-technology interaction. State the learning question first and use paper only when a human-operated low-fidelity flow can produce evidence relevant to that decision.

**What materials do I need for paper prototyping?**

Plain paper or index cards, removable notes, readable markers, tape or reusable adhesive, transparent sleeves, and a backing board can be enough. Make separate pieces for menus, dialogs, keyboards, and messages. Use cutting tools on a protected stable surface according to instructions, store blades securely, and use adhesives and markers with suitable ventilation and surface protection. Materials should make revision easy, not make the prototype look finished.

**How does a paper prototype user test work?**

Give a participant one realistic scenario without step-by-step directions. Ask them to point or say what they would do. A human acting as the system swaps screens and components in response. Observe the path, pauses, errors, expectations, and completion. Avoid teaching or praising the intended action. Afterward, ask what they expected and what was unclear, then separate observations from interpretations before changing the design.

**Should a paper prototype look polished?**

Only enough to be readable and support the question. Heavy branding and detailed visual design can consume time, discourage revision, and influence reactions unrelated to the flow. Use consistent control names, clear contrast, and legible states. Include back, cancel, error, and confirmation behavior where relevant. Move to a higher-fidelity prototype when typography, responsive layout, motion, timing, or realistic interaction is the risk you need to test.

**When should I stop paper prototyping?**

Stop when the prototype has answered the current decision question or when the remaining uncertainty depends on behavior paper cannot represent. Move to an interactive prototype for timing, input, focus, responsive layout, and accessibility technology; move to code for technical feasibility, integration, or real performance. Preserve version notes and unresolved findings. Do not draw the entire imagined product merely because the paper and markers are already on the table.


---

# Run a Customer Interview Without Leading

> Run a non-leading customer interview by defining one decision, recruiting people with recent relevant experience, and asking them to reconstruct a specific event. Use neutral prompts about triggers, actions, tools, alternatives, constraints, consequences, and what happened next. Avoid describing your solution, assuming the problem, or asking whether they would buy an imagined product. Obtain appropriate consent, protect private information, and separate observations from interpretation after the call. Compare repeated behaviors and counterexamples without turning a small sample into market percentages, then choose the next test or change in direction.

Source: https://sparkholyoke.com/customer-interview-without-leading/  
Publisher: Small Proof Studio  
Published: 2026-07-19  
Updated: 2026-08-26

## Ask for a recent story before offering a solution

Run a customer interview without leading by choosing one learning question, asking about a specific recent event, and following the person's actions, alternatives, constraints, and decisions in their own words. Keep your idea and preferred answer out of the question. End by summarizing what you heard and checking your understanding, not by asking whether they like the startup.

An interview is evidence about this participant's experience. It is not a representative survey, a product order, or proof of a market. Five enthusiastic compliments remain compliments, even when entered into a spreadsheet wearing currency formatting.

## Define the decision the interview should inform

Write the risky assumption and the decision attached to it right now. For example: Do people currently spend meaningful effort reconciling these records, and should we test a simpler workflow? Avoid goals such as “validate the product,” which quietly asks the conversation to return one approved conclusion.

Choose participants who have encountered the situation, not only friends who understand why the idea sounds exciting. Define relevant experience without targeting or excluding people unlawfully or unethically.

Explain who you are, the purpose, expected length, note or recording method, privacy, compensation if any, and how the person can decline or stop. Obtain appropriate consent. Do not collect sensitive personal, health, financial, employment, or confidential business information without a justified, approved plan.

Browse [customer discovery](/customer-discovery/) for more evidence-led research setup.

## Build a neutral question path

Start broad: “Tell me about the last time you had to….” Then ask:

- What triggered it?
- What did you do first?
- What happened next?
- What tools or people were involved?
- Where did you pause, repeat, or change direction?
- What did the outcome cost in time, money, risk, or effort?
- What have you tried before?

Ask “how” and “what” more often than “would.” Future intentions are easy to state and hard to interpret. A recent event gives the participant something concrete to reconstruct.

Avoid loading the problem into the question: “How frustrating is the slow process?” assumes it is slow and frustrating. Ask “How would you describe the process?” and follow the language they choose.

## Follow evidence without conducting a cross-examination

When a statement is abstract, request an example: “Can you walk me through the last instance?” Ask what the person actually used, paid, delayed, abandoned, or asked someone else to do.

Use short neutral prompts—“What happened then?” or “Tell me more”—and allow silence. Do not rescue every pause with a miniature sales pitch. The participant is thinking, not buffering.

When the story contradicts your assumption, explore it with the same curiosity. Do not debate, teach the person the correct problem, or keep reformulating until they agree.

## Keep the concept test separate

If you show an idea, label the transition. Present the smallest neutral description or prototype needed for the next question, then ask the participant to interpret or use it without a feature tour.

Observe what they expect, where they hesitate, and what they do. “Would you use this?” invites politeness and imagination. A task with a prototype reveals whether the proposed flow makes sense under test conditions.

Use our [paper-prototype guide](/build-paper-prototype-test/) for a low-cost concept session, and visit [prototype workshop](/prototype-workshop/) for materials and test boundaries.

## Debrief facts before themes

Immediately after, separate **observed or said**, **interpretation**, and **decision**. Preserve short exact phrases only with consent and appropriate handling. Remove unnecessary identifying detail.

Compare interviews for repeated behaviors, constraints, alternatives, and consequences, but retain counterexamples. Do not convert frequency in a small convenience sample into a market percentage.

Write what would change your mind and choose the next test. That may be another participant segment, a workflow observation, a pricing experiment conducted ethically, or a decision to stop.

The interview has succeeded when it makes the next decision better, including the inconvenient decision that the problem is smaller, different, or already well served. Discovery is not a courtroom where the idea wins; it is a workshop where the expensive mistake is invited to identify itself early.

## Frequently asked questions

**What is a good first customer interview question?**

Ask for a recent specific story: “Tell me about the last time you had to…” followed by the situation you are studying in neutral terms. Then ask what triggered it, what happened first, and what happened next. This grounds the conversation in behavior rather than broad opinion or future intention. Avoid naming your solution or describing the experience as difficult, slow, expensive, or frustrating before the participant does.

**What makes a customer interview question leading?**

A leading question contains or rewards the preferred answer, assumes a problem, praises the concept, or offers only favorable choices. “How frustrating is this process?” assumes frustration; “Would this convenient feature help?” advertises the response. Ask the participant to describe the process, recent event, alternatives, and consequences in their own language. Neutral follow-ups such as “Can you give an example?” reveal more than a reformulated sales claim.

**Should I pitch my startup during a customer interview?**

Keep problem discovery separate from a concept test. Learn the participant's current behavior before showing the idea. If a concept must be tested, announce the transition, present only enough neutral material for the task, and observe use without a feature tour. Pitching early teaches the participant your vocabulary and invites politeness. It also makes later agreement difficult to distinguish from genuine experience or simple kindness toward an enthusiastic founder.

**How many customer interviews are enough?**

There is no universal number that guarantees a conclusion. Sample relevance, decision risk, segment variation, interview quality, and the cost of being wrong all matter. Continue until the evidence is sufficient for the next limited decision and important counterexamples are understood, then test behavior through another method. Do not report small convenience-sample frequencies as market percentages or imply statistical representation the research design does not provide.

**How should I take notes in a customer interview?**

With consent, record brief exact phrases, event sequence, actions, alternatives, constraints, and consequences. Mark direct statements separately from your interpretation and remove unnecessary identifying detail. If recording audio or video, explain storage, access, use, retention, and the right to decline under applicable rules. Debrief immediately into observed or said, interpretation, open question, and next decision. A thematic summary should preserve counterexamples rather than sanding every interview into agreement.


---

# How to Recruit Customer-Interview Participants

> Recruit people whose recent experience matches the question you need to answer. Define that experience, choose a suitable recruitment channel, screen briefly and explain the session before booking it. Make participation voluntary, obtain informed consent and collect only necessary information. Plan accessible participation and disclose any incentive. A full calendar is not evidence of market demand; the point is to hear from relevant people, including those who may contradict your assumptions.

Source: https://sparkholyoke.com/recruit-customer-interview-participants/  
Publisher: Small Proof Studio  
Published: 2026-09-15  
Updated: 2026-09-15

## How do you recruit useful customer-interview participants?

Recruit people whose recent experience matches the question you need to answer. Define that experience, choose a suitable recruitment channel, screen briefly and explain the session before booking it. Make participation voluntary, obtain informed consent and collect only necessary information. Plan accessible participation and disclose any incentive. A full calendar is not evidence of market demand; the point is to hear from relevant people, including those who may contradict your assumptions.

This guide covers routine customer discovery with adults. It adapts UK government research guidance into a practical startup workflow; it is not a legal compliance template. Have privacy and consent arrangements reviewed for your jurisdiction, and obtain specialist safeguarding advice before research involving children or vulnerable participants.

## What experience should qualify someone?

Start with the decision, then describe the experience needed to discuss it. “People who love productivity tools” selects enthusiasm. “People who personally scheduled customer appointments recently” selects a task.

The [GOV.UK recruitment-brief guide](https://www.gov.uk/service-manual/user-research/write-a-recruitment-brief) recommends recording participant criteria, session dates and length, location, numbers and incentives. It also says to review an agency's screening script against your actual requirements. Use a written brief even when a colleague handles recruitment.

For a fictional appointment-reminder study, our proposed criterion is an adult who personally arranged appointments during the past month. The month is an illustrative choice for this example, not a research standard. Include people whose existing arrangements work well; requiring dissatisfaction would preselect the conclusion.

## What should a short screener ask?

A screener checks whether someone fits the research question before scheduling the interview. It should not become the interview itself. These original example questions are for the fictional appointment study, not a validated questionnaire:

| Question | What the answer helps establish |
| --- | --- |
| During the past month, which appointment-related tasks have you personally handled? | Relevant recent activity; allow “none” |
| Which parts did you handle yourself, and which did someone else handle? | The participant's role |
| What did you use to arrange them? | Existing process, including paper or another person |
| Would you be willing to discuss that process without sharing customer details? | Whether the proposed conversation is suitable |
| What contact method and session arrangements work for you? | Practical participation needs |

Do not ask applicants to upload calendars, client lists or account screenshots to prove eligibility. Record an unclear answer as needing clarification rather than silently treating it as a match. Keep scheduling details out of the interview evidence table.

## Where should you look for participants?

The [GOV.UK participant-finding guide](https://www.gov.uk/service-manual/user-research/find-user-research-participants) describes recruitment agencies, relevant organisations and existing users as possible routes. It calls for permission before inviting existing users into specific research activities.

For this example, start with an appropriate business network willing to circulate an invitation, or customers who have agreed to hear about research. A specialist recruiter is another option when your criteria are difficult to reach. Ask how the recruiter will apply them.

Have a community moderator approve a post before using their space. Invite people to respond privately through an approved channel. Do not scrape a member list or treat access to a customer database as blanket permission to contact everyone.

## What should the invitation make clear?

Say who is conducting the research, the task being studied, the session format and expected duration. Describe any incentive and provide a way to ask questions or decline. Avoid recruitment copy that sells the proposed solution before someone has described their experience.

The [GOV.UK consent guide](https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research) recommends an information sheet during recruitment. Explain data collection, observers, recording, use, sharing, retention and withdrawal in a format participants can understand. Keep evidence of what they agreed to. An expression of interest is not consent to record an interview or publish a testimonial.

Before the conversation, confirm continued agreement. Stop if consent is withdrawn and follow the reviewed withdrawal and data-handling procedure. Use our [non-leading interview guide](/customer-interview-without-leading/) for the session itself.

## How do you avoid excluding people through the arrangements?

Ask about preferred communication, usable materials and participation support before fixing the format. The participant-finding guide specifically addresses accessible contact methods, communication support and usable consent materials. Offer arrangements appropriate to the person's needs rather than assuming everyone can use a video call.

Do not turn a support request into an unnecessary medical-history questionnaire. If you cannot provide an agreed arrangement, resolve that before confirming the booking. A calendar invitation does not solve an access problem.

## What should you decide about incentives?

An incentive needs an ethical plan as well as a budget. The [Department for Education's guidance](https://user-research.education.gov.uk/guidance/incentives-26/3) identifies risks including pressure to participate and digital incentives that some people cannot access. Its payment rules are departmental, not universal startup rules.

Our recommendation is to state the amount, form, eligibility and delivery arrangements before booking, after appropriate review. Do not make payment depend on praise, purchase or the answers you hoped to hear. Seek qualified research advice if the proposed incentive could compromise voluntary participation.

## How should you manage the recruitment list?

Use a restricted scheduling record with contact details, eligibility status, agreed arrangements and session status. Avoid a shared calendar that exposes other participants' identities. Give the interviewer only the information needed for the agreed session.

The [GOV.UK privacy guide](https://www.gov.uk/service-manual/user-research/managing-user-research-data-participant-privacy) recommends minimum necessary recruitment information, secure storage, limited access and deletion when details are no longer needed. Follow a reviewed retention plan rather than keeping every unsuccessful applicant indefinitely. Check third-party recruiter and scheduling-tool arrangements with your privacy adviser.

For research notes, use participant codes and appropriate access controls; a code alone does not make a person's story anonymous. Our [interview-analysis guide](/analyze-customer-interviews/) explains how to separate evidence from interpretation after the sessions.

## What if the first invitation gets few responses?

Keep a simple record of the channel, invitation wording, replies, relevant volunteers and completed sessions. These are operational counts, not a market estimate. Before relaxing the criteria, check whether the message reached the intended people and whether the session arrangements were workable.

Change one part of the recruitment plan deliberately and note why. Do not redefine the target participant merely to fill the calendar. A useful round can be smaller than planned if its limitations are visible; an irrelevant round does not become stronger because every slot is occupied.

## Sources

- [GOV.UK: Write a recruitment brief](https://www.gov.uk/service-manual/user-research/write-a-recruitment-brief)
- [GOV.UK: Finding research participants](https://www.gov.uk/service-manual/user-research/find-user-research-participants)
- [GOV.UK: Getting informed consent](https://www.gov.uk/service-manual/user-research/getting-users-consent-for-research)
- [Department for Education: Incentive decisions and risks](https://user-research.education.gov.uk/guidance/incentives-26/3)
- [GOV.UK: Research data and participant privacy](https://www.gov.uk/service-manual/user-research/managing-user-research-data-participant-privacy)

## Frequently asked questions

**How many customer-interview participants should I recruit?**

Set the round size around the question, the relevant participant differences and the time available to conduct and analyse the sessions. Do not treat one fixed number as proof of market demand. Record who you reached, who is missing and what further research the findings would need.

**Can I use friends to practise the interview?**

Friends can help you rehearse the invitation, timing or wording, but keep a practice session labelled as practice. For the research round, check that each participant has the experience your question requires. Do not present familiar people's encouragement as independent evidence that customers want the proposed product.

**Should the recruitment screener contain the whole interview?**

Keep the screener focused on the criteria and arrangements needed to decide whether to schedule someone. Save the detailed conversation for the session. Review each question against the recruitment brief, and remove questions that do not inform eligibility or participation rather than collecting extra material just because the form allows it.

**How much should I offer as an incentive?**

There is no amount prescribed by this guide. Review the proposed payment against the research effort, participation costs and ethical risks, including whether its form is usable. State the agreed terms before booking. Ask a qualified research lead for advice where an incentive could create pressure or undermine voluntary participation.

**What should I do when someone does not fit the criteria?**

Thank them without pressuring them to give a different answer. Keep any necessary status note under the approved data-handling plan. If many volunteers do not fit, review the recruitment channel and invitation before changing the criteria; the purpose is to reach relevant people, not simply occupy available appointment slots.


---