Job Applicant Tracking System Case Study
Brief: Design a job applicant tracking system that helps companies manage job candidate applications and interviews.
I completed this challenge within a 24 hour timeframe.
Project Scope
This challenge is relatively open-ended, so I set some constraints to design within:
- This application is only available internally to recruiters and interviewers within a company, operating with a company account
- The interface will exist primarily as a web app
- The user is already signed up (no onboarding in prototype)
Research
If I could, I would want to talk to recruiters themselves and see what they are specifically looking for when they need to manage candidates. But for this challenge, some online research into recruiting perspectives had to suffice. Based on three stakeholders (recruiters, interviewers, and to a lesser degree, the candidates themselves), I mapped out some of the intersecting observations for use:
Identifying the Problem
What should this tool ultimately do? The core task is creating a way for recruiters and interviewers to manage all candidates through the application process, and to be in synchronized in their management.
According to the project brief, recruiters need to:
- Find candidates quickly
- View info and details easily
- See the candidate’s stage in the recruiting process, and their score for each stage
I identified some specific needs from recruiters based on desk research as well:
- If they are hiring at a university, recruiters are often looking to prioritize a certain graduation date.
- The first interaction with candidates is most often through email.
- If organizing a power day or another kind of interview day, recruiters need to be able to organize candidates into specific time slots fast to avoid long wait times.
- See cumulative scoring for a candidate who has been through multiple rounds of the process.
- Need to stay on top of their communication with the candidate, including preferred communication methods.
- Respond to inquiries and follow-up as soon as possible.
In this system, I observed that the recruiters take on the role of managing a candidate’s entire journey, while the interviewers contribute specifically to accepting interview assignments and scoring to aid this process.
Interviewer needs, from the project brief:
- What interviews are left to complete/assigned to them
- Submit feedback/scoring for candidates
And the additional needs I identified after desk research:
- The time and location of the interviews
- Access to communication methods with the candidate themselves.
From these identified needs, I whiteboarded a couple specific scenarios to design for.
Proposed Goals
These scenarios made it much easier for me to condense all of these user needs into a specific set of goals. With this web app, I want to create a tool that enables:
- Easy overview of candidates, with fast access to contact information, status, and extended details
- Flexible filtering of candidates by necessary use cases (location, status, job, etc.)
- Synced interview assignments and grading
User Journey
My user journey map is directly informed by the needs of each user type and calibrating them with the scenarios I identified. I started with placing all my identified touch points on sticky notes and playing around with how to best organize the interaction flow.
Because I am specifically addressing 2 user types, the journey maps should be conscious of each other.
A note about filtering: this is a specific instance where, if I had more time, user testing and persona development would be beneficial. I am curious what exactly recruiters need to most often sort by. This would also determine what candidates would appear first on their dashboard. For now, I accounted for the needs I’ve identified in my preliminary research: position, location/school, applicant progress, referral status, and grades.
I simplified the user journeys below. I highlighted the shared touchpoints: these affinities are key for identifying points of potential contact between the two use cases, as well as inform the overall interface design, so I wanted to keep them in mind as I move to designing.
Sketches and Wireframes
Time to build! With sketching and wireframing, I prioritized information architecture and experience decisions that addressed my 3 initial goals. Although I would love to prioritize maximalist visual design and animations, this is a product intended for efficiency, so I made sure to focus on creating a frictionless experience for the recruiter and interviewer to quickly access candidate data and interview scheduling.
I mocked up the entire product in lo-fi wireframes, but I’m going to specifically talk about the interaction for one of the scenarios I fleshed earlier on the whiteboard:
A recruiter is looking to filter candidates by progress and position, and then schedule an interview with one specific candidate.
On paper, I started with an some overarching flows based on my user journey map:
And from here, moved to digital wireframing. Digital prototyping, in all honesty, slowed me down in this time constraint because I constantly kept pushing my prototypes into the “mid-fi” range, which took up time.
After a couple of iterations, the final result for a mid-fi prototype of a recruiter user-flow looked like this:
There are some key decisions I made in this wireframe that I want to dig into a little more.
Extended Candidate Information
Because there’s so much possible data to present at once, I decided to abridge candidate information in the dashboard overview. I assessed what information recruiters would need when comparing to other candidates, versus what they would need when they simply expanded one candidate.
With this function, I aimed to address the need for recruiters to see progress and grading at each status. In this expanded view, the candidate’s information is extended to show a graded progress bar, with linked connections to each employee who is responsible for each stage of the process (I’ve got some color plans, I’ll show later). This way, the platform syncs multiple user inputs into one cumulative interface.
Schedule an Interview
In order to take advantage of the dual-user interface, recruiters are able to schedule interviews directly, based on a candidates reported progress within the system. A function of the extended view, this is a simple hover state that links externally to candidate email and syncs with the interview calendar (below) for both recruiters and interviewers.
Data assumption: I prototyped assuming that this app would sync with Google Calendar, providing the interviewer, Han’s, available times and then sending an email to the candidate, Janet, to confirm.
Filtering Function
While the expanded view allows recruiters to option-in to gaining more information about each candidate, I also wanted to support customized search options within the complete list of applicants. This way, recruiters can enter the app with a specific intention and see applications fast (one main goal established above).
So if recruiters only want to see candidates on located in Pittsburgh (because they’re at Confluence!) or only want to see applicants who have already interviewed, they can filter these results. This is a function in addition to the search bar, in order to facilitate fast comparison of candidates.
Interview Calendar
This function permits recruiters to see an overarching calendar with upcoming assignment.
I didn’t get to the mid-fi wireframing for the interviewer’s perspective, but because interviewers are more concerned with schedules and grading first, I plan to expand this interview calendar into the main dashboard for the interviewer perspective.
Hi-Fi Prototypes
Meet Hireowl.
My system is built on ease-of-use, with playful colors and clean type against light backgrounds intended to be scanned fast and accessed easily.
Additions to Hi-fi prototypes
- a tagging function in order to handle some of the more complicated candidate categorization. The tags also provide a way to do a high-level scan on a bunch of candidates and pick out pieces of metadata.
- Progress color indicators, set with a gradient scale, help me clear up some of the confusing around the mass of graded progress data within the extended candidate view.
- Hyperlink-blue as the action color, to present activated states.
Extended View Revisited
The interviewer dashboard is intended for filtering through applicants within the entire pool, with tags supporting quick scanning. I included a cumulative score, which can be dissected into individual scoring via the candidates “Extended view” profile.
Recruiter dashboard to Interview Panel
The final result features a pull-out panel for scheduling.
Filtering
As explored in the mid-fi, the filtering function is achieved through top-down subnav elements.
Revisiting my initial goals:
- I address the easy overview of candidates function by designing a dashboard interfaces with extended candidate views to offer more details.
- Flexible filtering is a function I also prioritized in the dashboard function. I think to improve it, I would want to include more hover states and indicators of active filters.
- Within the extended candidate view, recruiters can see interview assignments and grading, while the interview scheduler permits recruiter and interviewers to sync up on timing and grading.
Final thoughts and improvements
Overall, Hireowl was a fun challenge to tackle. I enjoy challenges where I get to condense a bunch of content and prioritize readability, legibility, and information retention, so this task played to my passions a little bit. However, I see a lot left to do. I feel like I thought a lot about the perspective of the interviewers and accounted for that use case a lot in my storyboarding and wireframing, but then ran out of time to complete anything mid-fi or hi-fi for their experience.
What I’m still thinking about.
- Competitive analysis: What is out there already, and what’s working?
- Informational hover states: There are a ton of scores and pieces of data attached to each candidate, and there’s only so much information I’d like to fit in a candidate profile without overwhelming the user. I think hover states that provide context into the reason there is a cumulative score or a “referred” tag would be a helpful addition tucked behind one layer of interaction.
- Top down navigation: The interview schedule is a sidebar, and otherwise there isn’t any top-down navigation. I like being minimal, but conducting user interviews would help me determine what options recruiters look for when they would open a pool of candidates and if I’m missing something important.
- Dates of application progress: The candidate overview dashboard currently lacks any data about the time the applicant interviewed or applied. Although this could possibly be solved with information hover states, I think a recruiter would want some up-front awareness of how long the candidate has been in the process.
- Information architecture improvements: Nitpicking, but type hierarchy could be improved, based on user testing, to prioritize top information first.
Quite honestly, I bit off more than I could chew, and now I’m personally invested in solving a bunch of problems that reach beyond my 24 hours. I want to user test, badly, so I could see how to sync up the interaction between interviewers and recruiters. It is this synthesis, I believe, that would distinguish this product, since it would synthesize the role of Google Calendar, email, and scoresheets into one common ground.
On a final note, I am happy with the progress I made on the design system itself. I think that part of keeping humans human and not just data points is treating their information with care and respect, and I aimed for that with clean and playful aesthetic choices.
