Overview
…
Goals
After the problem definition stage, we outlined the objectives and expected outcomes of this design sprint:
Improve the experience of recruiters.
Increase the number of candidates placed in job vacancies.
With the objectives defined, we conducted several sessions among the product team and stakeholders to generate insights and document business expectations and no-go's.
Discovery
Analyzing the recruiter's user journey during the execution of a job, we listed the nine recruitment stages that initially aimed to ensure a robust delivery for companies and job managers. It's worth mentioning that the job started with an alignment meeting between the job manager and the freelance recruiter.
Alignment Form: In this stage, the recruiter had to fill out a form with data extracted from an alignment meeting with the job manager to document expectations.
Contact Information: A stage for registering contact methods with the job manager in case the recruiter needed to clarify any doubts or conduct a new alignment.
Delivery Schedule: Here, recruiters and managers defined the delivery dates for each of the subsequent recruitment stages.
Alignment Summary: Upon completing the alignment meeting and the filling of the first three stages, a summary of the alignment between the parties was sent to the job manager for approval or disapproval. The next stage could only be initiated upon approval, and in the meantime, the recruiter had to wait.
Candidate Screening: After approval of the alignment summary, the candidate screening stage began, where recruiters had to input preliminary profiles of candidates found during the hunting process. The insertion of these candidates was simplified and aimed to help recruiters list potential candidates and only advance those who made sense for the job.
Interview Stage: In this stage, recruiters were required to assess those candidates who progressed from the screening stage. The assessment was to be conducted through an interview.
Market Research: A stage dedicated to recording recruiters' insights gained during the hunting process.
Shortlist: In this final stage of recruitment, recruiters had to list the candidates assessed during the interview stage and send them to the company.
Recruitment Summary: This stage served as a "delivery confirmation." Upon receiving the shortlist, the company could either accept or reject the candidates. If accepted, the recruiter's work was concluded.
After listing these stages, we conducted a round of qualitative research with recruiter users and companies.
During conversations with recruiters, we received many complaints about the job alignment stages. For them, these stages didn't make sense because job managers often didn't have available time for planning discussions, leading recruiters to fill out the forms superficially just to keep the process moving.
Furthermore, interviews made it clear that the candidate insertion stages were too bureaucratic. Recruiters were bypassing these stages by using other tools for candidate screening and only inputting candidates with a high likelihood of matching the job. This behavior was contrary to our expectations, as the idea behind the Huntly recruitment stages was to unify the process in a single tool that encourages the input of all candidates found during hunting.
As a result, fewer candidates were being registered in the application, weakening our data collection and decreasing the chances of job success. This was the primary problem we needed to address.
…
Definition
Based on these findings, we conducted several sessions with business stakeholders and determined that a dedicated squad would be necessary to carry out these alignment stages with the companies. This would ensure that the job positions arrived ready for recruiters, allowing them to focus solely on candidate hunting and evaluation.
After defining this change in our operation and business model, we proceeded with the development of the solution for the Huntly recruitment stages with the challenges of:
Making the process more fluid by removing the linear aspect of candidate navigation and progression.
Decreasing the time required for shortlist delivery.
Increasing the number of candidates uploaded by recruiters.
For the first challenge, we listed the jobs to be done and created the user journey. After the analysis, we could clearly see which stages were redundant in the flow and what could be simplified.
The "Market Research" stage didn't align with recruiters' workflow and didn't add value for clients, as much of the information filled in this stage could easily be identified by job managers during the analysis of candidates sent in the shortlist.
Another stage that could be removed was the "Recruitment Summary." While this stage was essential for Huntly, marking the recruiter's delivery and the company's "approval," for recruiter users, it was an obstacle. The process could only continue if the company approved the shortlist, something that happened at a much slower pace due to the different rhythms of job managers during the hiring process. This delay in shortlist approval directly impacted recruiter payments, as the longer the shortlist took to be approved, the more time it would take to hire a candidate and send the payment to the recruiter.
Again, we met with stakeholders and discussed the possibility of removing this stage. This possibility was well-received since it not only added value to users through flow optimization but also allowed the creation of an internal operational process for shortlist curation, sending, and follow-up actions by the company. This new operation would help increase the success rate of jobs, resulting in more hires, revenue for Huntly, and payouts for recruiters.
At this point, only three stages remained in the "Huntly recruitment stages": screening, interview stage, and shortlist.
We revisited our recruiter users, and the main result was identifying that in the "interview stage," only candidates that recruiters were sure would be sent to the shortlist were evaluated. Thus, the "shortlist" stage, meant for the organization and final selection of candidates sent to the company, became redundant due to the usage pattern adopted by users.
We also found that the "screening" stage was important for recruiter users despite being considered a bureaucratic step.
With these findings, we simplified the flow by removing the "shortlist" stage, reducing the number of screens to just two.
…
With the remaining two screens, we sought to understand what made the process of candidate insertion and progression bureaucratic. We identified the following issues:
Two mandatory forms for inserting a single candidate at different times: The "screening" page had a form for basic candidate information, while the "interview stage" page had a more complex form with candidate enrichment fields, as well as the technical assessment that should include interview details and the recruiter's technical opinion about the candidate.
Construction of the technical assessment: Analyzing the assessments written by recruiter users, we found that this document was often done in a basic way with the goal of "speeding up" the process. Despite being an important deliverable for clients, our users did not enjoy writing this document.
Navigation: Linear navigation between the two pages was tiresome and generated the feeling of a bureaucratic process for users.
With these new insights, we understood that the main challenge of the redesign would be to unify the two stages into one, optimize the candidate insertion form, and provide assistance in constructing the technical assessment.
In addition to eliminating excessive navigation from the job page, we aimed to simplify the product's proposed mental model. In this new model, the main task for the recruiter user would be to send and interview candidates only. We believed (and later confirmed) that this was the path to enhance job delivery.
We began sketching with the goal of finding a page layout and components that could fulfill the proposed objectives.
After a few ideation sessions, we moved on to building low-fidelity prototypes.
Initially, we created some prototypes where the main component of the page would be a table. The idea was to increase the visibility of process data by spreading information throughout the table. Additionally, we added tabs to the page header to facilitate access to job information.
After some testing and discussions, we concluded that a more familiar element for recruiters might be better understood and used (Jakob's Law). With this in mind, as we had already heard some suggestions from recruiters that were reminiscent of functionalities in an ATS (Applicant Tracking System, a system used by companies for candidate screening and tracking), we decided to delve deeper into these systems and how we could integrate their features into our product.
Exemplo de um ATS (imagem por usrnk1, do Dribbble)
With this new direction, we built a new prototype and replaced the table with a kanban with only two essential columns:
Draft
Shortlist
The "Draft" column would serve as the previous "screening" stage, where recruiters could use it as a workspace to save potential candidates.
On the other hand, the "Shortlist" column would function as a definitive space for sending the candidate to the company. After completing the candidate's profile and deeming them ready to participate in the hiring process, the recruiter would move them to this column, and from that point onward, the company would have access to the candidate's profile.
We created a low-fidelity prototype and tested it with some users. During the tests, we observed that the model was well understood, and the kanban component stood out for its resemblance to other services, making it easy to grasp.
With the validated prototype, we began the creation of high-fidelity prototypes.
With the high-fidelity prototypes ready and tested, we proceeded with the implementation in the product.
Implementation & Impacts
The implementation lasted about three months, and it was a process that I really enjoyed experiencing. Performing the handoff and monitoring the development was an experience that added a lot to my technical knowledge of how software development truly works and how the product matures and transforms.
Seven months after the implementation, we conducted an analysis of the impacts of this new version of the job page. The main results were:
Number of candidates sent pre-implementation: 344
Number of candidates sent post-implementation: 1343 (increase of 290.4%)
We are still measuring the impact on the number of completed job placements. Once the data is collected, I will update the case :)
