Chat-Based Recruiting Web Project - FactoryFix
Project Overview

Recruiting in the manufacturing sector is no easy feat. With unique challenges that can hinder the process, recruiters must be creative and resourceful to find the right talent for the job. One of the biggest obstacles is the outdated and incomplete resumes that are often submitted. Furthermore, traditional communication channels, such as email and phone calls, may not be effective, which adds another layer of complexity to the recruitment process.

To address these issues and help recruiters make more informed decisions, I led the design effort in the creation of the Conversations page on the FactoryFix Recruiting Platform. It offers a conversation-centric approach to candidate screening and selection. With this tool, recruiters can easily communicate with applicants via SMS and chat directly from their computer.

My Contribution
UX Research
UI Design
User Testing
Tools Used

Conversation Centred Candidate Management

The Conversations page allows recruiters to ask targeted questions and gather more information from candidates that may not be evident on their resumes. This way, they can fill in the gaps and make a more informed decision about whether or not to invite the candidate for an interview.

The aim of this project was to enable recruiters to communicate with and make decisions about the candidates in their pipelines. Using the rich information contained in the conversations between them and candidates, recruiters would have the context they needed to make well informed decisions.

Our team's goal was to improve recruiter engagement by making it easy for them to take actions on candidates and this project was at the center of making this possible.

The Design Process

I started off with a breadboard to help me communicate the initial idea to my product manager and other stakeholders
I then proceeded to create the first fat marker sketch that translated the breadboard into a visual design.
I iterated on the fat maker sketches and continued collecting feedback and ideas from the team.
I decided to drop the idea to have the filter as part of the navigation menu since it was in conflict with other teams' plans to redesign the navigation and it introduced a lot of rabbit holes on how to deal with edge cases like if a recruiter had 6 assigned jobs.
In the midst of all of this, I continued refining my understanding of the user by watching what they were doing on Hotjar and relating that with the user interview repository we had in Dovetail.
As I continued to increase my level of resolution in the designs, it became apparent that the part of the interface that had the most risk was the filter section. It was the part of the messaging interface that did not exist in some form and it had deep implications for how users would use the messaging experience and how engineers would build the page.
I, therefore, decided to put a lot more attention to this part before proceeding with other parts of the interface.
All the while, I continued to ask for feedback from the design team in critique sessions.
I also reached out constantly to the developers as I proceeded with the design process. Their questions and concerns provided useful insight into the  parts of the design that could put the timelines of the project at risk.
At this point, I was feeling pretty confident about the solution so I proceeded to explore how I would add candidate message cards into the experience.
Shortly after, I started doing user testing with power users of the existing messaging experience to get a feel of how usable the features we had introduced were and what impact this new flow would have to their recruiting experience.
This screenshot gives a bird's-eyes view of the entire design process. Most of the design work happened on Figjam and I only went into Figma to create the final design. This helped reduce the illusion of clarity that high fidelity mockups create when thinking about the problem and asking for feedback.

The Design Solution

Here's a prototype walkthrough of the final design.

Even though this was the final optimal design that we tested and got feedback for, we needed to pair it down for the first cycle since the final design could not be developed in one 8 week cycle.

In the paired down version, we removed the read/unread functionality, the search and the sorting capabilities. This would allow us to deliver the first version of the design in 8 weeks. It would also help us get a basic proof of concept before investing further into the idea.