Insight · 9 November 2026 · 5 min read
Origin Growth sets out how to test trust in recruitment journeys
A recruitment journey can be easy to complete and still difficult to trust. We explain how user research can test applicants’ understanding of automated assessment, decision inputs and routes to challenge an error.
Origin Growth believes recruitment journeys should be tested for understanding, not just completion. HR News reported on 7 November 2026 that a study had identified a trust gap between employers and jobseekers as automated recruitment tools become more widely used. For UK digital and operations leaders, that is a useful prompt to examine what applicants actually understand about the service in front of them.
Our view is straightforward: a submitted application is not evidence of an understood process. Research should establish whether applicants can explain where automation is involved, which information affects an assessment and what they can do when something is wrong. Those are practical design questions, not matters to leave entirely to a policy page.
Before recruiting research participants, we would map the application journey alongside the decisions behind it. Identify where information is extracted, where criteria are applied, where candidates are ranked or filtered, and where a person reviews the result. Include only functions the organisation actually uses; a generic description of the supplier’s capabilities is not enough.
For each point, establish what the tool does, what information it receives, what its output changes and who is accountable for acting on it. Distinguish administrative support from assessment. Extracting employment dates from a document is a different task from using those dates to influence progression.
This becomes the foundation for the research script. Without it, a team can test whether wording sounds reassuring without knowing whether it accurately describes the service. Pleasant copy is not the same as a reliable explanation.
We would bring recruitment, digital, operations and the relevant supplier into this mapping exercise, with privacy and legal colleagues reviewing the proposed explanations where appropriate. The aim is a shared, usable account of the process, rather than a technical inventory.
Choose a bounded journey for the first round: application submission through to an initial progression decision, for example. Mark every point where an applicant needs information or can correct something. That gives the team a manageable scope and makes gaps in ownership visible before testing starts.
We would use moderated task-based research with a realistic prototype or safe test environment, never a live hiring decision. Give participants a fictional vacancy and application materials, then ask them to work through the journey as they normally would. Explain the research setting clearly and avoid collecting unnecessary personal employment information.
Recruit across different levels of digital confidence and familiarity with application systems. Include relevant access needs in the research plan. The objective is to expose differences in understanding, not to find a handful of confident participants who can navigate anything.
At selected points, ask participants to explain what they believe happens next. Start with open questions, before naming a feature they may have missed:
Observe whether participants notice an explanation unaided, whether they interpret it correctly and whether they can find it again. Keep those findings separate. A prominent notice can still be misunderstood; an accurate explanation can still be practically invisible.
Then compare their account with the mapped process. If participants believe every application receives a person’s review when that is not the case in the test scenario, record that as a specific misunderstanding. Do not soften it into a general comment about confidence. The design task is to close the gap between the actual process and the applicant’s mental model.
Understanding the process is only half the job. We would also test whether an applicant can act when the information or outcome appears wrong. A route that exists somewhere in the service is not necessarily a route people can use.
Introduce a controlled error into the fictional application: an employment date extracted incorrectly, for instance. Ask the participant to check the information and resolve the problem. Watch whether they notice the error, understand its possible relevance and can correct it before continuing. If correction is unavailable, test whether the next step is clear.
Run a separate scenario after a fictional rejection. Give the participant a reason to believe inaccurate information influenced the assessment, without telling them where to click. Ask them to find out how to request a review and what information they would need to provide.
The research should examine the whole route: finding the option, understanding its scope, submitting a request and recognising the acknowledgement. Test whether the acknowledgement explains what happens next, who will handle it and when the applicant should expect an update, using only commitments the organisation can support.
Our recommendation is to pair this interface testing with an operational walkthrough. Have the responsible team trace a dummy request through the process. Can they retrieve the relevant information, identify the disputed input and return a useful response? Research should not approve a reassuring front end while the request disappears into an unowned mailbox. A review button needs a review process behind it.
For us, the useful output is a set of observable acceptance criteria, not a broad instruction to improve trust. Agree these before evaluating a revised journey, so the team knows what successful understanding and action should look like.
Suitable criteria might include applicants being able to identify the role of automated assessment, distinguish submitted information from extracted information, correct a material error and locate the review route without moderator guidance. Adapt them to the actual service rather than borrowing a standard checklist unchanged.
Report what participants did alongside what they said. Someone may describe a journey as clear while misunderstanding who makes the decision. Equally, someone may remain uncomfortable despite understanding it accurately. We would treat these as different findings requiring different responses. Better wording cannot settle every objection to a recruitment policy.
Prioritise failures by their consequence. Misunderstanding a decorative progress indicator is not equivalent to believing an incorrect qualification can no longer be corrected. Give each material issue an owner, a proposed change and a retest task. Where the problem sits in the underlying process, change the process rather than asking content to disguise it.
For UK organisations reviewing recruitment platforms, this offers a practical starting point: one mapped journey, a focused research round and an operational rehearsal of correction and review. Contact Origin Growth to discuss a user research plan that turns applicant uncertainty into specific, testable improvements — and gives teams a firmer basis for deciding what is ready to launch.
