Getting Instacart prepared for CA Prop 22

Problem

When California proposition 22 passed, it meant major changes for the gig economy. Now, gig companies operating in California had to provide the people working on their platforms a guaranteed minimum wage, and potentially a healthcare subsidy if they worked enough hours. Gig companies were also given a very tight timeline of just a few months to comply with these new regulations. Instacart's shopper app wasn't set up to calculate or display these changes at all, so a significant portion of engineering effort needed to go towards reconfiguring the app's back-end to function properly.

The design team was asked to make the necessary front-end updates as minimal as possible, which posed a unique challenge given the new cognitive complexity the new laws introduced. Nevertheless, a lead product designer and myself set up to do what we could to do right by Instacart shoppers in record time.

Goals

Our goal was clear—understand the new laws under Prop 22 as much as we could so that we could propose UI updates that were 1). Executable by engineering in just a few months and 2). Delivered  accurate information to shoppers so they could track and understand their earnings and healthcare subsidy status.

Scrappy research

The designer and I pushed hard to include a very brief round of research in our work before we set out to propose UI changes. Our PM was resistant to this at first due to timeline constraints, but given the potential liability risks to the business, she eventually allowed us to do some very scrappy testing with users. We quickly uncovered that most shoppers wanted the concepts of the law simplified as much as possible, but still wanted to retain access to the full "accounting" of their time and distance work so that the could audit things if need be. They preferred visualizations to help them contextualize their progress towards the guaranteed wage, too. All of this meant that content design was going to have to work extra hard to develop the right in product concepts to get the job done! 

‍

Concept development

After scouring the laws for weeks and talking to shoppers, I proposed that we introduce the concepts of a "guaranteed minimum" and a "weekly adjustment" into the product. The former was a shortened version of the guaranteed minimum wage Instacart would owe the shopper. The latter was meant to be the "true-up" Instacart provided if the shopper made less than the guaranteed minimum from their "batch payments" (an existing concept in the product that equated to how much the shopper earned working on Instacart). If the shopper's batch payments exceeded the guaranteed minimum, no weekly adjustment would be made.

Still confused? Don't worry; this is why visualization became a key part of communicating these concepts ;).

We were the most visually constrained in the interface for the healthcare subsidy. Ultimately, we could really only rely on text to communicate a shopper's progress towards earning the subsidy. given that constraint, I did my best to structure the text in way that was easy-to-understand and consumable.

Results Achieved

It took many a late night and some weekend work, but ultimately, we launched an MVP version of a prop 22 friendly app within the time allotted by the state. While it certainly wasn't perfect, in qualitative research post launch, we learned that shoppers mostly understood the new mechanics of their earnings and their eligibility for a healthcare subsidy. In future engineering cycles, we were able to "fast follow" with some more visual changes that made the core concepts easier to understand. The core concepts that I developed are still in use in the product today! 

‍

Constraints and challenges

• The timeline for this work was the biggest challenge. With a deadline of just a few months, we couldn't propose major visual updates to the app and in many places, had to settle for text heavy interfaces.
• While I'm happy the concepts that I developed for the product are still in use, they do read a bit academic to me. Legal was very particular about what I could call certain things based on the text in the laws. If that constraint weren't there and I got to do this again, I'd ideally pick simpler terms.