Prior to this piece of work, list of adverts for different recruitment campaigns was the homepage (image below).

The challenge

Google Analytics started to show us a common pattern: the product (called Vacancy Filler) had a few power users from HR teams in a company doing a lot of heavy-admin work and very little engagement from senior HR staff members and hiring managers.
We had realised the product was very difficult to use for the users who wanted to keep an eye on multiple recruitment campaigns without delving too deeply into each campaign (doing health check)
Our clients had many processes happening away from our product to make our product fit in their processes; e.g. areas related to keeping other team members updated
For some use cases, we knew the product was very straight forward and easy to use. For many others, it would take a lot of user's time to gather all the information required and communicate it with the right people.

To simply put it, we knew the product needed to be easier to use.

The approach

Finding out the exact problems

I championed installing Hotjar on our product to observe patterns of usage. I spent many hours watching to...

get closer to how users used our products and observe their behaviour on it
identify patterns of browsing and usage
understand user flows and the 'why' behind these flows (arguably the most important factor)

This helped me and the rest of the team to see what info a user was trying to access, what happened next, why they chose a certain path and not the other, the why behind some unusual pattern of usage, understand flows of heavy-duty users, understand flows of once-a-month type user, what actions they took after going through certain flows.

An example screenshot of Hotjar helping me to observe a user's pattern of usage

Making sense of things

Gradually some distinctive behaviours and patterns of usage emerged. By combining our understanding of our customer based using the 3 sources below 👇, I led the exercise of categorising the behaviours and distilling them down. We ended up with 4 scenario-based personas.

the observed patterns of usage & behaviours on Hotjar
previous conversations with customers (on how they would go about doing their job using our product and their requirements / needs)
how their organisation had adopted our product in their processes and their ways of working

Personas

These 4 personas were to illustrate the distinct different behaviours people would show going through their recruitment process on our product.

to make it easier for us to design for these personas, we picked names for them. We also nicknamed each pattern of behaviour to make them more memorable.

In many whiteboarding sessions, we tried to work out how the recruitment processes and patterns of behaviours we saw corresponded to one another.

👤

Jenna – with "maintenance" behaviour Cares about high level overview & business objectives, KPI-driven, decision maker on recruitment processes, engages with senior stakeholder Scenario Jenna wants to view number of candidates at different steps of the recruitment pipeline under different recruitment officers managing multiple campaigns. She wants to make sure the process is running well and if there are any blockages, she can find out on time so that she can support the team under her leadership to elevate problems.

👤

Amy – with "window shopping" behaviour Doesn't care about individuals on a personal level at this point, more about executing recruitment process in the best way possible, cares about candidates going through the pipeline in the best way possible, turns longlists to shortlists Scenario Amy works in a retail company. She wants to view CVs / application forms of new applicants (or those at other initial stages of a recruitment process) within the adverts she looks after. She aims to shortlist candidates faster & more accurately. She looks after 27 recruitment campaign across 9 retails stores that she's responsible for.

👤

Davina – with "personal shopping" behaviour Gets to know and looks after candidates individually and builds a rapport with them, looks after specific types of job vacancies, Scenario 1 Davina wants to track the progress of the candidates who are reviewed by the hiring manager (or those candidates who've gone past a certain stage in the recruitment process). Scenario 2 She looks after candidates at the final stages of offering jobs to them for 10 vacancies. Scenario 3 She moves a candidate's application, who recently attended an interview, to the next step (either progressing to the next stage or rejection)

👤

Rob – with "hiring manager" behaviour Doesn't want to be login to the system unless he has to.

Solution finding

Working with a business analyst, another designer and a software architect, we came up with ideas on how we could optimise the product so that users could find what they were looking for more effectively.

Having a 'dashboard' as a starting point for customer journeys gradually became an obvious solution (in term of effort and impact). This dashboard had many different modules which could be added based on functions and features used by different users.

We also identified some gaps between user needs and product's capabilities and features which informed the product strategy (an example is an on-site notification system to make users aware of important changes made by colleagues impacting hiring campaigns)

One of the many whiteboarding sessions to explore ways to facilitate user journeys better on our product.

Low-fidelity prototyping

Using lo-fi prototype, I iterated on the design 5 times based on internal feedback. This was to get to a rough structure for Dashboard.

Which widget to build

We prioritised which widgets to work on based on this 2x2 matrix – value versus risk (level of experimentation involved)

Designing widgets

Then I started to go into more details on the interactions and catering for difference use cases.

Feedback from colleagues (internal stakeholders)

I'd run sessions by going through the prototypes with stakeholders and gathered feedback and ideas from them. Below is an example of it:

The outcome

Dashboard was rolled out gradually to some beta users and after very positive feedback and improvements, it became available as a standard part of the product.