Tackling Turnover with Nimble Recruiting

Product Design & User Research

During my tenure at OnShift I inherited a tool designed for retirement home managers to recruit hourly staff. I joined a small team comprised of a few engineers and a product manager one quarter before our major release. This case study will summarize a few key features we worked on to take this niche recruitment tool from beta to V1 and beyond.

Why SMS based recruiting?

On average nursing homes hold some of the highest turn over rates across most industries in the USA. This stat has led to a major skilled worker shortage in this industry. In the USA post acute care facilities (nursing homes) need a certain worker to patient ratio for these facilities to stay open legally. OnShift’s answer to this problem was a recruiting tool that let enables recruiters to respond to many applicants quickly and conveniently via an SMS chatbot that would schedule and set up interview times.

Project Timeline

Project Starts

Chatbot Complete

Alex Joins Project

My work

Initial release

Fast and furious planning

Creating a long term backlog in three months

When I joined the team most of the work on the chat bot was already completed by a designer that just left OnShift. So it was my job to help the team evaluate the rest of the product to determine what we needed to prioritize before our first major release. A lot of the research and execution for our feature list was done quickly in collaboration with my product team and our 8 beta partners. (nursing homes testing our product) We took weekly visits out to each nursing home where we ran contextual inquiries, observations and usability testing to make sure we were on the right track. My team and I accomplished a lot in a short time but the following solutions represent my most impactful contributions to the product.

A screenshot of the original candidate list design before I started working on the project.

Revamping the Candidate list

Refining a flashy piece of tech

During contextual inquiries we uncovered that recruiters were using this candidate list to keep track of applicants way more than we thought. Recruiters would come in each morning and add new applicants from their Indeed listing. Then they would check the list displayed below to see if anyone responded to them overnight.

Instead of seeing a list of candidates they actually cared about, recruiters would see anywhere from 10-20 candidates they just texted at the top of their list. This issue made recruiters miss ~5-10 engaged candidates per day.

The original order of this list, newest ➡️ oldest candidates, made it extremely difficult for recruiters to keep track of candidates who either needed to reschedule their interview or leave any feedback on candidates they've recently interviewed. The team originally thought that recruiters would use the "Interviews" tab to manage candidates this way. But seeing recruiters gravitate towards the "candidates" view even though it was difficult to use told us that our perception of their mental model was incorrect. So we thought it was important to make sure we exposed features that let recruiters manage their candidates easily straight from this list. Because if recruiter couldn’t keep track of who they reached out too, then this fancy chatbot that increased applicant volume would be worthless.

The Solution

Highlighting mission critical candidates

The solution we landed on was a filtering system modeled after our recruiters' interview process. We organized candidates being actively considered for a position into chronological buckets based on where they were in the recruitment process. Read more below.

We used the real estate at the top ofthe screen highlighting two different kinds of candidates. Candidates who needed to reschedule and candidates that an HR person has just finished interviewing.

Here is the default state of the candidate list. We only reserved higher contrast colors for when we actually needed to catch a recruiters attention.

Before releasing this feature recruiters would miss, on average, 5 to 6 candidates every day because they had issues scheduling an interview with the chatbot. Highlighting candidates this way reduced missed candidates to nearly 0 with our beta group. We planned to follow up this feature SMS notification post beta. After tapping the filter button a recruiter could hit the highlighted action button right next to the candidate name that would navigate them to a chat window where the recruiter could send an interview time that works for the candidate or leave candidate feedback if their interview time passed.

Here's an example the spec I wrote for engineering. I put this in a hosted sketch file so they can see important details about the Candidate pipline.

Currently wrapping up this case study.

To be continued.

I'm actively working on completing this case study. But because the content for the first section is mostly wrapped up I decided to make this part available to the public. Look out for more to come soon. In the mean time here are a couple of posts on dribbble I made related to this project.