Recruitment is where a usability study either earns its evidence or quietly loses it. Test the wrong people, skip the consent conversation, or keep recordings longer than you can justify, and the findings are built on a shaky base. This is a deeper look at the two things that determine whether recruitment holds up: where participants realistically come from, and what GDPR requires once you're asking Irish residents to take part in a research session. It expands on the recruitment questions covered briefly in our usability testing service page and in question 4 of 9 questions to ask a usability testing supplier.
Where participants actually come from
In practice, almost every usability study in Ireland draws participants from one of two sources, and most credible proposals are explicit about which one applies and why.
The client's own customer base
For a lot of studies — especially anything testing an existing product, service or account area — the strongest participants are people who already use the thing being tested. A client emailing its own newsletter list, CRM segment or existing customers for a short paid session usually produces people with real task history, which is exactly what the research needs. The trade-off runs the other way: a self-selected group of engaged existing customers will not reflect people who tried the service and bounced, or people who never heard of it. Whether that matters depends on the research question — testing a checkout improvement for existing customers is a reasonable use of this route; understanding why prospective customers abandon before signing up usually isn't.
This route has a data-protection dimension the client needs to own from the start: contacting people through a customer list has to fit within what those customers were originally told their data would be used for, or needs a separate, clearly explained invitation and consent step for the research itself. "You're already on our mailing list" is not, on its own, a basis for recruiting someone into a recorded research session.
An agreed recruitment route or panel
Where the client doesn't have a usable customer base — a pre-launch product, a B2B audience too small to self-recruit from, or a study that needs people outside the existing customer set — recruitment runs through an agreed external route instead: a recruitment panel or agency, a targeted call for participants, or, for specialist audiences, partner organisations who can help reach people with particular access needs. Whichever route is used, it should be named and agreed before the study starts, not decided informally once recruitment turns out harder than expected. The GOV.UK Service Manual's guidance on writing a recruitment brief is a useful independent reference: it recommends stating criteria plainly enough that a third-party recruiter can screen against them, actively welcoming disabled people and people with limited digital skills rather than letting recruiters exclude them by default, and checking the actual screener questions an agency writes, since agencies routinely miss points from the brief or add their own questions that can accidentally rule people out.
Whichever route is used, recruitment through a third party is still processing of personal data on the client's behalf — the responsibility for lawful recruitment, consent and data handling does not transfer away just because someone else is doing the outreach.
What GDPR requires before, during and after a session
Usability testing collects personal data — names, contact details, sometimes video, audio or screen recordings that reveal account information. That makes it GDPR-relevant work. Ireland's Data Protection Commission (DPC) doesn't publish guidance written specifically for UX researchers, but its general guidance applies directly to a research session. What follows is kept general — this is not case-specific legal advice, and studies with particular sensitivities should get their own legal sign-off.
Before the session: lawful basis and information
Every use of personal data needs a lawful basis under Article 6 GDPR before it starts. The DPC's guidance lists six possible bases — consent, contract, legal obligation, vital interests, public task, or legitimate interests — and for research sessions with members of the public, consent is usually the right one, particularly where a recording is involved. To count as valid, the DPC's own definition is that consent "must be freely given, specific, and informed" — participants cannot be pressured into taking part, and need to be told plainly what their data will be used for before they agree.
Separately, Articles 13 and 14 GDPR set out what participants need to be told when their data is collected: who is running the study and who else — an agency or panel — is involved, why the data is being collected, how long it will be kept, and that participants can access, rectify, restrict, object to or erase their data, and can withdraw consent and complain to the DPC. In practice this is a short, plain-language briefing, not a page of legal text — but it has to cover those points, not just say "we may record this session."
During the session: recording and special-category data
Recording is its own consent decision, separate from agreeing to take part. A participant can be willing to attempt the tasks but unwilling to be recorded, or willing to have their screen captured but not their face on camera; the consent process should let them say so, rather than bundling "take part" and "be recorded" into one tick box. If a session might incidentally reveal special category data — health information, financial detail, anything beyond the task at hand — that should be anticipated in the study design, not handled improvised on the day.
After the session: retention and the right to withdraw
GDPR sets no fixed retention period for research recordings, notes or contact details. The DPC's retention guidance describes a "storage limitation principle" instead: data should be kept "for no longer than is necessary for the purposes for which the personal data are processed," and once that purpose has been served, deleted or securely disposed of. For a usability study, that generally means personal identifiers — names, emails, recognisable faces in recordings — shouldn't be kept indefinitely once the report is delivered and findings no longer need tracing to a named individual. A defined retention period, stated up front and actually followed afterwards, is the practical way to meet this.
Participants also keep the right to withdraw consent after the fact. The DPC is explicit that the right to erasure applies "where you withdraw your consent to the processing and there is no other lawful basis for processing the data" — so a study needs a working process for "please delete my recording," not just a form signed before it starts.
Screening criteria that serve the research question, not the sample's optics
Screening criteria exist to answer one question: does this person's experience tell you something relevant to the decision the research needs to support? Everything else is noise, and noise in a screener has a cost — it either shrinks the pool of people who qualify, or it produces a sample that looks varied without actually being informative.
Criteria worth including are tied directly to the task: prior experience with the product or task type, customer type (existing customer, prospect, lapsed user), relevant digital confidence, the device or browser the study needs to cover, language, and — where the question makes it relevant — access needs or assistive technology use. A study evaluating a new-customer onboarding flow legitimately screens out existing customers who already know the product; a study evaluating an assistive-technology journey legitimately screens for people who actually use that technology day to day, rather than asking sighted participants to "try it with their eyes closed" as a substitute.
Criteria worth dropping are the ones added just to make a small qualitative sample look demographically balanced — an even age or gender split across five or six participants, say — when the research question has nothing to do with age or gender. A handful of participants was never going to represent the full population on those dimensions anyway, and a token quota adds recruitment friction without adding evidence. The honest version is to state plainly, in the report, who was tested and what that group can and can't tell you — not to over-engineer the screener so the sample looks more representative than it is.
Where a study concerns accessibility or assistive-technology use, the opposite failure mode shows up: disabled participants get treated as a late add-on rather than a group whose access needs shape the session format itself — length, break structure, remote versus in-person, and which assistive technology the moderator needs to accommodate. Planning that with participants from the outset is what makes the criteria serve the research rather than just the recruitment brief.
Sources
- Data Protection Commission: Guidance on Legal Bases for Processing Personal Data
- Data Protection Commission: Definition of Key Terms (consent, personal data, processing)
- Data Protection Commission: The right to be informed (transparency) — Article 13 & 14 GDPR
- Data Protection Commission: The right to erasure — Articles 17 & 19 GDPR
- Data Protection Commission: How long should personal data be held to meet the obligations imposed by the GDPR?
- GOV.UK Service Manual: Write a recruitment brief
Read next
- Usability testing service — how we scope and run a study, including recruitment and participant numbers
- User research — for upstream discovery work before a testing round is designed
- 9 questions to ask a usability testing supplier in Ireland — including the recruitment and data question this article expands on
- Heuristic audit vs usability testing: which one first?
Planning a study and need recruitment scoped properly?
Use the brief call to talk through where your participants would realistically come from, what consent and recording process fits the study, and how long any recordings need to be kept.