Designing for online recruitment: A product case study
Whilst working at Mindera, I lead the re-design and launch of a new web app for Jam Pan, an online recruitment company. Here’s the whole damn story (warts and all).
Disclaimer: I worked on an amazingly talented, cross-functional team with Mindera and Jam Pan. Everything in this case study is from my perspective and what I learned. All this work was only possible with the blood, sweat, and tears of my team. Love ya ✌️
Finding the best person for the job
Speak to any business owner and they’ll say that hiring the right talent is one of those ‘make or break’ business skills. When you’re hiring, there’s lots of pressure to get it right. You’re time poor and over-worked (or you wouldn’t be hiring). You’re skipping lunch to go through thousands of CVs’. Bigger companies have a way around this. They outsource to recruiters. People who understand what the right candidate needs less than your own employees do. You now have to go through more candidates, but this time they are ones you haven’t vetted.
This is some Dave Wood, founder of Jam Pan, saw when he worked in big companies. He saw that the void that recruitment agencies were filling lacked the understanding of what the candidate needed and didn’t really solve the problem of taking away the legwork of hiring. Also, they often just pulled from a spreadsheet of candidates who used the ‘right buzzwords’. When you were getting a recommendation from a recruiter, they often had no clue who that person was. A lot of online platforms promised good talent but fell short on really creating that relationship and trust that companies needed.
That’s why he created Jam Pan, a company that took the pain of hiring off companies but also provided real relationships between talent and the companies wanting to hire them. If Jam Pan recommended you a candidate, it was very likely that Dave would swear by them. Jam Pan created an online portal where candidates could register their interest in being hired and Dave’s clients post jobs for candidates to browse.
Jam Pan approached Mindera, a software consultancy, where I was working as they needed help with their online portal. As Jam Pan grew their client base, they wanted to keep that 1–2–1 relationship they had with both suppliers (freelancers, contractors, small agencies) and their clients, the businesses looking to hire. This was taking its toll on Tori and Julia, two senior members of Jam Pans’ customer service team. They were working with a skeleton staff to field all the calls and foster those relationships between clients and suppliers. This was a job that the online portal was supposed to alleviate. Both suppliers and clients weren’t using the online portal. That’s where we came in.
Asking the right questions
Before we kicked off the project, it was important we understood what our goal was. We know that we wanted to revitalize the original goal for the online portal; taking the load off customer services and let users use the site instead. This would save the company a lot of money that is currently directed to support but also free up senior members like Tori and Julia to grow the business. But how do we measure that? Mita, the product owner, and I discussed this at a pre-kickoff call with Jam Pan. We settled on increasing activation for current suppliers, new sign-ups for clients and re-purposing the pricing model for Jam Pan to include a basic service (access to the supplier base on the portal) and a premium service (dedicated account manager). This was because that on-call relationship had already been far too established for some clients and the concern from JP was if we removed that too quickly they would lose that trust.
Speaking to customers
Alongside speaking to JP, I conducted some research sessions with their key client and supplier base. I spoke to both suppliers and clients of Jam Pan, but also their customer service reps to ask them what customers’ complaints were about the portal and why they didn’t use it. We didn’t have a full-time researcher nor the budget to get one so I lead our research sessions alongside Tori. Having a member of the Jam Pan team there helped as it allowed us to be more comfortable with the participants. At first, I was skeptical that the participants might self-censor their critique but, because of their strong relationship, they were surprisingly friendly and frank discussions. I used the interview model canvas from ‘Running Lean’. As well as speaking to customers, we also ran some surveys across their customer base and with segmented potential customers to widen our data pool.
What we found that one of the biggest reasons they were a customer of Jam Pan was because they understood the pains and frustrations that they went through, as both suppliers and clients. Clients were more keen to have Jam Pan work everything and some were willing to have a more premium account manager service. A lot of suppliers, however, wanted to use the site, as many of them use Indeed & Freelancers.com as well but felt the experience didn’t match up to what they got on the phone. Almost all of them gave up on filling in the huge amount of information needed for their profiles to just call up. Another feature was ‘bidding for jobs’. It wasn’t very popular and was really confusing for users to understand. It also bruised their egos slightly as they were all (quite rightly) proud of their expertise and didn’t want to be in a bidding war.
Using our customer research data and doing an evaluation of the existing product with the engineering team we highlighted three major parts that we could focus on to achieve our goal of bringing great user experience to clients and suppliers, as well as taking the load of JP. The three parts broke down into three phases of sprints we were going to run.
Phase 1 — would concern itself with improving the quality of the engineering as well as the UX and visual design to remove the frustrations that suppliers were feeling. We would focus on reducing the amount of upfront work for signups, onboarding users more effectively and keeping them engaged. We would also look at an alternative to our ‘bid for jobs’ process. As well as this, we would give the portal a lick of paint to help attract potential new users and re-energize and excite apathetic ones.
Phase 2 — would be focused on reliving the effort on Jam Pan. By creating a system where we would empower the portal to handle most of the client-supplier relationship. Alongside this, we would build a new backend system to manage all this new data. After this phase, we would pilot the new portal to a selected user base to squash any bugs and get immediate feedback.
Phase 3 — would be releasing our product onto the market and planning a roadmap to include requested features such as accounts system integration. As well as improving the fit and finish of the portal and their marketing site.
Working with JP and Mindera, we worked in Agile/Scrum sprints. These three phases would be planned with all the production work being divided into two-week sprints. My initial concern was if we jumped straight into production; how would design keep ahead of engineering and how would we make time to prototype and test the parts of the product that were new to us?
There were key sections of the portal that were extremely frustrating and ultimate dead-ended the app for users. But we didn’t have a clear idea of how to solve them yet. We needed a process that allowed us time to research, prototype and test new ideas quickly that didn’t block any of the sprints in the phases.
We decided to go use a process called ‘Lean UX’. One of the big advantages of working like this is it removes much of the “I don’t think that’s a good idea” and political infighting from the UX design process. Every idea is going to be tested and the evidence criteria clearly determined. This fits perfectly in our production process where we had a small team that needed to move fast.
Our version of the Lean UX
Lean UX is something I was comfortable with and had used on other Agile projects. I think it’s a great way to approach UX. It works especially well when combined with continuous research or kickoff research before a project. I think combining the two into something similar to a Design Sprint, in the Google model, would be the masterclass for a project like this but we had already planned the sprints before I was involved fully to set the design process. Lean UX worked really well and throughout the big bets in designing the new portal, that approach really helped not just me — but JP to see where their customers were struggling rather than just hear ad hoc through a feedback form.
Every time we felt we were making a big assumption, we prototyped our solution and tested it with 5 customers. As Jam Pan’s customers were spread out over the EU, we would set up a Google Hangouts call that we would record. Participants would share their screen and answer a few initial discovery questions. They would then perform certain tasks, whilst myself, product manager Mita and head of customer services at Jam Pan would watch and record notes.
Afterward, we collated our feedback and identified trends with our user group. We would use these findings to validate (or invalidate) our product decisions.
What we did
As our focus for Phase 1 was to re-engineer the platform so we could remove the frustrations and barriers that new & existing suppliers and clients were facing with the platform — I thought a good place to start the production work would be to work out what parts of the product users struggled with the most and plan rounds of research and testing around those first. Alongside this, the developers expressed a wish to make the codebase a lot more scalable. As our development team was staffed by two FE and one BE, resources were tight.
Our UI Kit & Styleguide
Our FE was to be built in React and me and the lead developer, Gabe, decided to use Material UI (A React UI library based on Google’s Material Design). This offered both tested and performance-ready components but with a good deal of theming capability. Anything not included in this library, we would prototype in Code Sandbox together and test individually. To make sure we could move at speed, I started by creating tokens, elements & foundational components we know we would need. These included; typography styles, colours, spacing sets, shape styles, buttons, cards, headers to name a few. This gave our development team some UI to focus on, along with their architecture setup, whilst I worked with our product owner to plan and conduct research and prototyping on the key areas of uncertainty in the app.
New User Signup
One of the key areas we felt needed a change was our entry point. The sign-up page not only was seeing a lot of ‘drop off’ but also requested a huge amount of information, which users said caused them to either half-fill their profile or abandon it completely. Whilst our focus was on reducing the burden of existing user struggles, we wanted to nip the problem in the bud by re-thinking our sign up flow. This would also feed into the onboarding as when we studied JP’s data, most users hadn’t fully completed their profiles. This meant they were missing out on job offers as both clients and JP couldn’t see if they were a good match.
We broke the onboarding into three parts; Soft-sign up (above) which would ask for the minimal information needed to create an account. Filling out your profile parts 1 and 2 (more about those later). The soft-sign up asked for just your name, email, and password. A clear and uncluttered UI allowed for a calmer experience, allowing the user to focus in on what they were doing. We removed any sales messages or chrome from the existing design and replaced it with the form and some lead copy. It wasn’t clear to users on JP’s original UI that the account was free and what the benefit of signing up was. Most of these services are paid services so I believed it was an important hook at this stage in their sales funnel to show the benefit of the platform as well as it’s 0 costs of investment.
Splitting the sign-up into two sections really made it easier for new users to invest time. But those users already signed up needed to fill out information if they were going to be available to clients. We decided to test different lengths of forms; ranging from 1 to 5 steps. We found that 2 steps, broken into information about you and then information about your work made the most sense to users. It was important we didn’t make too many fields mandatory as we found, it was more important to users that they could skip things for now (such as knowing their VAT number or registered business address) and come back later rather than having to answers every question. We added the ability to save this form for later.
Creating your profile
The second part of the form (pictured above) dealt with uploading your portfolio and work information. For clients to find suppliers through Jam Pan, JP’s original system required cataloging everyone in pre-defined categories. They didn’t really have a search function so all the suppliers needed to be put in groups. We tested this system as we were told it was a big pain point from most users. We found that literally 0 of our users felt the categories identified them and their work. Also that when users needed to upload their work to their relative skills, the would need to complete this multiple times. This was because, how the system was built, it required you to add work per skill. Most projects spanned multiple skills, meaning that work you did for a company where you did design, illustration, copywriting and development needed to be uploaded four times.
We changed this so each project you uploaded was now ‘tagged’ with certain, more broader categories. The categorization system JP used was still there, behind the scenes, as we didn’t have scope to rebuild their internal system. But to users, they were presented with more familiar, broader terms that they could attach on a per-project basis. This would feed into their ‘Skills’ category where they could set a generalized rate for that skillset that would be visible to potential clients.
Onboarding new users
Another big frustration for users just getting Jam Pan out of the box was understanding where to go and what to do. Most users never filled out there profile fully, but they weren’t informed that this would a) decrease their likelihood of being found by clients b) not give them the ability to show work and grow their profile. We decided to change that. Using a method of ‘Progressive Disclosure’ we unveiled more features of the app every time the user filled out more of their profile. It was a basic reward scheme so that the more data JP could feed into potential clients, the more visibility the supplier would get. We decided to be really transparent about this, constantly telling suppliers that key areas of information were necessary for clients to find them.
Fully Onboarded user
Searching for suppliers
On our clients’ side, we knew that their main goal was to find suppliers they knew JP was confident in. Currently, they were all doing this on a one-to-one basis, overloading the JP staff. Along with splitting the pricing model so that only premium clients were being directly managed, we introduced a more sophisticated search feature. Clients could search for suppliers instead of post jobs, which then suppliers would bid on. This was a huge change to how the client-supplier relationship worked, but one that was welcomed. The current bidding process was a nightmare for both parties and this now gave the ability of suppliers to showcase themselves for what they are worth and the power to the clients to find the suppliers they need.
Clients would search for suppliers and add them to a ‘Shortlist’ (more below). The could see key information on the search listing and filter into 3 key areas, which we tested with clients. We asked them what are the 3 top things you look for in a potential supplier (besides their skill). The answers were availability, cost and what tools they used. These formed our three filter criteria.
One idea from JP’s founder was to hide the suppliers. He was concerned that if clients saw the names of suppliers they would contact them outside the platform. I appreciated his concern but felt that would do more damage than good. It’s a system they used before and something which had come up in research as not positive. I explained that not only will giving a personal view to a client increase conversion for suppliers but the ability of the platform would keep both parties integrated. For the launch, we ended up just using first names as a compromise which I felt was a bad decision but understandable from his point of view.
A supplier's profile needed to show all their key information. When we spoke to clients about what they looked for; the stated that cost, quality of work and availability were key factors. We made sure that these were presented in a clear and concise way. Also, we added a reviews section that could give clients confidence if a supplier was genuine and could back up what they say.
Part of JP’s brand was their trust with their clients and suppliers. We added a feature that would showcase a ‘Jam Pan recommended’ supplier. This would be manually awarded to suppliers that have achieved a certain rating or skillset. For our initial launch, this wasn’t included but I thought it was a good idea to push forward. Something similar to AirBnb’s Super Host feature, which works really well for them.
A client’s shortlist is a collection of all the suppliers they are considering for a project. Before, clients would post a job opening and have to go through all the applications one-by-one. Most of the clients didn’t use this cumbersome feature. So we added the ‘Shortlist’, now clients can add suppliers to their list and they will all receive the same project brief. We also planned to integrate a chat feature where they could contact each other and discuss the terms and details of the project.
This gave more freedom to the clients as they were anonymous until that first contact had been made. No longer would they consistent messages in and outside of Jam Pan about projects which lead to a negative experience.
Client’s dashboard with Notifications
To keep the client-supplier relationship smooth, in Phase 2, we added a notification and messaging system. We wanted to remove the pain of conversing through a third-party (i.e. Jam Pan) or over email where crucial conversations and details could get lost. Having our own messaging system keeps all the business conversations in one place as well as provides a version history in case of any changes or miscommunication.
We kept the behavior simple, modeling the notifications on something like Facebook which we knew a majority of our users would be familiar with. We separated out all the conversation threads by the project to keep all message organised. The conversations would only open up after a supplier had been added to a project to keep respect the client's time and keep them away from unsolicited emails from suppliers they felt no longer were suitable.
A message thread between a client and a supplier
Our messaging flow was very straightforward. Each user could send two types of messages; basic text message that would display in real-time thanks to a WebSocket connection (go WebSockets!). Also, they could send pre-selected messages that would trigger an action in the supplier-client project flow (pictured above). Users could request/send quotes, create statements of work, leave the project etc. Some of these actions would trigger a request from the other party and we would log this in our database once it had been completed. In the example, this supplier has submitted an S.O.W for the client to approve. We would log this so we know that the milestone of ‘SOW sent’ has been completed. Once that had been signed we can then update the status.
This was crucial so we could monitor where projects were incased of any support issues. But also, we could combine this with our user analytics and tracking to see where projects usually dropped off. This would give us a big set of quantitative data to then go ahead and explore how we could improve that stage of the journey.
Signing an S.O.W
Including legal documents into the product was tricky. We needed to make sure we worked closely with Jam Pan’s legal team to reach compliance. We would make users complete multiple checkboxes and download a PDF version of the S.O.W before the official approval. We also introduced visual signifiers to communicate the importance of the document. Outlining the details of the work, billing cycle and breakdown of the cost was crucial.
Luckily for us, when we spoke to our users they were all well suited to signing these documents but we needed to make sure that new or less able users were protected. We introduced a holding phase of a couple of days where the agreement could be nullified and confirmed, which was company policy anyway. This was to be conducted manually by JP, which wasn’t ideal, but we would explore an automated system in Phase 3.
We launched the MVP after Phase 2, in late April 2019. This was launched alongside the original portal. Switch over wasn’t too much of an issue because the usage was so low. Regardless, we piloted the MVP with a selection of Jam Pans’ user base. Before the pilot launch, Dave took the product to a recruitment conference to present it as well as signup for new suppliers and clients.
In the first three months, after some marketing push, we saw a ~100% increase in new signups compared to the original product launch as well as ~150% activation of existing users to being fully on-boarded. We received overwhelmingly positive comments about the new look and feel and usable design from both suppliers and clients alike. Months after the launch, I caught up with Jam Pan about how it was going. They said the new platform had dropped the burden on customer services and growth was steady.
Phase 3 didn’t go ahead, however. Funding was tight and JP made a decision to spend that money on marketing their product as is rather than adding additional features and rebranding themselves. This made perfect sense for a 10–15 person startup that had burnt a lot of their cash on the previous portal build and launch.
What I learned
We had a lot of positive feedback on our process. Beforehand, the JP team hadn’t been present in any testing, design or product decisions. The previous agency took a PRD and went away for 6 months and came back with a product not fit for purpose. Tori, a lead on the project, said she really enjoyed the user testing sessions and found them incredibly useful for learning about how their customers use the online portal.
I learned a lot about my own process during this project. I had used Lean UX in some way, shape or form in most projects I've done but this was only the second time I’d brought other team members along with me. Educating them on how to run user testing sessions, what the benefits were and the nature of prototyping really helped me understand on a deeper level when this process worked and when it didn’t. I was brought onto this project after the planning of Phase 1, so I didn’t get as much time to do as much upfront work as I’d have liked.
If I could go back, there’s not much I’d change other than being involved earlier on to run a Design Sprint to iron out those big bets earlier so we could have spent more time on the fit and finish. We were slightly rushed at the end to meet a release deadline, which was compounded by the small size of the development team. There are some rough edges around the UI that still bug me to this day but the overall experience is 10x better than what they had and I’m proud of what we achieved.
But the biggest takeaway was just how fun these guys were to work with. Not only the team on the Mindera side but Jam Pan were so enthusiastic about the production process, it was impossible not to have a good time. Like every project, there are tense moments but seeing the JP guys learn about the production process as well as the passion they have towards their customers was infectious and definitely made coming to work on this project every day a joy.