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.

Hireowl, an intuitive and customizable search tool designed to support synchronized management of job candidates through both interviewer and recruiter interfaces.

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:

Image for post
Image for post
Highlighting key interactions that will likely indicate priority touchpoints.

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.

Image for post
Image for post
Full, fleshed out personas aren’t required, but I think some statement scenarios are helpful for creating interaction flows.

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:

  1. Easy overview of candidates, with fast access to contact information, status, and extended details
  2. Flexible filtering of candidates by necessary use cases (location, status, job, etc.)
  3. 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.

Image for post
Image for post
Recruiter Journey Map
Image for post
Image for post
Interviewer Journey Map

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.

Image for post
Image for post
Interaction flow for two user states. The highlight represents intersections in content.

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:

Image for post
Image for post
Image for post
Image for post
Initial sketches of some of the overarching user flow. Once I got a good idea of how I wanted the information displayed, I moved to Figma.

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:

Image for post
Image for post
Overall wireframing, mid-fi. Excuse my messy trackpad lines!

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.

Image for post
Image for post
The expanded view of a candidate within the dashboard page

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.

Image for post
Image for post
Assigning and scheduling an interview between candidate and interviewer

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).

Image for post
Image for post
Based on pre-set filters, recruiters can customize their search in order to prioritize different groups, depending on their immediate need.

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.

Image for post
Image for post
This sidebar calendar serves as an opt-in function for recruiters to manage times, especially whether both participants have confirmed the time. On the interviewer’s interface, I would plan to put the main focus on this calendar function.

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.

Image for post
Image for post
User flow for Recruiting interface (Excuse the low-quality file)

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.
Image for post
Image for post
A style guide for the Hi-Fi mockup. I specifically focused on communicating progress and status with color.

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.

Image for post
Image for post
Color is used as a progress indicator, especially in extended view.

Recruiter dashboard to Interview Panel

The final result features a pull-out panel for scheduling.

Image for post
Image for post
Image for post
Image for post

Filtering

As explored in the mid-fi, the filtering function is achieved through top-down subnav elements.

Image for post
Image for post

Revisiting my initial goals:

  1. I address the easy overview of candidates function by designing a dashboard interfaces with extended candidate views to offer more details.
  2. 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.
  3. 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.

Written by

Designer. Currently at Asana, previously at Khan Academy. Language + Data + Digital + Print.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store