Modular onboarding and eligibility

Enhancing user onboarding by dividing a single flow into modular flows, improving both user experience and operational efficiency

Overview

Uber Carshare formally Car Next Door, is a peer-to-peer car sharing platform that connects vehicle owners with borrowers, an alternative approach to traditional car rental services.

Since its startup days as Car Next Door, verification process for new members had been built up over a decade as new checks became necessary. This resulted in a robust yet time and money consuming process that needed to be improved for expansion.

Role

Product Designer

I led the design of the new onboarding flow and worked with the PM and EM on development. Ensuring it covered all user bases and regions as well as future global expansion plans.

User interviews, user shadowing, business analysis, strategic planning, visual design, prototyping, testing.

1

Understanding the problem

2

Discovery

3

Defining the problem

4

Solution exploration

5

Flows & Design

Understanding the problem

There were three key factors that forced our attention to the onboarding flows and application processing.

1. Application processing is slow and costly

Processing applications had become by far the most time consuming and costly processes for the member experience team. Average application took 15mins and up to 30 mins. When we looked at other businesses, their verification process seemed a lot lighter and sometimes even instant - think photo verification for a bank account or LinkedIn profile.

2. Increase in theft, arrears and other bad behaviour

When we rebranded from Car Next Door to Uber Carshare, we saw an increase in bad behaviour which was steadily rising. We needed to understand why and tighten the onboarding processes to remove any new users coming onto the platform who might cause similar issues.

3. It’s a black box, we don’t fully understand it

The application process had been built up over ten years as the business grew. When a new check was required, it was added to the long list of checks. This meant that we did not know exactly what it was doing as a whole and therefore how it could be improved.

Hypothesis

If we gain a good understanding of how we are processing applications and what checks we are running for each region, then we will be able to make appropriate adjustments to improve bad actor detection while reducing processing speed and cost.

Uncovering the black box

First step of discovery was to understand the application process in it’s entirety. We started by looking into what checks we were conducting, why we needed them, reasons why we might decline someone and a standard flow a user will go through. I collaborated with Product Manager, Engineering, Sales, Operations team, US & Canada teams to get these answers and to get clear and aligned to establish a good baseline.

I started by creating this flow which illustrates how a user goes through onboarding. Note that this one flow is used for both segments of users - people who wants to borrow cars on the platform, and people who wants to rent their car(s) on the platform. This is one of the early red flags we saw.

We listed out all the checks we were conducting, what the rules were and which region was using them. Note that some checks were still running but was not available, meaning the we had swapped out that vendor for another but the remnants still remained. Potential quick wins to remove this from the user flow and agent process.

We looked at all the ways we decline a user and why we decline them for that reason. What we also found was that we were not tracking these decline reasons so we got our analytics team to setup a data table to track each decline reason week to week so that we could understand what our most common reasons were and see if there were any leaks.

Interviews and user shadowing

To understand how agents were processing the applications and how the web page was used, we conducted interviews and user shadowing sessions. By talking to them and watching them process applications, we could see major areas where the process was failing these agents leading to a bad decisioning, unproductive use of time and overall frustration.

What we heard

“There is a need to constantly scroll up and down the webpage because information I need is scattered throughout or on a different page”

Conducted

4

Interviews

“Check are not in a logical order, they jump from identification to credit score, then back to identity fraud checks, it can get confusing especially when switching back to an old application”

Conducted

6

User shadowing

“We are asked to go through every single check, even if it’s an obvious rejection like an under age driver applicant, it takes us a lot of time to get through all the checks”

Defining the problem

Ultimately, what we found was that the application processing required a lot of changes.

  • Clean up of checks being conducted - to remove unnecessary or overlapping checks which will reduce cost

  • Deep dive into our decline reasons to gain a full understanding and to access if the checks are right and modify if necessary which will improve our detection

  • Tackle the issue of single onboarding flow for two user segments (borrowers and owners) which improves user experience and processing speed

  • Fix the agent application processing webpage to improve speed and therefore cost

  • Fix application processing logic so that agents no longer need to waste time on applications who do not meet a requirement

In discussion with the Product team, Marketing team and Sales team, it was decided that we would solve the issue which involved our external users first “Tackle the issue of single onboarding flow for two user segments (borrowers and owners) which improves user experience and processing speed”, then systematically improve all our internal processes.

I also worked on the the improvement of the internal processes when I transitioned to a Product Manager role at Uber Carshare, progress we made can be found in Verification Overhaul case study.

Problem statement

Uber Carshare’s onboarding flow has evolved over a decade but still follows a single process for both borrowers and owners. However, their needs and verification requirements differ, making a one-size-fits-all approach inefficient.

This misalignment introduces unnecessary friction, leading to user confusion and increased drop-off rates, ultimately impacting overall signups. A more tailored onboarding experience could improve conversion and user satisfaction.

Solution exploration

It became quite clear to us that we needed to modify the onboarding flow to cater for the two user segments. On top of this, we were quickly expanding into the United States and Canada, with talks of the United Kingdom, Singapore, and New Zealand on the horizon. We came up with two variations of how we might tackle this problem.

Original state

For context, below flow shows a simplified view of how verification worked, it will give context to how the two solutions aims to solve the problem.

Solution A: Separate flows for Borrowers and Owners

This solution was to simply split the single flow into two, one for people who want to borrow cars and one for people who want to rent cars.

Pros:

  • Relatively simple change where we add another flow and modify the current single flow - it’s low effort and will be quick to deploy.

  • Each flow is kept separate for each country / member segment and therefore will be easier to understand.

Cons:

  • Doesn’t scale well when expanding into a new region. Each region will most likely have different legal requirements meaning the flow will need to be adapted for that country.

  • If the above is true as it has been for the US and Canada, we will end up with two flows per country, or worse yet, per state (in some states in the US we observed varying laws that require us to conduct different checks and consent).

  • A global change to the flow means changes to every single flow will need to be made separately.

Solution B: Entirely modular onboarding and verification

This solution was to split the current onboarding into different parts, like ID verification, driving eligibility, car eligibility, credit eligibility and so on. By doing this, we could run specific checks for a user depending on their intended use of the product.

Pros:

  • Allows us to simply pick and choose which flow a user needs to go through at any given time - if a user goes to another country, they would not need to go through the whole flow for that country.

  • Keeps the flows shorter for better UX, we only ask for what we need depending on the user's intended use.

  • Keeps the flows simple and reusable in different countries provided the legal requirements don’t differ. This keeps the maintenance and upkeep of the flows much lower than solution A.

Cons:

  • Big shift from current state, requires significant engineering effort compared to Solution A.

  • Management of these flows and logic requires a little more strategic thinking as new regions are added.

Modular onboarding solution

After discussions with various functions of the business, we landed on Solution B. The main driver was that we were future proofing our onboarding flow and gave greater flexibility to add new regions moving forward.

By separating the verification flow into various sections or groups of checks, Uber Carshare is able to conduct the necessary checks for the user depending on their region and use of intention on the platform. This also means if a user travels to another location or becomes a vehicle owner from a borrower, we are able to conduct only the necessary checks for their new intended use.

Three separate checks were asking three simple questions:

  1. Are they who they say they are?

  2. Can they borrower a car?

  3. Can they list a car?

Below flow shows the individual checks we were conducting for each section of onboarding.

Flows and wireframes

Working towards the ideal state, I put together wireframes and used it as a tool to get questions and edge cases discussed. This helped the team align on exactly what we would be building and how it would help our users and product. The engineering team then performed estimations and spikes on various areas to ensure the proposed solution was achievable. The last section “Car eligibility” was deprioritised at this stage as Car Operations team was not ready to change their current flow, this did not affect the separation of Identity verification and Driving eligibility and we pushed on with the project.

Identity verification for all regions - this single flow is what determines if we want to allow them to be on our platform or not.

Driving eligibility for all regions - this flow has three variations for Australian licence, United States & Canada licences and international licences

Screen design

Once flows were finalised and the team aligned, I designed the screens for each user case and region.

Release plan

Working closely with the Product Manager, sales team, engineering team, agents who review the applications, we tried to breakdown the steps to ensure a smooth release.

1. Preparation

Both flows had to be released at once since it replaces the whole flow. For smooth transition, we created how to docs, FAQ articles and ran training sessions with the affected teams.

2. Release

Flows were be released at once under a feature flag to ensure we could roll it back if we saw any major issues.

3. Nice to have’s

We decided on leaving some of the nice to have UI elements to last, such as “Review in progress” count down bar and notification. We needed to work internally first to be confident with this SLA.

4. Future expansions

To prepare for new regions which would bring new requirements and criteria, we wanted to add the ability to create new driving and car eligibility flows in the back end.

Reflection

It was satisfying working on a feature that needed a lot of love. It had been neglected for years which resulted in bad user experience for users and operational burden put on the agents. I learnt about how to best structure data so that it could be expanded on in the future and how to break down big features into understandable chunks. Getting the team involved early in discovery also meant I had buy-ins from the team and it was great giving updates to everyone along the way.

See more of my work: