Encouraging workers to clock in on-time

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

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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

Encouraging workers to clock in on-time

Context

About Instawork

Instawork is an on-demand staffing platform for blue-collared workers (catering & warehouse work), where they can choose when and how much they want to work.

Project background

When an Instawork Professional arrives at the location of the customer (typically a catering venue or a warehouse), they start the shift by clocking in on the app, and once the shift ends they clock out. Their earnings are calculated based on the hours worked and paid out through Instawork.

Problem statement

One of the most common types of support tickets we used to get was around the clock-in/clock-out timings. Such tickets used to come from both businesses and professionals, because it directly impacted how much they got charged/paid.

However, this meant a lot of manual effort checking the logs, communicating back-and-forth with both parties and resolving the dispute. More than that, this caused unnecessary confusion for both the professional and the business and could lead to a lack of trust.

Hypothesis

One very likely reason for all this confusion was the way the users clocked-in in their mobile app. Here’s how it worked:

  1. The app starts tracking the user’s location a little while before the start-time of the shift
  2. Once the user is at the shift venue, it clocks them in automatically. But this would only work as long as location data is accurate. Places with bad connectivity could mean wrong clock-in times.

We had preliminary data from earlier user research to validate this. The support tickets confirmed this too.

Problem deep-dive

The automatic clock-ins caused two kinds of problems:

  1. Early clock-insThe user would be clocked in as soon as they’re in the vicinity of the location, which sometimes meant they’re still on the way, or finding parking. The business would be notified but they wouldn’t be able to find the professional yet.
  2. Late clock-insThis happened mostly when the automatic clock-in failed due to bad connectivity. As this doesn’t happen in most cases, the professional wouldn’t expect this. By the time they notice they’re not clocked in yet, they can manually clock in, but it’s late already.

Real problem

Yes, the clock-in data was wrong, but more specifically the recorded timings were earlier than the actual clock-in times in most cases. So, the actual instances of late clock-ins were probably more than what the data showed.

Late clock-ins affect both the professionals and the business partners. As business partners rely on the professionals for their events, each professional turning up late affects their ability to start things on time, which in turn affects their credibility. On the other hand, it had cascading effects on the professional’s livelihood — when they receive bad ratings for being late, it creates a lack of trust and hurts their future earning opportunities.

Goal

  • Reduce instances of late clock-ins
  • Make clock-in and hours calculation transparent

Step 1 — Fixing data

If we were to remove the automatic clock-in and ask professionals to clock in manually every time, it would give us more accurate data, but would mean a change of behavior for those who’re used to the current system. However, in the interest of making things transparent to the users while getting more accurate data to improve on, this is what we implemented at the risk of this short-term impact.

You can only improve what you measure.

Well, only if you measure it correctly.

Step 2 — Research

As an organization, we value basing our product decisions on data and user research.

Also, Instawork has a high bar for quality, the professionals are activated only after different quality checks. So we strongly believe that if a professional clocked in late, it is most probably due to an external factor, which we could help with. But we had to understand these factors first.

Data

We started with a hypothesis of different parameters that might cause late clock-ins — including experience level of the professional, day of the week, hour of the day, location of the event, etc — and started slicing the late clock-in numbers by each parameter. Two of them stood out as strong correlations.

  • Time of the dayGigs that start early in the morning had significantly higher tardiness
  • VenueThere were specific venues that had a higher rate of late clock-ins. These are mostly large venues like stadiums and golf clubs, which typically have multiple entrances and are tricky to navigate, or where the workplace is far away from parking.

User interviews

We also sent out surveys and interviewed users to understand this deeper. This confirmed the learnings from data but also explained why that was the case.

  • Not able to clock in even after reaching the venue, because finding the exact place/person to clock in with is not clear at some big venues.
  • When the shift is early in the morning, the reminders we send a couple of hours before the shift were not very useful.

Step 3 — Solution

Quoting an Indian statesman,

If you want people to do good, you need to make it easy to do good, and extremely hard to do bad things.

Once you understand the reasons for the current behavior, you can help change it. Taking the learnings from the research, we started tackling them one by one.

Helpful reminders

Prev evening SMS for early morning gigs

For shifts that start early in the morning, we started sending reminders the previous evening, along with an estimated time to leave home to arrive on time.

Commute time SMS before the gig

For other shifts, we were already sending reminders a couple of hours before, but now started including the time to leave based on their location.

https://cdn-images-1.medium.com/max/1600/1*are-yj6y5g8vaWh1fsk2_Q.png

Left — commute time reminder. Right — previous evening reminder for early morning shifts

Addressing complicated venues

When a business posts a shift at a venue that’s known to cause confusion navigating, we suggest them to adjust the map marker to the exact clock-in location and add clear navigation instructions.

https://cdn-images-1.medium.com/max/1600/1*F_3dRzsTDrvMqTqaoMX42g.png

When a professional is looking to book such a gig, they’re shown a heads-up too so they can be prepared and arrive a little earlier.

https://cdn-images-1.medium.com/max/1600/1*i-yExdRt8zGNY9Qb-wIxnQ.png

Transparency

When it’s close to the shift start-time, the app shows a real-time view of the time and distance to cover, giving the professional complete transparency of the clock-in time.

https://cdn-images-1.medium.com/max/2400/1*YfMvYAnsp04goEEU2qEEjw.png

Results

As we implemented these changes one by one, the instances of late clock-in started reducing gradually, and eventually by more than half.

Scroll to top