Redesigning Application Management

Context

Both legacy products were built by very different businesses, serving very different customer groups. These were built with varying degrees of user research or customer focus.

 The UK product had been around longest, had the largest engaged user group and had been built based on extensive user research. Whilst the DE product had a much smaller user group, product were not able to talk with customers during the build (due to corporate politics), and had a significantly smaller user group. 
The new version we would design would be built using the more modern DE tech stack which had a React front end.

My process and tools

For research I conducted with remote clients in the UK/Middle East I used:

• ‍MS Teams - to run interviews
• Our live site for testing the legacy product
  
• Invision for basic user testing of the new prototypes


When it came to design I used:

• Whimsical, for online brainstorming and process mapping.
• Sketch & Invision, for Wireframing/UI design and Prototyping.
• Principle, for micro animation work.
• Zeplin, for handover to the dev teams.
  
• Confluence, to document the changes needed, systems and processes within the product

Challenges in this project

User problems

Everyone thinks their recruitment process is unique, however when talking with lots of customers you realised that they are essentially all doing the same thing for the most part. Trying to build a single product that, to start, would not offer any flexibility for users to customise the process like they felt they needed to was a problem to work around. We wanted to design a product that enabled as many of our users as possible in the first release, whilst also ensuring that we have a solid base to iterate on for future themes identified in our research.

From a design process point of view

The biggest challenge for me as a designer, was trying to get our internal stakeholders to recognise who their actual users of this product are, and who the potential market could be.
There was a lot of resistance to change some of the more badly implemented and unused features, that PMs were attached to, yet didn’t see use. This required a high level of stakeholder engagement from myself and the other designer throughout this project. We tackled this issue through conducting plenty of research with users, and creating a narrative around what problems they faced in their day to day work.

User research

Reviewing previous research conducted by previous team members in the UK market and looking into analytics of how users where using the legacy product, gave us a good focus on areas to target in more focused user testing sessions. The DE product team had never done research with users, and was built as an MVP on generic assumptions.



I spent time in Excel to analyse data from the legacy products in order to understand actual user behaviour a bit deeper. This helped to give us focus on the first steps of the project, and where we should prioritise features in the product and others we could completely remove.
‍
From the early stages and throughout the project, I lead the UK research with regular user interviews and testing (all done remotely). For the DE market I relied on a UX Researcher to talk with users due to the language barrier.

Mapping system flows and processes

Using Whimsical as an online ideation and mapping tool to map out the existing structures, processes and flows for the legacy products. Using some of the existing research we were able to map both systems to a new unified structure, and from there map out where the existing features would map to. Culminating with the communications layer out to candidates, and the various trigger points for these both Recruiter generated and system generated.

Layering in communications to the candidate

One feature the DE product had built was a basic email template manager and semi-automated emails to help facilitate communication between the Recruiter and candidates. This focused only on the front end of the process, and actually was fairly intrusive and took recruiters out of the ‘flow’ of their work. We iterated on this feature by providing targeting the areas of the process where recruiters are more likely to do certain activities. For example, at the shortlisted stage, offer to send an asynchronous video screening invitation (a tool we owned that targeted making this part of the recruitment process easier). This mapping of our options for communications and actions can be seen below.

Automating tasks users hate

One of the biggest issues in recruitment for jobseekers is the lack of transparency in the process and a lack of communications from the recruiter. For a large proportion of recruiters there is little perceived value in communicating to candidates they do not have any interest in. Even though most admit that in an ideal world they would signal to these candidates they are unsuccessful.

We made the decision to automate certain comms to the candidate based on the initial recruiter actions. This tested really well with our users, reducing their admin and taking delivery of the ‘bad news’ out of their hands. Whilst the logic was reasonably simple this change required a big leap from the business stakeholders. Ultimately we were able to design a solution that resulted in only the relevant communication being delivered to jobseekers.

By introducing the option to ‘delay’ a rejection email to a candidate, we were able to increase the number of candidates moved within the product.  Our users avoided feeling bad for rejecting new candidates quickly, because the email would only arrive after the specified delay time.  Meaning the candidate is out of the recruiters list, the candidate didn’t get rejected immediately so they felt their application had been considered.  And a win for the business as we got more data on who stayed in the process.

Feature prioritisation

Both legacy products had features that had been ‘bolted on’ with little consideration to the actual task the user was trying to accomplish. Through our interviews and user testing we were able to identify certain areas and pain points, and iterate on these features to reduce or remove these issues.

Helping recruiters stay on top of their workload

Whilst the structure of the product allowed recruiters to move candidates through the various stages of the recruitment process, one issue was staying on top of large groups of candidates. Testing a few variations on how to confirm actions and build in reminding recruiters which candidate needed actions. Feedback from our user testing indicated that recruiters knew they needed to action candidates, they didn’t want to feel like to product was nagging them to move people along, so we adopted more subtle approach.
Our finalised copy reflected language recruiters made when making their notes on paper to capture what they’d done.

Implementing asynchronous video interviews

Whilst I was engaged on this project, Stepstone acquired a company specialising in video interview and wanted a free service version of this integrated into the Applicant Manager product. I worked directly with stakeholders in the video interview team to understand their API and how we might offer an MVP of this into the harmonised platform as well as the legacy products. I created a journey where recruiter could record their questions and then invite candidates (or reuse pre-recorded questions), as well as a means for the recruiter to view the answers.
‍

This work was severely hampered by time, as the business wanted a solution in a fortnight to start building. This meant no real user testing outside of some very basic usability. I was able to deliver this, but the solution and journey is far from ideal. Since going live this feature has really struggled to gain traction with recruiter users on our platform. Partly because it suits high volume recruitment, and our main users on the platform weren't doing this due to the Covid pandemic.

Impact and next steps

The harmonised product is in development and will be launching in the DE market in early 2021. The UK product is in a legacy tech stack and will go live once certain backend services and databases have been migrated. We have been able to implement some of the features that not the UK market that did not require significant technical investment. The auto-rejection and introduction of automated comms to candidates has increased the number of candidates getting a response.



We’ve already identified themes to continue exploring for this product and pushing it forward. This work is ongoing as we look in incorporate some of the more ‘proactive’ candidate sourcing products already on site into the application manager product. This has the potential to make it a one stop product for recruiters; whilst increasing the business opportunity for cross selling.