Executive Summary

PathMotion is a recruitment tech which allows for a better connection between potential employees and the companies they want to work for. They have many solutions such as a Q&A portal, Live Chats (streaming), the ability to view your potential colleagues, and much more.
The platform was developed without taking design into account, and the codebase used a monolith structure which made it more difficult to fix issues that had become prevelant over the years.
Below you will find the steps taken to come to redesign the platform, the systems put in place to work between design, product, and development, and the rational behind my decisions.

Before & After




One of the main challenges we encountered with PathMotion was its lack of usability and design considerations during its initial development. The focus at that time was to create a tangible product and improve it later, which led to a solution that worked but could have been more optimal. One glaring issue was the need for more consistency between UI elements, resulting in a disjointed user experience. Additionally, several areas caused excessive friction for users, making it nearly impossible for clients to relay information on the platform effectively. While the core idea was promising, the execution fell short and required significant improvements.

Solutions Considered

When analysing PathMotion at its core, it essentially functioned as a social platform. We drew inspiration from successful platforms like Glassdoor, LinkedIn, Reddit, and Quora. However, we recognised that users were increasingly drawn to establishing connections rather than just accessing information. We looked at popular social media interactions on platforms like Instagram, YouTube, and Twitter to address this. We wanted to understand how people gather information and build opinions in those contexts. This insight shaped our approach throughout the process. We aimed to create a space for users to share information and a platform where users and clients felt they could genuinely build relationships.

User Feedback

Throughout our development journey, we actively sought and valued user feedback. It was crucial in understanding our users' pain points and aspirations. Here are some of the insights we received:
"I want to find the information I'm looking for quickly": Users desired an efficient search experience to locate relevant information without hassle.
"I find this information useful; I want to share it with my friends": Users appreciated valuable content on the platform and desired seamless sharing capabilities to help spread the word among their social circles.
"I can find marketing material about companies everywhere; I want the raw information": Users sought authentic, unfiltered information about companies rather than promotional material, emphasising the need for transparency.
"There is too much going on; I just want what I'm looking for": Users felt overwhelmed by the abundance of information and desired a streamlined experience prioritising relevant content based on their specific needs.
"I get lost in the sea of text": Users found it challenging to navigate through lengthy blocks of text, indicating the importance of presenting information in a more digestible and intuitive manner.
By incorporating these valuable user insights into our development process, we aimed to address these concerns and create an improved user experience on PathMotion.


Short-term: Improved search functionality, reduced loading time, and implemented user feedback.
Medium-term: Conducted user and client interviews, gathered feedback and made iterative improvements.
Long-term: Addressed accessibility issues, implemented consistent colour logic, and focused on quality-of-life enhancements.


The most straightforward way of describing PathMotion is a similar offering to Glassdoor. Where it differs, the PathMotion platform allows anyone to understand what it's like to work within a company directly from the employees. You could interact with people within a particular role or company and find general information.
It differed from Glassdoor by giving life to the company and understanding what it's like for the people there—engaging in conversation with those people, as opposed to a short review from (usually) ex-employees.
Here is also where the major issues arose; the platform was released and grew quite rapidly thanks to a good concept and great word-of-mouth, but this only allowed for a bit of time to consider how optimal the experience was for users and clients. Large companies signed on to lengthy contracts, and users found the idea a great way to engage with the companies they wanted to work with.
However, many useability problems within the platform resulted in a meagre retention rate for users, which would affect the quantitative results clients had agreed to, such as; the number of new questions posted within a given month.

Identified Problems

The platform was highly multi-faceted; not only were there two unique platforms for the public and client. The public platform also had different features for the general public and company employees; the breakdown was as follows:
1. Backend platform
2a. Frontend platform (User)
1. Logged in
2. Logged in, but on a different client's career site
3. Logged out
2b. Frontend platform (Company Employee)
1. Employee (answer questions only)
2. Employee - team lead (can manage the answers of anyone below them and direct questions towards them also)
3. Admin (can manage/rewrite all answers and direct any questions to anyone else)
4. Super admin (can answer as someone else, as well as all of the above)
On the outside, this seemed like a minor problem, but the platform was built mostly in HTML & CSS and followed a monolith structure.
In addition, each public-facing implementation had a unique method of interaction which clients could decide, these were; complete URL redirect, pop-up window or iFrame.


The first step was to determine consistent communication channels:
We would use Slack for daily updates.
We used JIRA for anything requiring reference; weekly goals, design direction, etc.
Two check-ins per week (third midweek if urgent). Google Meet calls, usually consisting of myself, the Head of Product and the Head of Frontend, agreeing on what we wanted to complete or had completed.
We used the Kanban system within JIRA for design tasks to prioritise and keep track of everything.
The second step was to decide between the design, tech and product (senior members) and determine which areas to improve within the short, medium and long term.

Short Term

Our first decisions centred around anything that would require little deliberation or review.
User feedback from a feedback button on the platform showed that the most common complaints were around searching for information. Clients had also voiced this concern, as some had substantial information but were very difficult to access.
We used Google Analytics to keep track of most actions on the platform; it was the most accessible tool to implement within client websites too. The analytics showed the time taken to load each page, with the slowest being on manual queries; this meant a user could wait anywhere from 2 to 8 seconds to load results from a search.
The implementation of results also had users type their query (only on the homepage) and load a dropdown with as many results as possible. Two problems here were; scrolling within a long dropdown list was very cumbersome, and the search was a database lookup with little language processing to discern if the result was correct to the query.
The agreement was to use the rest of the first quarter to correct these problems; we created a dedicated search results page. If a user pressed 'ENTER', the results dropdown was restricted to only five results. We tested different search technologies and landed on Meilisearch, as it provided the best features for our requirements and budget.
We launched one week before the end of March, and by April 5th, we had seen a 500% increase in the number of people completing the search funnel (activate the search field and enter a resulting page from either the dropdown or search page).
We also improved search result time to 100-150 milliseconds on average.

Medium term

Over the medium term, I decided we needed to speak to our clients and users. It was great receiving constant feedback, but it helped me to be able to talk directly and empathise with people.
For this, I suggested we use site access data to find users who posted multiple times to a client's board and users who returned to the PathMotion-integrated pages more than eight times in 2 weeks or if a user activated search numerous times within three sessions.
If a user met either of those three criteria, they would trigger a message from the feedback button asking if they wanted to help us make the platform better. If a user had an account, they would receive an email given that they matched the criteria also. We also sent out one email to all registered users.
In total, we received over 100 people who agreed to take part in the research. Of them, only 40 gave us their details to connect.
They were further narrowed to 25 once we sent questionnaires to determine user motivations.
We (myself and the Head of Product) interviewed each of the 25 users, splitting them between the two of us, I led 13 interviews, and he led 12.
We asked users if they would agree to the recording of our call, along with use taking notes throughout. The interview process consisted of users completing tasks on the website and speaking freely about how they feel or what they're thinking.
Once completed, users were asked about their experience, whether the website behaved how they thought it would/should, their frustrations, etc. This feedback allowed us to gain a qualitative understanding of the experience.
Finally, users could spend 10-15 minutes freely speaking about their thoughts, suggestions, what they like about the platform or other platforms, etc. So long as it was in the interview context, users could speak about anything they wanted.
We sent any users who seemed highly engaged during the interview process an email one week later to ask if they would like to stay on board during our redesign process. 10 users agreed to stay with us. We would contact them every 6-8 weeks for a short call to present design prototypes.
For client calls, there was less of a prospecting phase. Our client success team would regularly speak to different clients to onboard new employees or run workshops.
Initially, I would sit on those calls to understand how the clients think. As designs developed and we presented prototypes to clients, I had 20-30 minutes during calls to show the designs and compare and explain the reasoning behind changes or solutions.
Issues during these calls pertained to most client meetings addressed HR or sales team members, occasionally tech and only once design, this meant certain concepts would fly over the heads of the client employees, and our motivations for the solutions didn't always make sense to clients.
I had to rethink my presentation style significantly and "relearn", a skill I had primarily followed in the same manner throughout my career. Ultimately this was a great lesson, as the client employees weren't internal stakeholders and weren't users, which meant they rarely saw any individual gain from being on the platform. It was usually a mandatory action to complete by their line managers. Learning to speak and present ideas to people who didn't care was a great challenge and learning experience.
In the end, I was able to gather information such as; wanting the ability to interact with users like it was social media or wanting to create reference threads for questions, such as if a colleague replied to a comment/question and you could build on it within a thread as opposed to making an individual comment.

Long Term

These goals were quality of life. They were necessary improvements to the platform but nothing requiring an all-nighter for anyone within the team to complete. As such, less data was going into these changes from within the platform itself, but a lot from my understanding of useability and suggestions we received internally and externally.
PathMotion initially allowed clients to choose up to 10 colours for their site integration. There was some basic mapping of the colours, but it needed to be made clear in the UI. Furthermore, many UI elements would derive colours from determined colours by reducing opacity or decreasing/increasing darkness.
This lead to clients having anything from impossible-to-read pages, such as EY with yellow text on a white background. Or websites that looked like they fell out of a Skittles packet.
The team members in charge of setting up the PathMotion websites for clients were usually not developers or designers, so it wasn't fair to expect them to take the time to work out the colour science.
In addition to the above, especially seen in clients like EY, accessibility was a massive downside of the platform.
The first requirement was determining a 'colour logic' for all clients. One which allowed them to brand their integrations while still controlling how much freedom they had, both to keep the platform accessible and to ensure it was still PathMotion and not just another page within the Coca-Cola website.
The second requirement was to complete two WCAG assessments throughout the public-facing platform; one before any major redesign and one after. Ideally, AA at least and AAA in as many areas as possible. Accessing and correcting was a long process as some of the criteria required the website to exist on a staging platform to test in actual use; as such, it was an ongoing project.
The 'colour logic' decided upon was to allow clients to choose a single 'main colour', usually the brand colour. These would display throughout highlighted areas of the platform; CTAs, active states, areas of note, etc. A secondary colour for accented elements, such as; icons/icon backgrounds, section backgrounds, etc.
Everything else would be a variation on black or white. To prevent the same issue as EY, we also used an API to detect anywhere text would be inaccessible due to background colour and change it to the opposite colour; black to white, white to black.
On the backend platform, we created a dedicated page to show clients where their colours would map and explained any changes that would happen automatically and why.
We added icons to the platform's interactive or non-question components to ensure anyone visually impaired could understand the website. We used the material icon library, with some custom icons if they didn't exist.


When my time at PathMotion ended, we had 74 clients signed, with two more completing their contracts.
Site speed had increased drastically; search results initially took up to 8 seconds to appear and were improved to less than 1 second. Combined with UX and visual improvements, quantitative analysis showed users were staying on the site much longer; 5 minutes on average increased to 15 minutes, and signups had more than doubled.
I set up a design process that could be repeated with future hires and team expansions, negating the need to reimplement work processes.