Guided workflows for recruiting software

Summary

Instawork is an on-demand staffing platform used by blue-collared workers to find flexible work (gigs).

When the onboarding flow for this mobile app stopped working after expanding to a different industry, I helped redefine the user segments, redesigned the onboarding flow to make it work across the industries, and increased the conversion by 400%.

My role

As the lead designer for the project, my responsibilities included:

Company

Instawork

Team

1 Designer,
1 Product Manager,
1 User Researcher (mentee),
A team of developers

Timeline

Q2-Q3 2021 (3 months)

Context

Project background

Before the Pandemic, Instawork was an on-demand staffing platform focused in the hospitality industry. Due to the pandemic, the focus changed to a new industry — Warehousing.

Instawork before and after the pandemic

As a consequence, the onboarding flow for professionals (workers) — that used to work well in hospitality — started seeing huge drop-offs.

Onboarding funnel
Only 7% of signed up professionals work a gig

On the other hand, demand was growing exponentially in warehousing, and even hospitality demand was increasing steadily.

Demand grwoth after COVID impact

Problem statement

  • The current growth rate of supply — i.e. professionals available for working gigs — is not enough for the projected peak season demand.
  • The onboarding funnel has massive drop offs, thus losing a lot of great professionals in the pipeline.

Deep-dive & Hypothesis

As a first step, I teamed up with the Product Manager, and took a closer look at the funnel. And we were able to quickly narrow down the problem to the later part of onboarding - i.e. the part where the user applies for a “position”.

Funnel chart showing drop-offs at different steps of the onboarding

Existing flow

Existing onboarding flow

Initial hypothesis

Based on anecdotal evidences like support tickets, app store reviews, etc., the product team had a hypothesis that:

The drop-offs were happening because of a “lack of trust”, since the product was not as known among the warehouse workers as it was in hospitality.

And this had even influenced the roadmap for that quarter.

Initial hypothesis around "lack of trust"Roadmap showing focus on "lack of trust"
OKR for the quarter, showing focus on “trust and anxiety”.

Digging deeper with User Research

While it was a valid hypothesis, I wanted to conduct more research, to:

  • validate if lack of trust is indeed the biggest reason for drop-offs, and discover any other reasons
  • identify the underlying reasons for lack of trust, and thus our biggest opportunities to build trust

Interviewing dropped-off users

From my previous experience with onboarding-related changes, I knew that conventional user interviews wouldn’t work for new user experiences.

Because, users who abandoned the app without even completing the onboarding are very unlikely to respond to requests for user interviews.

So I seeked help from the “Supply Ops” team, that used to call up the dropped off users to nudge them to complete onboarding and to help them with any questions.

1
First, I listened in on some of the “nudging” calls done by supply ops team
2
Then I switched roles and called users myself, with help from the team
3
In addition to the usual script, I asked a few follow-up questions on why they dropped off earlier

Usability testing

While the interviews gave a high-level understanding of what the users were looking for, I wanted to dig a little deeper into the specific pain points.

A usability study would be perfect for this. But like any other first-time user experience, this should ideally be tested with a new set of users who haven’t experienced the flow already.

So I used an unmoderated usability testing tool called Userbob, to test the live app with a set of potential users.

Usability test setup
Usability test setup

Learnings

Seeing opportunities upfront builds trust

Letting users see the available gigs before asking for personal details can go a long way in building trust. This can help in both the old and new industries.

Lack of clarity on current status & next steps

Users want to know when they can start working a gig and how to get there quickly. But, UI and the terminology made it hard to understand the current status and next steps (e.g. “positions” were misunderstood as specific roles rather than categories).

Friction with entry-level requirements

Some of the required details like work experience are perceived as “too much” for working entry level gigs. These details are also tedious to complete.

Redefining user segments

With the above learnings, some of our shared assumptions about professionals started to break, and new personas started to emerge. I evolved this understanding by conducting additional (secondary) research. Here are a few examples of the sources I used.

  • “Working/Shadowing a Gig” notes from colleagues in the US
  • A large-scale survey conducted by Marketing to understand the new userbase
  • My past surveys related to worker profiles and work experience
  • Intent questions from onboarding

For the scope of this project, I identified these four segements in particular:

Skilled hospitality professionals

Looking for high-paying gigs that match their skill set.

Entry-level hospitality professionals

Got basic skills in hospitality, but open to non-hospitality work

Warehouse professionals

Looking for intermediate-level warehouse work, but might consider entry-level work

Newbies

People from various backgrounds looking for entry-level work that don’t require specific skills

Realigning the roadmap

Now that I had these solid findings from the user research, it was time to revisit the roadmap and adjust the priorities.

First, I discussed these learnings with my PM, and we came up with the updated roadmap, which focused more on getting the professionals to realize value sooner and simplifying the journey to their first gig.

Screenshot of the updated roadmap based on user-research findings

However, in order to quickly test out the original hypothesis around lack of trust, we planned these “quick wins” to build trust:

  • Surfacing up “People you may know”
  • Social proof (testimonials, app reviews, etc.)
  • Quick-glance view of the demand
  • Personalized flow for high-intent pros
  • Collecting “intent” to help prioritize follow-up calls

Scenario mapping

Before taking this updated roadmap to the leadership and other stakeholders, I worked with the PM to hash out the high-level plan on how the different scenarios (based on a combination of user preferences and the demand in the market) will be handled.

Possible scenarios of user preferences and market demand
Mapping scenarios of user preferences and market demand against intended actions

Then I visualized this into simpler user flows to communicate to a wider audience.

Flow diagram of the onboarding before the changes

Green signal

Through a series of discussions (thanks to Zoom and Slack), using the above findings and visualizations, and with the help of the PM, I was able to get a go-ahead from the leadership for the new roadmap. But we agreed it was important to keep these in mind:

  • Quality of the professionals is important for all the positions, but it’s non-compromisable for the “skilled” ones.
  • The proposed solution has to be signed off by the Supply ops team - who was also part of this discussion on the new roadmap
  • This might require changes to some fundamental assumptions in code, so the solution should be discussed with engineering as early as possible.

Solution exploration

Design goals

Help users realize value by viewing gigs before applying
Let users book entry-level gigs without an application

Inspiration

Before I start exploring design solutions, I often spend some time looking at other apps (not necessarily competitors) for inspiration. Here are a few of the apps I looked at for this project, and the takeaways from each of them.

Apna
(blue-collared job portal in India)

Screenshots from Apna app

WorkIndia
(blue-collared job portal in India)

Screenshots from WorkIndia app

Duolingo
(language learning app)

Screenshots from Duolingo app

Design concepts (lo-fi)

Before I start exploring design solutions, I often spend some time looking at other apps (not necessarily competitors) for inspiration. Here are a few of the apps I looked at for this project, and the takeaways from each of them.

Design concept with only entry-levl gigs shown upfront

#1. Only entry-levl gigs shown upfront

Design concept with all gigs shown upfront

#2. All gigs shown upfront

Design concept with all shifts shown upfront + callouts to unlock non-basic positions

#3. All shifts shown upfront + callouts to unlock non-basic positions

Stakeholder inputs & final direction

Supply ops

Supply ops team owned all the backend processes for the supply - reviewing applications, activating professionals, handling ad-hoc communications and many more. So it was crucial that they’re aligned with any changes we were making to the onboarding process. I also wanted to get their inputs on the pros and cons of the different approaches.

Thanks to the detailed scenario mapping I had done in the previous step, it was straight forward to evaluate the solutions against the different market scenarios and user preferences.

The team’s major concern was that auto-activation (letting professionals book a gig without a manual review) could be risky and might lead to bad experience for customers. After discussing the trade-offs, we came to an agreement that

  • auto-activation should only be applied to entry-level work
    • even the existing process for entry-level involved bulk-activating anyone who had filled in some basic profile information, so this wouldn’t be a problem
    • but the team would continue to asynchronously review the profiles for red flags like inappropriate profile photo
  • showing gigs before activation could backfire in markets with low no. of gigs, so the design should handle this scenario carefully
  • removing work-experience requirement for entry-level might be ok, but we should roll this out in a controlled manner and check for any impact on worker quality

Engineering

Besides getting a feedback on the overall solutions, I particularly wanted to check the feasibility of showing gigs before activation, because I knew it would require a major change in the “dispatch logic” — the part of the code that determined how a newly posted gig gets dispatched (made available) to the different tiers of professionals.

I learned that the answer is a mix of yes and no. i.e. Letting users see a list of gigs before activation would be straight forward, but letting them see the details page would require major code changes and would delay the release.

But it was super helpful to find this out early on, as I was able to design the MVP accordingly (more on that later).

Design critique

It was a usual practice at Instawork for the designers to present their work (often WIP) to the whole product team of PMs and designers, and sometimes people from the leadership team. I used this opportunity to get inputs on the high-level concepts to narrow down the direction.

Design-approach document

In parallel, I summarized the context and thought process so far in a document and shared it with a wider audience across the organization, seeking feedback

This is a practice I established along with another designer, inspired by the “Technical Approach Documents” from Engineering. The idea was to make the thought process behind the designs transparent to the whole organization, and encourage feedback from anyone.

This also helped with getting asynchronous feedback from stakeholders across timezones.

Screenshot of the Design Approach Document for this project

Final direction

From all the stakeholder and user inputs, it became clear that concept #1 fared better than others, because it

  • most clearly communicated the whole range of opportunities (entry-level to skilled) for all user segments
  • addressed the immediate need for entry-level workers, but also scaled well for future scenarios and edge cases
  • lends itself to iterative rollouts and controlled experimentation (A/B tests)
Lo-fi design of the final direction

Task Prioritization

After collating the inputs from all the stakeholders and the learnings from the research, I worked with the PM to identify the different tasks in the project and prioritize them using RICE framework as shown below.

Task prioritization table

UI design

Exploring new components

There were clear usability issues identified from the user research, so some of the existing UI components had to be rethought. Also, showing the entry-level gigs upfront required a new section.

In order to explore a breadth of design possibilities, I took a modular approach and tried to visualize each of the modules in multiple ways, and then combined the best options to create the final UI.

UI components explorationUI components explorationUI components explorationUI components explorationUI components exploration

Revisiting Terminology

Confusing terminology was a recurring theme in the usability issues identified.

In order to explore a breadth of design possibilities, I took a modular approach and tried to visualize each of the modules in multiple ways, and then combined the best options to create the final UI.

  • For instance, we had been using the term “position” to refer to a job category (e.g. “Bartender position” would mean all the Bartending jobs on the platform), but most users understood it as a specific job opening.
    - There were associated terms like “Apply to a position”, which also added to the confusion
  • Also, the term “gigs” had come to have a slightly negative connotation due to the negative PR associated with other “gig” apps, and this was a good opportunity to rethink the term.

In order to explore a breadth of design possibilities, I took a modular approach and tried to visualize each of the modules in multiple ways, and then combined the best options to create the final UI.

  • replacing “Gigs” with “Shifts”
  • replacing “Positions” with “Roles”
  • replacing “Apply to position” with “Get activated to work gigs“

Prototype testing

Before finalizing the design, I set up a Figma prototype to validate them with users, especially:

  • Does it convey the range of opportunities available on the platform?
  • Do people get excited by the opportunities?
  • Do people understand what the next step is?
  • How do the above things compare for Hospitality workers vs Warehouse workers?

Since a vast majority of the gigs at that time were entry-level gigs, we focused on optimizing the end-to-end experience for these user segments. From the end-to-end design I had made earlier, I picked the relevant parts for MVP and created a new design.

Prototype setup for testing new design

Testing with different user segments

I ran two quick studies (thanks to Userbob again) with two cohorts of users from Hospitality and Warehouse industries.

Userbob setup for testing the new design

Final design

Here’s the final design, based on the user research insights, prototype test results, inputs from stakeholders and UI explorations.

New end-to-end design

Planning incremental rollouts

Though we had prioritized the tasks using RICE framework already, we wanted to be really conscious of the timeline as were approaching the peak season. Using the 80-20 principle, we wanted to identity the 20% changes that would give us the 80% results.

MVP: Showing entry-level gigs upfront

I worked with the engineering team and the PM to identify the MVP that would

  • have the highest ROI (using an 80-20 principle), but also lay the foundation for subsequent changes
  • validate the hypotheses and nullify major risks

Since a vast majority of the gigs at that time were entry-level gigs, we focused on optimizing the end-to-end experience for these user segments. From the end-to-end design I had made earlier, I picked the relevant parts for MVP and created a new design.

MVP design end-to-end flow
MVP design showing different UI states

V2: Previewing skilled-position gigs before applying

In the second iteration, we focused on the user segment interested in skilled positions.

V2 design - happy pathDesign showing updates to the position cardsV2 design's edge cases

Updating Design System

This project required some updates to existing components (e.g. position cards) as well as introducing some new components (e.g. entry-level gigs section). These changes were applied to the design system along the way.

Design system changesDesign system changesDesign system changes

Results

The changes were rolled out with an A/B test — starting with a small % of users seeing the new design, and then ramping up this percentage. I kept a close watch on the data over the next few weeks, and started seeing the conversion rate being significantly higher for the cohort that saw the new design.

The end-to-end conversion (from signup to working the first gig) improved by more than 400%.

Chart showing the onboarding funnel before and after the changes

Guided workflows for recruiting software

Context

About the company

Recruiterbox is an “Applicant Tracking System” that helps small- and medium-sized companies manage their hiring process — including sourcing candidates, screening, scheduling interviews, collecting feedback, etc.

In this project, we set out to add a layer of “smartness” to the system, to make it highlight action items based on the current status and the user’s role.

Employer: RecruiterboxRole: UX DesignerPlatform: WebDate: May — Aug 2016

Project Background

Though the system already allowed clients to set up their hiring workflow (the stages a candidate goes through), these “stages” were nothing more than a set of labels. Keeping track of what is happening within each of these stages was not easy.

Old UI: Hiring workflow setup
Old UI: CTAs on candidate profile

In the candidate profile above, all that the system tells is that the candidate is in Telephone Interview stage. It has no notion of whether the interview has been scheduled or not, who the interviewers are, and if they have submitted their feedback.

User personas / roles involved:

  • Recruiters
  • Hiring Managers
  • Interviewers

Goal

The goal was to make the system guide recruiters throughout the hiring process, allowing them to:

  • quickly track the candidate’s exact status (without having to read through multiple sections of information)
  • get a clear picture of what they need to do next + an efficient way to act on it.

MVP & Goal Validation

As this touches upon some of the core workflows of the product, we were aware that getting it right might take multiple iterations of fine-tuning.

So we planned to validate the value proposition of the goal, before working on an exhaustive solution.

Configurable stages to reflect interview workflow

‍

State-based dynamic CTA on the candidate profile

‍

So in the MVP, we just made the hiring workflow little more customizable, so that the CTAs on candidate profile make sense for the candidate’s current status.

This way, the change didn’t disrupt the existing workflows, while enough new workflows were getting set up (for new job openings), thus giving us big enough sample set for data analysis.

Learnings from MVP

When we looked at the events tracked on Mixpanel, we learnt that the dynamic CTAs were clicked only about 40% of the times they were shown.

So, we started digging deeper to understand what the rest 60% ended up doing. We put together the Mixpanel events against a snapshot of our backend database, which connected the user activities with the resulting state. While this explained the “what” of user behavior, we spoke to a few users (thanks to the great rapport our customer-facing teams had with our users) to understand the “why”s. Three behavioral patterns emerged:

  • Interviews are often (almost 50% of the time) scheduled before the candidate is moved to the corresponding stage. Given that changing the stage is more of a bookkeeping chore and interview-scheduling is the real work, this made sense. Especially because interview-scheduling could be triggered by offline events — like a phone call with the candidate.
  • People often diverged from the hiring workflow, using it just as a rule of thumb. For example, if the candidate is not in the same city, one might want to do an extra Skype call before flying in the candidate for a F2F interview.
  • While interviews (and profile reviews) were core parts of the hiring workflows, recruiters also spent a considerable amount of time handling communication with the candidate as well as with other colleagues involved in the hiring.

With these solid findings, it was good enough for us to start working on an exhaustive solution.

Design Sprint

At Recruiterbox, we used to follow an abridged version (~1.5 days) of the Design Sprint pioneered by Google Ventures. So, we started the sprint with “what” questions — to define the scope, followed by “HMW (how might we)” questions — to lay out the requirements.

Also, the learnings from the MVP were translated into the following requirements:

  1. Gracefully handle interviews scheduled outside stage
  2. Allow tracking communication-related work
  3. Accommodate multiple interviews/reviews within a stage

Paper Sketches

This is how the two alternatives fared against each other:

‍

Option 1 — Pros:

  • Less drastic change: Page layout remains roughly the same as the existing version, thus less relearning for users.
  • Focus: Pending work items get more real estate and prominence (always at the top) at the top of the main column.

Option 2 — Pros:

  • Visibility of multiple workflows: All workflows are visible simultaneously, while option 1 shows only one at a time, due to the limited space in the header (the user would need to click on the “+ 1 more” link to see the rest).
  • Scalable number of stages: The vertical layout scales better for hiring workflows with a large number of stages, not only because it can show more stages in one shot, but also vertical scrolling is more natural than horizontal scrolling.
  • Better zoning of information: The hiring workflow remains visible even when scrolled, while at the same time giving a visual separation from the candidate’s profile info (name, email, contact details, etc).

Option 2 was clearly better in the bigger context, despite involving more work and throwing away a previous design (of the hiring workflow graph).

UI Design

Candidate Profile — before and after redesign

‍

Results

1. Capterra Ranking

While we were just wrapping up the rollout, business-software reviews website Capterra carried out a study of 216 applicant-tracking-systems and singled out Recruiterbox as the number-one most user-friendly applicant tracking software:

While there are multiple components to this score, usability carried 50% weightage, which in turn was scored based on ease of completion of 7 core recruiting tasks. Read more

2. Internal feedback

‍

3. Side effect — meaningful data

One of the common workarounds people were using earlier was to have multiple stages in place of one, to represent different states within.e.g. “Skype Interview — to be scheduled”, “Skype Interview — scheduled”, “Skype Interview — collect feedback”, etc.

As a result of the guided workflows, such workarounds were no longer needed, leading to a more natural set of stages.

This, in turn, enabled us to provide users with useful insights about their hiring workflow — where the bottlenecks are, how long each interviewer takes to submit feedback, where most candidates get filtered out, etc.

‍

Scroll to top