Applicant manager

This is an area of the back office that recruiters use to manage their applications.
It’s extremely outdated, not responsive, badly designed and cumbersome. it was necessary to revamp and create a modern framework for a new and improved responsive solution for all verticals.

Job Advert Manager page is also old, unresponsive and hard to use but still get 54,000 visits a week. The next page in the journey is the Applicant Management page but it only saw 15,000 visits a week. Finally, the Applicant Details page and the most important page in the journey gets 4,000 a week. This was a clear indicator that something was wrong and offered an obvious opportunity for improvement. Thus, our main KPI was retention of existing users.

The Task

  • Understand who our users are and what they need
  • Understand user journeys, touch points and possible issues with changing so much of the platform at once
  • Set up a research plan and timeline
  • Discovery and design
  • Continuous user, stakeholder feedback sessions
  • Work directly with designer and scrum team during build to mitigate errors
Job ad manager
List of applicants in applicant manager
Applicant details

Discovery

We started by understanding what we currently have onsite and how it is used. I used a tool called Mouseflow to see how current users interact with the pages. By utilising screen recordings and heat maps, it’s quick and easy to build up an understanding of user behaviour.

Heat maps show whats being used on the page most

I discovered the checkboxes are receiving a high number of clicks. Roughly 21.95% of visitors are clicking a checkbox. The number of checkbox clicks didn’t match the number of download all selected cv clicks, which was significantly lower at 1.95%. From this we were came to a few hypothesis, which includes:

Hypothesis 1:
Recruiters are using the checkboxes as a marking system and not for the bulk actions. Perhaps using the tabs or a new browser window to view an applicant and keeping record of view/actions in another

Hypothesis 2:
Recruiters don’t want/need to bulk download CVs

Hypothesis 3:
Recruiters are not aware it is possible to do bulk actions, which would be a labelling problem)

Hypothesis 4:
Recruiters are expecting something else to happen when they click the checkboxes

Next was understanding the routes to and from the pages. This was done with Adobe analytics. We discovered that most users land directly on the page from their email notifications, this was something that hadn’t been expected.

Whilst we needed to understand routes in, we also needed to know the main user journeys and task flows. It’s important in a large project like this that we know exactly what the user will be interacting with so that we can mitigate any dead links or worst of all creating issues around the user’s primary journey.

We then needed to work out who the new offering would be for. We did this by undertaking a number of user group focus sessions. These enabled us to get a quick overview of the qualitative aspects of the site whilst getting a better understanding of our users needs. Once we had established a primary user group, namely small/mid size enterprises, we then performed more intense in-depth interviews (IDI).

Using a script whilst interviewing keeps you on track and helps to negate leading questions.
Here I created a kind of hybrid map in order to visualise what we're doing for stakeholders.

Creating a group of personas is a great way to keep design teams, scrum teams and stakeholders on the same page with regard to who you are all doing the work for. Quick proto-personas are perfect for UX teams but higher fidelity always works best for stakeholders and those that don’t understand the UCD approach.

Next steps were to conceptualise the new user experience. I worked through a number of concepts before settling on a simple design paradigm that our target users would understand easily – the email inbox. The hypothesis was that by using a design language that was already second nature we could onboard existing and new users quickly.

User journeys show what pages the user will hit along an identified tasks route to completion as well as success and pain points.
Task flows help to identify what your users do and the decisions they make along the way.
Working low fidelity and quickly is the key to covering as many concept as possible. It's important to fail quickly at this stage.
Once main concept is decided its time to make basic wireframes and sense test them with stakeholders. Its still possible to change our minds at this stage and not cause major issues.

Now that the concept is agreed it’s time to do in-depth testing with our primary user groups. Depending on budget this can be done remotely or in person. It’s often advantageous to do testing in the place that the user feels most at home, it helps to get a more normalised response.

After gathering feedback it’s time to assess the UX and make the changes required. We did this whilst moving to a higher fidelity. This is a great stage to test micro-interactions and any key design aspects that will affect the UX.

We implemented a lazy load feature after discovering users felt that content wasn’t available to them when it loaded slowly from our servers.

The solution​

Once the designs were complete for all verticals and all view points it was time to complete build and start an alpha release to small numbers of sympathetic users. We used trusted clients and our original testers to give feedback when using the product in the real world. This helped to clear up any teething issues in a safer environment.

Results

It took more than a year to release version one of the responsive applicant manager. Straight after release we saw a sharp upturn in people using the platform and a huge increase in those using on mobile and tablet, which was a primary KPI. The trend continued as time past and this is the real success. When released we sent out an email campaign and talked to clients about the new back office which accounted for the quick upturn, but the fact they stayed and continued to use it shows we made a quality, usable product.

 

Key takeaways

Before responsive applicant manager was released we saw approximately 60,000 visits on desktop to the applicant manager. After the release of the new responsive applicant manager we saw the following results:

130,000 visits per month
After the second month of release

365,000 visits per month
on desktop July the year after

508%
Total increase in 15 months

Mobile usage saw similar gains but on a smaller scale. Long term analysis showed that most recruiters managing their jobs and applicants at their desks during working hours. We saw an increase in mobile usage during morning and evening commutes. Tablet usage went up in the evenings this suggests users sat in the evenings on the couch assessing candidates before work the next day.