research_participant_screening v1.0.0

---

name: research_participant_screening description: "Recruit the right participants for a research study: turn a persona or segment brief into screener questions with qualifying logic that hides which answer qualifies, handle consent and sensitive questions, set quotas, run panel hygiene and fraud checks, and pass a pre-launch review that catches guessable or leaky screeners. Use when writing or reviewing a screener, defining inclusion and exclusion criteria, building quotas for a mixed panel, porting a screener between tools, or checking why a study recruited the wrong people."

---

Research Participant Screening

Purpose

Turn a brief about who a study needs into a screener that finds those people, keeps out people who cannot answer the research question, and does not teach respondents how to qualify.

The skill is platform free. It works for a survey tool, a form, a spreadsheet plus phone script, a panel provider brief, or a recruiter script. It ships a screener template with researcher side logic, a quota tracker, two small checkers, and a worked screener for a mixed panel.

It does not run the study, write the discussion guide, or replace an ethics review. When a study sits under an IRB, a university policy, a health privacy rule, or a client compliance rule, that rule governs and this skill supplies the screener craft underneath it.

Workflow

1. Turn the brief into a criteria table first

Do not write questions yet. Write the criteria table in assets/screener_template.md, one row per criterion.

For each criterion record:

• The trait, in plain words, and the research question it serves. If no research question needs it, cut it.
• Type: must have, must not have, quota only, or nice to have. Quota only means the answer balances the final sample and never disqualifies anyone on its own.
• Evidence: what past behaviour or verifiable fact shows the trait. Prefer behaviour over a label. Product manager is a label. Analyses usage data at least weekly in the past month is behaviour.
• Source: panel profile, screener answer, document the person can show, or re-screen at the session. Name one.
• Failure mode: what goes wrong in the session if this row is wrong.

Rules for the table:

• Keep must haves short. Nielsen Norman Group and User Interviews both warn that overscreening produces a pool nobody can pass. Every extra must have needs a sentence saying why the study fails without it. Two to four must haves is a useful prompt to argue about, not a cap to obey.
• Screen for behaviour and psychographics before demographics. Add age, income, gender, location, or job title only when the research question, the method, or safety needs it. Location for an in person study is a real reason. Habit is not.
• Write who cannot answer the question, not only who can. Exclusions often do more work than inclusions. Common exclusions to consider, each still needing a reason: people who work on the product or for a direct competitor, people whose job is evaluating interfaces or research itself when the study needs naive users, and people who took part in a closely related study recently enough that they will repeat what they learned there. Set that gap per study and write it in the table as a team choice.
• Split combined criteria. Small business owner who uses cloud accounting is two rows, owner status and tool use. A disagreement or a bad recruit should point at one row.

2. Classify each criterion by how it will be checked

Assign one check type per row. The check type decides the question shape.

• Gate: a fact that ends the screener when it fails, such as country, device needed for the test, or a legal age requirement.
• Hidden qualifier: the core trait the study is about, such as using a named product, doing a task, or holding a view. Write these so the qualifying answer is buried, see step 3.
• Verification: a second question that makes the first answer hard to fake, such as naming which items a business holds, where the target item is must select in a longer list.
• Articulation: an open ended question that shows whether the person can explain what they do. Use it to judge communication fit and to spot thin, copied, or inconsistent answers.
• Quota: an answer used only to fill cells in step 6, such as channel used, household size, or experience level.
• Sensitive: a question about health, money, identity, belief, or similar ground. Route it through step 5 before writing it.

3. Write questions that hide which answer qualifies

Keep two copies from the start: a participant facing copy with no logic marks, and a researcher copy with the logic in brackets after each option. Never send the researcher copy to a panel or paste it into a tool as visible text.

Logic vocabulary, usable in any tool:

• [must select] the person has to pick this option to stay in.
• [may select] picking it neither helps nor hurts.
• [reject] picking it ends the screener, alone or in combination as noted.
• [quota: cell name] the answer assigns a quota cell.
• [verify: Qn] this answer must agree with the named question.

Patterns that work:

• Replace a lone yes or no question with a two question series. First ask frequency or recency in bands, with the zero band as [reject]. Then ask a select all list that includes the target among plausible alternatives, with the target as [must select] and none of the above as [reject]. Nielsen Norman Group gives this exact shape for shopping sites, and Kantar gives the same shape for places visited followed by frequency.
• Bury the target in a list of real alternatives at the same level of detail. Five to eight options is easy to scan. Do not make the target the longest, the first, the only specific one, or the only positive one.
• Ask about past behaviour in a stated window, not about intent. Write in the past 7 days, in the past 30 days, or in the past 12 months, and pick the window the criterion needs. Cut vague words such as often, regularly, and usually from both questions and options.
• Use mutually exclusive ranges with no overlap and no gap: 0, 1 to 3, 4 to 7, 8 or more. Overlapping bands such as 0 to 3 and 3 to 7 make the data unusable.
• Give every closed question a way out: none of the above, not applicable, I do not know, or other with a text box where other is plausible. Without a way out, people pick a false qualifying answer because nothing else fits.
• Ask one thing per question. Split double questions. Avoid double negatives, jargon, and brand language the participant would not use, unless knowing that term is itself the criterion.
• Add one or two open ended questions, placed after the hidden qualifiers. Ask for a recent concrete episode: the last time they did the task, what they used, and what happened. Score the answer for specificity and for agreement with the closed answers, not for polish or spelling.
• Keep the study description at the screener head general and true. A study on how people plan weekly food shopping is general. Naming the client app feature under test is specific enough to prime answers and invite gaming.

Run the linter on a CSV export of the researcher copy before piloting:

bash
python3 bin/screener_lint.py my-screener.csv
python3 bin/screener_lint.py my-screener.csv --strict

CSV shape and flag meanings are in references/lint-and-quota-tools.md. The linter flags patterns. It does not prove a screener is clean, and a human still does the guessability test in step 7.

4. Order the screener as a funnel

Order for a written screener:

1. Consent and expectations block, step 5. Short, before any question.
2. Cheap gates that many people will fail and that reveal little: country or region for an in person or legally limited study, device or connection the session needs, availability for the session window.
3. Broad behaviour questions that cover a wider category than the study target.
4. Hidden qualifiers and their verification questions, separated by at least one unrelated question when the tool allows it.
5. Articulation question.
6. Sensitive questions that survived step 5, each with its reason given just before it.
7. Quota and demographic questions needed for balancing, then contact and scheduling details.

Two ordering pressures pull against each other and both are real. Ending a bad fit early respects the respondent time, and starting broad protects the hidden qualifier. Resolve it this way: gates that say nothing about the study topic go first, topic questions run broad to specific, and no specific question appears before its broad cover question.

In branching, send a [reject] to a short thank you page at once. Do not let a rejected respondent keep answering, and do not show them which answer ended it. Use the same thank you wording for quota full, not a fit, and scheduling failure where the tool allows one page, or neutral wording on each page where it does not. A page that says sorry, we needed daily users tells the next attempt exactly what to claim.

5. Handle consent and sensitive questions

Put a consent block before question one. For ordinary commercial or product research it should state, in plain language:

• That this is research, who is running it in general terms, and the general topic.
• What taking part involves if selected: method, session length, recording if any, and that the screener itself takes a few minutes and does not guarantee selection.
• That taking part is voluntary, they can stop the screener at any point, and they can skip a question where the tool allows skipping.
• What happens to screener answers for people who are not selected: who sees them, how long they are kept, and whether they are used to invite the person to other studies. Answer this honestly for your own process and write the real retention choice in the template before launch.
• Incentive terms in brief: amount or form only if your process states it at this stage, who gets it, and that completing a screener alone does or does not earn it, whichever is true.
• A contact for questions about the research or about their data.

For research under the US Common Rule, 45 CFR 46.116 lists more: purpose and expected duration, procedures and which are experimental, foreseeable risks, expected benefits, alternatives where relevant, how far confidentiality of identifying records goes, compensation or treatment if injury occurs in more than minimal risk research, who to contact about the research, about participant rights, and about injury, a statement that refusal carries no penalty and stopping is allowed at any time, and a statement about future use of identifiable information. Use that list as a completeness check and route the final wording through the IRB or policy owner. Do not claim compliance from this skill alone.

Sensitive question rules:

• Ask only when a criterion in step 1 needs the answer. Curiosity, client habit, and a panel field existing are not reasons.
• Say why, right before the question, in one sentence tied to the study: we ask about household income in bands because sessions are grouped by budget range. Then ask in bands, not an exact figure, unless an exact figure is the criterion.
• Offer prefer not to say where the study can live with it, and decide in the researcher copy what that answer does: quota unknown, manual review, or reject. Write the decision down. Never leave it to whoever reads the responses.
• Never bury a sensitive question inside a decoy list to disguise it. Hiding a qualifying answer is fair craft. Hiding that you asked about health, income, or identity is not.
• Keep sensitive answers out of file names, calendar invites, chat messages, and shared trackers. Store them in the research record with the rest of the screener and limit who can open it.
• Take extra care with children and young people, patients, employees of the sponsoring company, and anyone in a dependent relationship with the researcher. The ICC ESOMAR code requires parent or responsible adult consent before interviewing children and treats cooperation as voluntary at every stage. Follow the stricter of your local law, your organisation policy, and the study protocol.
• Withholding the precise hypothesis is allowed. Misleading people about the general purpose, the time involved, recording, or how their data will be used is not. ESOMAR frames cooperation as based on adequate and not misleading information about the general purpose and nature of the project.

6. Set quotas and run the tracker

Build quotas from the target population and the comparisons the analysis needs, not from who is easy to find.

• Write each quota dimension, its cells, the target per cell, and the reason. Good dimensions split the sample on a difference the findings will be read through: channel, experience level, company size, region, or a behaviour band.
• Prefer a small number of separate quotas over one large interlocking grid. An interlocking grid with many cells creates cells nobody can fill and invites quiet loosening late in field. If cells must interlock, state the minimum per cell the analysis can still use.
• Mark each cell hard or soft. Hard means stop recruiting that cell when full. Soft means prefer other cells first and report the final split honestly.
• Track target, screened in, confirmed, completed, and no shows per cell in assets/quota_tracker.csv. A cell that screens in and then no shows is not filled.
• Close a full cell in the screener or in the invite step, with the same neutral thank you wording as a rejection, so a full cell does not teach people to change an answer.
• Note who the source cannot reach. A panel quota can match the population on the dimensions you set and still miss people who are rarely online, rarely join panels, or cannot do a video session. Write that gap in the readout, following the caution in the online survey methods literature that quotas do not repair coverage.

Check the tracker in field:

bash
python3 bin/quota_check.py assets/quota_tracker.csv
python3 bin/quota_check.py my-study-quota.csv --stage confirmed

The tool reports remaining places per cell, flags overfilled cells, and totals each stage. See references/lint-and-quota-tools.md.

7. Run the pre-launch review

Do not launch until every item in assets/prelaunch_review.md passes or has a written, dated exception.

Core checks:

• Guessability test. Give the participant facing copy, with no brief, to someone who did not write it. Ask two things: what do you think this study is about, and which answers do you think you would need to give to be picked. If they can name the must select answer or the target brand, rewrite the cover questions or the list before launch.
• Logic walk. Follow every path by hand: each [reject], each branch, each quota full route, the prefer not to say routes, and the other text route. Confirm each path lands on the right next question or the right thank you page.
• Consistency pairs. List every pair of questions that must agree, such as role and tasks, tool list and tool named in the open answer, age band and a date or life stage given elsewhere. Inconsistent pairs are a review task in field, not an automatic accusation.
• Wording pass. Read each question aloud. Cut jargon, double negatives, double questions, vague frequency words, and any option set that overlaps or leaves a gap.
• Sensitive pass. Every sensitive question has a reason sentence, bands where bands will do, a decided prefer not to say route, and a storage note.
• Incentive and gaming pass. Assume the screener link will be shared in a place where people trade tips on qualifying. Check that the title, the file name, the URL slug, the invite email, and the thank you pages give nothing away. A screener file named daily-users-of-brand-x fails this check before question one.
• Pilot. Run the screener with a small set of testers, including at least one person who should qualify, one who should not, and one boundary case from the criteria table. Record where they paused, what they misread, and whether the logic routed them correctly. Nielsen Norman Group and User Interviews both treat piloting as a required step, for wording and for skip logic. Fix and re-pilot any question whose wording changed in a way that could flip an answer.
• Phone or live re-screen plan, for moderated studies. Write a 2 to 5 minute script that asks the person to expand on two or three screener answers in their own words, following Nielsen Norman Group guidance on synchronous screeners. Use it to check honesty, fit, and whether the person can talk through their work, which a written form cannot show.

8. Field it, watch it, and close it cleanly

• Watch four numbers daily while in field: completes, termination rate by question, quota fill by cell, and the share of open answers flagged as thin or inconsistent. A sudden rise in qualification on one question usually means the answer is being shared or the question is leaky. Pause and inspect before recruiting more.
• Review flags as a person. Location mismatch, a VPN, a VoIP number, a fast completion, or a reused device are signals reported in the fraud literature and by panel providers, and each one also has an ordinary explanation such as travel, work networks, or privacy tools. Flag, check a second signal, and re-screen. Never reject on one signal alone and never accuse a respondent of fraud in a message to them. Use neutral wording: we could not confirm a fit for this study.
• Re-screen at the session start with two warm up questions tied to the claimed behaviour, and compare with the screener. If the answers do not match, end politely, follow your stated incentive policy for a session ended by a mismatch, and log the reason in the research record.
• Keep a record of confirmed bad actors in your own research operations file so the same person is not recruited again under a new address, and report confirmed misrepresentation to the panel provider when you used one. Keep that record factual: date, study, what was inconsistent, and who decided.
• Pay and thank as promised, including people screened out where your stated policy covers them.
• At close, file the criteria table, both screener copies, the tracker, the pilot log, the review sheet, and counts: invited, started, screened out by reason in aggregate, quota full, confirmed, completed, no shows, sessions excluded after the fact with the reason. A later reader should be able to see who you wanted, who you got, and where they differ.

Output Contract

Deliver, every time:

1. Criteria table, filled, from assets/screener_template.md: one row per criterion with type, evidence, source, and failure mode, plus team choices labelled as team choices.
2. Two screener copies: participant facing with no logic marks, and researcher facing with [must select], [may select], [reject], [quota], and [verify] marks, a stated answer route for every option including prefer not to say and other, and a neutral thank you page text.
3. Consent block as it will appear, with the retention choice for unselected respondents filled in with the real practice, not a placeholder.
4. Quota tracker in the shape of assets/quota_tracker.csv, with target, screened in, confirmed, and completed per cell, hard or soft marked, and a note on who the source cannot reach.
5. Pre-launch review sheet from assets/prelaunch_review.md, completed, with the guessability test result, the pilot log, and any exception written and dated.
6. Lint report from bin/screener_lint.py on the researcher copy, with each flag fixed or explained.
7. Close out counts at the end of field, as listed in step 8.

Operating Rules

• Never ship a screener that was not piloted and did not pass the guessability test. If time pressure forces a launch without one, say so in the review sheet and in the readout, as a limitation.
• Never put logic marks, the target answer, the client name where it primes behaviour, or a sensitive answer in anything a respondent can see, including file names, URL slugs, invite subjects, and calendar titles.
• Never use a demographic question as a stand in for a behaviour you could ask about directly.
• Never collect a sensitive answer you cannot point to a criterion for, and never reuse screener data for marketing, sales, or any purpose outside the research the person agreed to. ESOMAR states that personal data collected in a research project must not be used for another purpose.
• Never treat one fraud signal as proof. Two independent signals plus a failed re-screen is the minimum for removing someone as a suspected bad actor, and the record states the signals, not a label about the person.
• Never loosen a must have or a quota in field without writing the change, the date, and the reason in the criteria table, and noting it in the readout. Quiet loosening is how a mixed panel turns into a convenience sample while keeping the old label.
• Keep numbers honest. Any threshold in the deliverable that came from team preference, such as a recency window or a gap since a prior study, is labelled a team choice. Thresholds traced to a source are cited to that source.
• Style: plain sentences, no em dashes in any output.

References

• references/worked-example.md: a complete worked screener for a mixed panel, brief to criteria table to researcher facing questions to quotas to review notes.
• references/consent-and-sensitive-questions.md: consent block wording for ordinary product research, the Common Rule element check, and sensitive question rewrites.
• references/lint-and-quota-tools.md: CSV shapes, flag meanings, and worked runs for both tools.
• assets/screener_template.md: blank criteria table plus screener skeleton with logic slots.
• assets/quota_tracker.csv: tracker shape the quota tool reads.
• assets/prelaunch_review.md: the review sheet that has to pass before launch.