To resolve confusion amongst recruiters regarding the user interface and how the system was intended to work, I was asked to redesign our internal candidate search system.
The Search & Match system is a tool that Adecco’s recruiters use to discover candidates that match the requirements of a job request. Candidates from multiple databases are fed into a big data engine, allowing recruiters to find ideal candidates from multiple databases and business units within one application.
The application has two algorithms, one for search and one for match:
- Search: a search field that a recruiter can enter any string of text, plus advanced filters for specific criteria. Skills or location for example.
- Match: the recruiter copies and pastes an entire CV or job description in order to find a similar candidate or a matching candidate respectively. The advanced filters are also available.
Once a recruiter performs either a search or a match, they are presented with a list of candidates. They can view their profiles and/or download their CV. At this point the recruiter can decide if any of the candidates are potential hires, and add them to their Application Tracking System (ATS).
Recruiters can also search for jobs within the system, they have the same search & match capabilities as candidates although the advanced filters differ slightly. A recruiter who has a good candidate may not have a good job match for them, so turn to the search system to find a good fit.
One of the benefits to working with an internal system is easy access to users, so I set out to talk to as many recruiters as possible. The most common problem that kept surfacing was confusion around the difference between a search and a match. Also, having a screen for searching and a screen for matching for both candidates and jobs was deemed excessive and disorientating.
I ran a usability test with 2 groups of users. The first group was recruiters that had used the system for at least 6 months, the second, recruiters that had never used the system before.
I was interested to see and hear how recruiter’s use of the system fit their daily routine and activities, under what circumstances do they use the system? How often do they use it? Are there features that aren’t present that recruiters were expecting? Are there features there that recruiters weren’t aware of? What are their main frustrations?
After a round of interviews and usability tests I had gathered enough information and understanding to move into the discovery stage.
After many discussions, reviewing usability test videos and generally observing recruiters using the existing system. I put together an experience map to illustrate the current process and to highlight areas where we can improve the experience.
The advanced search in the existing system had text inputs for each filter, with no validation or feedback for the user. This was quickly improved by using an input that support the content best. Sliders for min and max values, auto-suggest for location etc.
I also designed a ‘create search pattern’ option so the recruiter didn’t have to populate the form for popular searches. Clear labeling and help text was also used.
To allow recruiters to narrow down large candidate results we added a faceted search. Using key data such as location, skills and salary as attributes.
Allowing recruiters to create groups of candidates was an important feature we wanted to introduce to mirror their daily activities.
To allow our recruiters to make quicker decisions on candidates eligibility, we introduced a candidate comparison tool. Displaying their experience, skills, education and location against a job request and other candidates.
During the iteration process, I was keen to remove the ambiguity between searching and matching - the biggest source of frustration for recruiters. The reality was that regardless of the algorithmic differences between a search and a match, from the recruiter’s perspective, they’re the same thing, search criteria is entered into the system search results are displayed. We therefore made the decision to remove any mention of ‘matching’ - everything was a search, only one interface.
As we were allowing recruiters to drag and drop documents to run a match, we decided that any searches from the main search box under 30 characters instigated a search, anything over that (A pasted job description for example) would instigate a match. The result for the recruiter is the same, though in the back-end the engine is doing things differently.
By integrating the search, match, candidate & job search and advanced search into one control, we reduced the cognitive load for users. 2 screens became 1 screen, and 4 controls became 1 control.
Now it was time to give the UI a skin! As this system was brand agnostic I decided to use Google’s material design. This reduced the effort by not having to create a design system or styleguide.
View the click-able prototype.
You can use the left and right arrow keys to navigate the screens
By talking to recruiters early and understanding their needs and frustrations we were able to design something with their interests at the heart of each decision. We introduced lots of quick wins (Load times, clear messaging etc.) that improved the overall experience whilst giving recruiters the features that they had been expecting.
There is still plenty of work to do here, but the feedback so far has been very positive.Back to case studies