Redesigning onboarding for a new user segment

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.

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

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.

Existing 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.

OKR for the quarter, showing focus on “trust and anxiety”.

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.

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

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.

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

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.

Design goals

Help users realize value by viewing gigs before applying

Let users book entry-level gigs without an application

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.

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)

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.

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.

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.

Testing with different user segments

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

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.

V2: Previewing skilled-position gigs before applying

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