Transforming the recruitment game with AI
About HRGO
HRGO is a UK-based recruitment agency, founded in 1957, that aims to revolutionise recruitment by combining technology with a personal touch, focusing on finding the right talent and creating a positive experience for both employers and candidates.
Their core philosophy is:
"To leave everyone better than we find them".
Problem Statement
Eclipse UX Designers worked with a team encompassing product managers, technology experts and developers, my job was to assist discovery of the problems the company faced when hiring temporary workers, fast.
Working with the team to find the stakeholders who would be best placed to set up calls with – the people that would be using the new product (Font) to find out what would the key pain points were in their current processes.
I set up discovery sessions with consultants (recruiters) at HRGO who deal with hiring and onboarding of temp workers on a daily basis to find out what their current processes were and where the problems with their current tech solution lay.
Clear articulation of the challenge
Early discovery (discussions and workshops with consultants who deal with temp recruitment on a daily basis) revealed that one of the core issues was that the jobseekers who applied for a job and were unsuccessful in a particular role could easily be lost in the system and not always considered for future roles where they could be a good fit.
They had a database full of potential candidates, new roles opening up all the time and no way of matching these candidates to the roles.
As artificial intelligence continues to evolve into a powerful tool, we recognised an opportunity to leverage its capabilities to enhance the recruitment process. AI had the potential to streamline and optimise candidate matching, making it easier for recruiters to find the right talent efficiently.
With this in mind, we set out to develop a new feature called Betty Search, designed to intelligently match candidates to job opportunities based on their skills, experience, and location and provide a match percentage against the job title and description that consultants had put into a search.
By harnessing AI’s ability to analyse vast amounts of data quickly and accurately, Betty Search aims to improve hiring outcomes, reduce time-to-hire, and provide a more seamless experience for both recruiters and job seekers. Betty Parkinson was the name of the founder of HRGO, and this tool was named in her legacy. Read more about Betty.
Business context and importance
The aim of this was to match more candidates to roles, quicker, and have a better-matched “pool” of candidates which we could present to clients for their open roles. This meant better candidates for clients and candidates were put into roles faster.
Key metrics included:
- Number of people using Betty search (as an initial metric to monitor whether this number increases or decreases in time – are people using it?)
- Candidates added to jobs via Betty search
- Adding a job → time taken to fill the role (all required positions filled)
Constraints and limitations
We built the initial version of Betty search in early 2024 and the technology used was in its infancy and inaccuracy in results was high.
Research & Discovery
Research methodologies used
We designed and developed Betty search and tested it with users using moderated testing: We set up calls with initial set of five consultants that hire temp candidates on a daily basis and asked them to find candidates for job vacancies that they currently have. We asked them to talk us through the process – what they were doing, what they were looking for and what they were feeling. We recorded these sessions (with the consultants’ permission) and referred back to these again after the recordings were complete to monitored facial expressions throughout the journey for signs of frustration.
After the initial user testing session, we themed up the following patterns:
Learn more about our approaches to research and experimentation
Key pain points identified
- Consultants found it difficult to use. This appeared to mainly be due to content overload on the page.
- Results were inaccurate – candidates often showed up with high % matches when they didn’t have the correct skills or qualifications.
Prototyping
We designed and built a UI that asked recruiters to enter their search criteria (skills, qualifications, etc required for the job), postcode, the distance in miles from the postcode entered (for temp work clients would want candidates near the location), active in the past week (when the candidate had last logged in to their account) and whether a drivers licence and having their own car was required for the job.
Since we had a lot of the candidate information in our database already from the temp candidates (they are all required to create a “candidate account” so that they can provide their CV, contact information and any compliance requirements such as proof of right to work), we could use the information to match candidates based on their location and skills/experience in their CVs.
Once the initial working prototype was built, we went back to the consultants to ask them to try using the new Betty search feature for real jobs they were looking to fill.
We then arranged a second phase review of the functionality (one-on-one moderated user testing sessions) and found out where issues had arisen...
Pain points with the initial working prototype (let’s call this Version 1)
- Recruiters were unsure of how to use the search criteria area – they often entered just a job title or a few keywords to search for candidates
- Recruiters were unable to contact candidates or add candidates to existing jobs
- Recruiters couldn’t search for candidates if they didn’t have a job already in Font (e.g. searching for potential matches if a new client was looking to sign up with us but hadn’t signed off yet – the results would of course be confidential up until that point but getting information early on helped)
- Results were inaccurate – candidates often showed up with high % matches when they didn’t have the correct skills or qualifications.
- Consultants found it difficult to use. This appeared to mainly be due to content overload on the page.
Version 2
We updated the designs and developed an adjusted UI that attempted to tackle the most common issues above, one by one:
- Recruiters were unsure of how to use the search criteria area – they often entered just a job title or a few keywords to search for candidates
We adjusted the AI to automatically-populate the search criteria field once client/job and distance fields had been entered. The recruiter could then adjust the search criteria to ensure it contained all requirements needed by the client and role before searching for matching candidates.
- Recruiters were unable to contact candidates or add candidates to existing jobs
We added a selector (checkbox) to each candidate card so that recruiters could group message candidates to ask if they were interested in a working a particular job and invite them to apply for a job
- Recruiters couldn’t search for candidates if they didn’t have a job already in Font (e.g. searching for potential matches if a new client was looking to sign up with us but hadn’t signed off yet – the results would of course be confidential up until that point but getting information early on helped)
We added the option to search for candidate matches against a specific, existing job in Font (default) and add candidate matches from the results, OR search for matches that were not client specific (“Manual search” toggle – the toggle pattern was not standard for this type of “switch” between views, but we decided to test it with users and get their feedback)
- Results were inaccurate – candidates often showed up with high % matches when they didn’t have the correct skills or qualifications.
We revisited the AI tool and scraped data from the candidate CVs and parsed it through development again to try and get more accurate candidate matches. On the second pass, the matches still needed work but were distinctly more accurate than version 1 (we reviewed the job titles and search criteria that had been entered by recruiters and the CVs of the candidate matches and found much better semantic matches on requirements overall)
- Consultants found it difficult to use. This appeared to mainly be due to content overload on the page.
When reviewing the main components that had been used on this page for searches, we found that drivers licence and own car were selections that very few people used, so we moved these to a new Filters area, ensuring they were deselected by default (so not filtering any results that shouldn’t be filtered out, but allowing for additional filters to applied if needed.
We also found that the “active” filter wasn’t being adjusted much, and that having it default to 12 weeks was greatly limiting the results provided, so we adjusted the default for this filter to 20 weeks and monitored the use of Betty search. We also realised that due to the nature of temp work, being inactive for multiple weeks but changing role/company in the temp industry is extremely common, so waiving these results was risky.
Pain points (Version 2)
- Recruiters were unsure of what the manual search toggle meant
- Recruiters often missed the filters option after performing a search
- Recruiters were unsure of which candidates were already working
- Consultants were still having a little trouble with finding accurate candidate matches. They were entering the client/job field, distance, and then getting confused as to why the page would start loading (we were previously generating the search criteria as soon as the two fields had been entered, although the recruiter hadn’t specifically pressed anything/done anything to action that request
- Recruiters were frustrated when they had to click in to each candidate (new page) to view their CV, skills and work history
Version 3
We adjusted the “manual search” toggle with radio buttons and adjusted the wording for clarity, so the radio buttons now read Search against existing jobs / Manual search.
We further simplified the UI to only display client/job title and distance fields. If a job existed in Font, the recruiter could search and select this job using this field and we would know the postcode from the job that had been added. The manual search option still asked for postcode.
We added “chips” (tags) to show if a candidate was already working for one of our clients/jobs. In the temp industry, this doesn’t necessarily mean they are excluded as many temps work at more than one client/job in a week but served as a note to bear in mind.
We moved the search criteria that had been generated by the AI prompt into an “Advanced filters” area below the search along with the driver’s licence and own car requirements. On our user testing sessions, we found this to work well as there was less “distraction” on the page for consultants who wanted to see results quickly, and fine tune the requirements thereafter.
We adjusted the search to get users to specifically click the search button when they were ready to find a candidate. This decreased confusion when the page would start loading results before any specific action was taken (clicking the search button).
We adjusted the loader - it was previously a loading bar at the top of the page and quite difficult to see, which previously wasn’t much of an issue and most of the site loaded very quickly. But since we were using AI prompts to call and create a job specification (which was no longer shown at the top of the page), we needed to clearly show that the page was performing an action/loading and calling data, so we changed the loading bar out for a spinning wheel and screen tint.
Consultants could now clearly see that the page was loading results.
We also added the “Quick view CV” option as consultants had fed back their frustration with having to open new pages for each candidate result to review their CV and work history. This opened a contextual drawer to show the information for that specific candidate.
Pain points with the initial working prototype
- Consultants found it difficult to use. This appeared to mainly be due to content overload on the page.
- Results were more accurate than our previous version but needed improvement
Conclusion
We iterated different versions of the product to simplify and improve the user experience. By listening to real users and analysing how they interacted with Font, we made informed changes that drove continuous improvement. But like any site, app or software, when UX is done right, this process is never truly finished - there’s always more to learn, more to refine, and more ways to evolve as user needs, technologies, and expectations change. It is a living product, always growing with its audience.
The Results
