About the project
The driving force behind building Searchie was to fix the traditional recruitment process which heavily relied on a fixed group of recruiters who matched candidates according to skills, as opposed to cultural fit in an organisation, early in the recruitment process.
To clarify, recruiters and employers are not always the same.
While recruiters can be an in-house team of people who work for your company and find suitable candidates, they are often freelancers or contractors who work for multiple companies and keep nominating candidates whom they think are suitable for required roles. They are usually paid a one-time fee based on the salary of the candidate they nominated.
Getting back to the project at hand, here’s how Searchie works:
Employers tell us about their organisation’s culture and skill requirements
The job is then posted to our global network of freelance recruiters
Our recruiters will source candidates who match your skill requirements
Sarah, our AI based chatbot, will evaluate candidates to match your culture and needs
Our platform shows you the top candidates based on the requirements you specified previously
You can continue to schedule interviews
Your job role is filled in days!
The red are the stages where organisations usually start considering the ‘intangibles’ or the cultural fit of an individual. The blue is the stage which sets Searchie apart.
The main differences are the introduction of cultural and personality mapping early in the recruitment cycle and using a network of freelance recruiters around the world to source candidates. This not only saves a lot of money by weeding out unfit candidates early in the recruitment process but also increases the reach of the process by overcoming geographical and financial constraints.
The goal was to build a platform where employers could post jobs, recruiters could work on those jobs by nominating candidates, and candidates could get screened by our AI chatbot, Sarah.
I was brought in as a UX Engineer to design and develop the platform as part of a small team. My work involved working closely with recruiters and candidates to understand the recruitment industry and design a solution tailored to the needs of organisation of all sizes.
From card sorting to picking colour palettes and from wire-framing to actual code, I was responsible for ensuring that the platform delivered what it promised while keeping the experience consistently intuitive.
I spent a sizeable part of my time on researching and understanding the target audience. One of the greatest advantages I had during this project was accessibility to the target audience. Since I was working in the innovation wing of a traditional recruitment firm, I had constant access to recruiters who had been in the industry for almost a decade and knew what worked for them and what didn’t.
Like every other project, I started by defining the problem that I wanted to solve, the issues with existing solutions, and the stakeholders in the process.
After sifting through hundreds of web results and talking to tens of people, I had a fair idea of the playing field. Startups like Hundred5, Harver, and FinalStage were building great products but none of them were actually using psychometric analysis to determine the suitability of a candidate to the organisation hiring for that role. This was Searchie’s USP.
After talking to my product manager and the rest of the team, we concluded that the stakeholders were as follows:
Organisations hiring employees
Recruiters sourcing candidates
Employees being hired
Next up was time to crunch some data.
I sent out surveys to multiple startups in the MENA region asking them to rate how important cultural fit was to them when assessing a candidate. I also asked them if cultural fit was something they put emphasis on when hiring.
The results were intriguing but did not contradict pre-existing surveys on the internet:
While the vast majority of organisations agreed that cultural fit was important to them, only about half of them actually had a structured way to analyse the intangibles.
Next, I took to the internet to find out how most organisations around the world actually measure cultural fit.
Data showed that interviews were by far the most common way of figuring out whether a candidate was a match for what the organisation was looking for. This was almost halfway through the recruitment process! Questionnaires were the second most popular method where a variety of tests were employed, from the Big Five to Occupational Interest Inventories and from DISC Profiling to other situational judgement tests. The major problem here was that very few of these tests were standardised and almost none were tailored to organisations. This left recruiters with a very vague sense of what a candidate’s personality was like and was often more confusing than helpful.
Thus, these surveys helped us understand our problem statement much better with a clear vision of how to proceed.
During this project I didn’t have to create personas since I had access to actual people part of a recruitment firm.
This helped the team validate design decisions within minutes of making them and proved to be extremely efficient in a fast-paced working environment.
While taking to them, we gathered some information about platforms which they used as part of their workflow:
For finding new candidates, LinkedIn and Indeed were the two most popular places.
ATS or Applicant Tracking Systems were used to monitor stages of the recruitment process different candidates were at, since recruiters worked on 10+ roles at once.
Email was a standard for communication with candidates and organisations.
It was time to start laying out the structure of the platform.
Three main ‘streams’ were created to cater to our stakeholders—employers, recruiters, and candidates. We made a comprehensive list of all possible actions and touchpoints our platform would involve. From the signup flow to the scheduling of interviews, we sorted cards and mapped the user’s journey for all three streams.
We tried to simplify the onboarding process by letting recruiters and employers signup with LinkedIn and Indeed. We came up with a way to allow candidates to simply upload their CVs to our platform after which skills and experience would automatically be parsed into fields which the user could then edit.
Over the course of a few days, we ironed out the flow of the platform and decided to start building it.
This project was supposed to be just a couple weeks long at first and so I immediately got down to the details of each part rather than thinking about the project broadly. I started brainstorming and designing in the browser simply because of the time constraint.
I quickly realised that this wasn’t a viable option since I wasn’t thinking about usability at all, which was contrary to the purpose of this project.
After talking to my product manager, I backed up a little and started approaching it from a broader perspective.
First off, I spent some time looking at all the software which recruiters and employers use on a daily basis in order to see what worked and what didn’t.
Something interesting which I noticed with most enterprise applications was a static navbar for top-level navigation and a dynamic horizontal navbar for navigation within pages of the current state. This made sense from a usability perspective since it provided the user with a clear sense of hierarchy and established a rather simple mental model of the system.
We finally settled upon a style with icons on the left for main functions like accessing the dashboard, list of candidates, roles, billing, and settings. The internal pages were fairly simple with a piece of text on top which read the name of the page the user was currently on along with a horizontal menu for toggling pages.
Now all of this seemed really good until we ran into our first roadblock. When testing with some recruiters in our office we realised that they spent too much time figuring out what the icons on the left meant instead of actually using the platform. Since a lot of them came from different backgrounds, their outlook towards what I as a designer perceived as ‘understood’ was not the same at all. This needed to be fixed.
The solution was simple — add a piece of text beneath each icon describing what it meant.
After fixing the navigation, we started targeting the dashboard screen which was supposed to be a bird’s eye view of everything that was going on. It was meant to give key information at a glance.
We went with a large typeface for statistics along with a small colour-coded arrow which showed the trend from the past week. Alongside statistics, we also chose to show a graph in order to visually represent how a recruiter or employer was matching up to their goals. Later, we also integrated a small panel at the bottom which showed a recruiter or employer the ‘hottest’ candidates for open roles right now — those who were the best match for the job.
While I’m not at liberty to talk about how our algorithms sorted the best suited candidates, beta testing later revealed that the ‘hottest’ candidates indeed had a 90% job satisfaction rating on average.
Most of the other pages were simple forms with lots and lots of question fields. This was a really data-heavy project and we would later run into some issues related to presentation of information.
Once we completed laying out most of the components, it was time to start building them.
When I start designing and developing the screens, I ensured that each component being built was reusable which proved to be really efficient since we were using AngularJS as our front-end framework. I used Semantic UI as the library of choice since it offered a lot of what we needed without being too slow on weaker internet connections.
Choosing the colour palette for this project was slightly tricky. Since the logo of the company was already red, I was expected to use that for most of the application. I knew that having a bright red throughout the application would not have a positive impact on the psychology of the user since it is considered a panic-inducing colour.
So we chose a warmer pastel red along with a navy blue accent. This was similar to a lot of ATS platforms which recruiters were used to.
As the project moved along, everyone was pretty happy with the results. We were building the product at lightning speed and completed coding most of the components in just over a week. It was my first time formally using Agile to manage a project.
On a side note, the technical part of the AI chatbot was still being worked on during this process so I did not have the opportunity to design the chat interface specifically.
Here is what the platform looked like:
A vey interesting challenge came up when we decided to think of a way to simplify how an organisation fills in the details of the job it is creating. Since there were about 50 different questions which could not be avoided, we decided to reveal information gradually.
We grouped input fields according to the type of information they were asking for and then divided these groups into separate pages or tabs.
This is what the navigation between form pages looked like:
And this is what a single form page looked like:
This ensured that the person entering the information did not get overwhelmed by the sheer number of input fields on the screen and also helped navigation between different sets of inputs.
Soon, it was time to design a creative type of form—one which asks an organisation for the personality type it is looking for. The need for this to be creative was that very often organisations did not have a set list of attributes they were looking for in a candidate.
The team came up with a solution to give the user a dropdown with a list of adjectives as part of a paragraph. This way it wouldn’t just be a random arrangement of adjectives that the user would be adding to the job. Also, only one sentence would be visible at a time so that user could remain focussed on entering an accurate value while all the other sentences would be ‘dimmed’.
Here’s a demo:
It was coming along well until we hit our next major roadblock.
We were using bar charts to represent different personality traits because our algorithm simply returned values for each of them. For us it was simply a matter of plotting those values against the personality trait. This is what our initial solution looked like:
The problem with this was that no one really understood what any of these graphs meant. Sure, I can infer from the above graph that the person in question has a high ‘emotional range’ and is rated low on ‘agreeableness’. But what do these words translate to in a real life environment?
After spending some time talking to our target audience and people within our team, we came to a conclusion: Everyday language is the simplest way to convey thoughts.
We spent a few days working on an NLP model which could help translate these values into coherent sentences.
This made a lot of sense from a UX perspective—the recruiters and employers had a paragraph which they could read and infer how the candidate would behave in a work environment. The parts highlighted in green are the traits of the person which match the requirements of the organisation hiring and the parts in red are the ones which oppose them.
After ironing out some other minor usability bugs, the product ready to ship and run beta tests on.
This was one of the most rewarding projects I have worked on till date in terms of learning new things and thinking at scale. It was exciting to build a product which used cutting-edge technology to solve a real world problem and make an impact on organisations of all sizes.
While what I designed in a few weeks might not even be close to the perfect solution, it felt like a step in the right direction and was a great learning experience which gave me a broader perspective of the variables involved in shaping great products.
Over the course of this project, I came to realise that user experience is not much more than common sense and everyday psychology applied to design.