Improving marketplace safety by adding positive friction.

🚀 Shipped October 2018
📱 iOS, Android, and Web
✏️ Lead Designer

To steal a phrase from another case study — Trust is the core of Turo's marketplace. Guest's who have an experience that makes them feel unsafe are unlikely to return. As a designer, I'm an advocate for the people who use our product. It's my responsibility to seize opportunities to improve the safety of the marketplace. In this case, legislation presented an opportunity to do so.

I led design on a team effort collect better data on the cars entering the platform. This enabled us to build infrastructure for safety recall checks. It also created positive friction that deterred low intent hosts at no cost to revenue.

Maryland passed legislation requiring changes to our marketplace.

The core of the bill required us to collect Vehicle Identification Numbers (VINs). A VIN is a 17 digit mix of letters and numbers that identifies a specific vehicle. In other words: not a Honda Civic, but this Honda Civic. VINs would let us to check safety recalls on cars entering the Maryland marketplace. This project had a tight, non-negotiable deadline to avoid potential fines.

I led design on a multidisciplinary team. We managed expectations with a large set of stakeholders.

My project team included a product manager, an engineering manager, and cross platform engineers (iOS, Android, web, and back end). We managed expectations with our Host product domain, legal team, and executive leadership. I got valuable feedback from other members of the design & product org.

My team advocated shipping this safety driven change beyond where legislation required.

I recognized an opportunity to help our guests across the board. We'd need an infrastructure to check recalls on our hosts cars. We'd also be collecting VINs — a powerful tool for fraud prevention. Vehicle safety and fraud cause some of our guests worst experiences. As an advocate, I needed to push for a wider adoption of these changes. I'm thankful to have worked with great people — my project team didn't need much convincing. We kicked off the project planning to create something we could ship beyond Maryland.

We aimed to ship a low friction VIN collection experience.

At a base level, we needed to collect VINs for all new vehicles in Maryland. At a deeper level, we wanted to make VIN entry as friction free as possible.

Primary metric
Collection of VINs on all new listing
Especially in Maryland. Everywhere in an ideal world.

Counter metrics

1. Listing flow conversion, both on this collection step and the flow as a whole.
   VINs are annoying to enter. If it's too annoying, hosts might abandon.

2. Revenue
   Any drop in conversion might also impact our earnings.

My team suspected VIN entry would have a negative conversion impact. We hypothesized it would only deter low intent hosts though.

VINs are long, and most hosts won't have them on hand. Some hosts might not even know what a VIN is. Friction was a concern, and we worried we'd cause some hosts to abandon the process.

That might not be a bad thing though. Not every car owner who joins Turo plans to fulfill trips. Some join out curiosity, and bail when the get a booking. Turo shares some responsibility for this. It's likely we're not educating or motivating them well enough. Regardless — these hosts leave guests hanging, and that experience sucks. It also hurts our business.

My team felt low intent hosts would be the primary cohort deterred by VIN collection. Less hosts might enter the marketplace if that were true. If we didn't see a proportionate decline in revenue, that would prove our hypothesis.

I needed to move fast. I used market analysis to see how other product collect VIN. I also ran feedback driven iterative sketching exercises.

Most of the solutions I found offered straightforward text entry. The best products offered an option to scan a barcode that often accompanies VIN. Scanning felt like a great opportunity to reduce friction.

I wouldn't usually dive straight into sketching, but the timeline required acceleration. I had to to explore how to work VIN collection into the existing architecture of the listing flow. I also had to compare and contrast architectures for educating about & collecting VINs. I documented considerations as I identified approaches. Rapid fire feedback from my team & other designers helped us start forming recommendations.

Early explorations generated three main takeaways.

Let hosts scan VINs.
Scanning could reduce friction. Engineers confirmed it would be a quick implementation with native iOS & Android tools.

Decode information from VINs.
A VIN includes information like car year, make, and model. We could could guarantee accuracy and remove extra steps by decoding. Better info, less steps.

Design the feature as it's own flow.
We anticipated needing to collect VINs for cars already on the marketplace in the future. Creating a child flow — rather than implementing in a main view — would make for easy use of the UI elsewhere.

My team broke the effort into smaller user stories. I dove into UI explorations.

We knew we'd need a handful of elements:

1. A clear explanation of what a VIN was, and where to find it.

2. A scanning UI using native iOS & Android tools.

3. A VIN input field with actionable feedback when there's an error.

4. A means of entering year, make, and model when we can't pull it from a VIN.

5. A means of letting hosts know we found a recall.

We broke those into user driven stories like:

• As a host, I want to be able to scan my VIN

• As a host who entered a VIN, I don't want to enter my year, make, and model

• As a guest, I don't want to book a car with a safety recall

I jumped from wireframes to high res UI explorations. I continued documenting and comparing approaches with my team. We kept our host product team, legal team, and executives abreast of progress. That allowed quick movement and early identification of concerns from stakeholders.

We AB tested a VIN collection experience across the US.

Hosts can enter their VINs on iOS, Android, and web, and scan them on iOS and Android. We decode year, make, and model from valid VINs. That let us remove three inputs for the price of one. Hosts outside the US weren’t required to enter VINs, but we supported them with the same infrastructure.

We agreed to AB test the change to allay concerns about revenue. 50% of car owners wouldn't get asked for a VIN, and 50% would. We boosted the test group to 100% in Maryland for compliance.

We also started checking for open recalls before cars entered the Maryland marketplace. I would have loved for a broader launch of this process. It made sense to observe the impact in Maryland first though. The infrastructure we built would enable quick expansion later.

Here’s VIN collection on iOS.

Here’s Android

We didn’t run into any situations that called for platform specific approaches. Android mirrors iOS in its architecture. There's some native styling differences like the scanning view.

And here’s web.

Text entry is the only option. Without a camera, we weren’t able to provide the scanning experience we did on iOS & Android.

The flow accommodates a variety of use cases.

We built prompts for unexpected outcomes (ex. invalid VIN or VIN not recognized) and paths for different use cases (ex. VIN not required). We aimed to provide clear feedback in cases of failure, and give hosts an obvious path forward. We mixed and matched the same reusable screens from elsewhere in the flow cut scope. I’ve highlighted a three examples below.

1. A host scans a valid VIN, but we fail to pull the cars info. This prompts manual inputs for car information.

2. A host types their, but it conflicts with one of our VIN validation rules. We have a handful of rules (too short or too long, invalid character etc). We give specific feedback whenever possible. A host has to enter a valid VIN to move forward.

3. If VIN isn’t required, hosts need to enter their car info. We re-use the same prompt in Example 1 to collect this info.

We started blocking cars with active recalls too.

We run checks at the end of the listing flow. There was debate between a few placements. Alerting hosts as soon as we collect their VIN was a strong contender. It meant hosts who were ready to list would have a lot of steps to complete once we cleared the recall though. Letting hosts complete the remaining steps before alerting them minimized post clearance friction. They could go live in search with a single tap.

Our hypothesis proved correct! Revenue wasn't affected. We enshrined the AB test.

🤩 Fewer low quality hosts entering the marketplace.
Conversion drop at VIN step: -20% vs control
Conversion drop by end of flow: -10% vs control
Revenue drop: 0% vs control

In non-metric terms: less cars were entering the marketplace when we required VINs. The biggest drop was at the step where we asked for VINs. That drop shrank versus control when looking at overall flow completion though. Despite that, the same revenue was being generated. This was a strong sign that hosts less intent on fulfilling trips were being deterred. Drops are scary, but we viewed this as positive friction.

🤩 Turo gained important guest safety tools.
Cars in Maryland can't enter marketplace with an open recall. This narrow roll out disappointed me. I was thankful to work on a follow up project to extend this feature to California, our largest market. That project also enabled us to extend recall checks to cars already on the marketplace. The positive guest benefits and small business impact generated wider support for expansion.

Our Support & Ops teams also found great us in VINs. They made vehicle identification easier in support cases. They also enabled important fraud tools. That included blocking fraudulent actors from reentering the marketplace after a ban.

🤩 Turo gets more accurate car data.
Pulling information from VINs lets us guarantee the car year, make, and model are correct. This has benefits ranging from pricing algorithm improvements to fraud prevention. The base we built will enable the team to pull even more information in the future.

There’s a handful of things I’d love to see moving forward.

We need to run usability testing.
This was the primary shortcoming of this effort. The legislation driven timeline didn't accommodate coordination with our research team. At the time, designers weren't empowered to run research initiatives on our own. VIN collection is a core component of our listing experience, and we need to see how people are using it. I advocated for a follow up Research project to identify pain points and gather feedback.

We can enhance the web experience.
VIN submission rates were consistent across platforms despite web's text only input. That indicated it wasn't a serious detractor. It didn't capture the same magic as the mobile scanning experience though. I explored & documented enhanced solutions for the desktop experience. This included linking to the app or a mobile web view with camera access via text message.

We can automate more of the listing flow.
The information we can pull from VINs isn't limited to year, make, and model. We could also identify trim, and check for things like salvage titles. That would let us drop even more steps. The main hold up in not expanding was our use of a third party service to decode VINs. We didn't have the time or budget to negotiate having our provider pull more information. I'm confident the team will build on this in the future.

Building trust by coaching new hosts on how to take great car photos.

🚙 Turo
🚀 Shipped November 2019
📱 iOS, Android, and Web

Allowing hosts to list & earn anywhere.

🚙 Turo
🚀 Shipped March 2018
📱 iOS, Android, and Web

Setting expectations by structuring airport settings.

🚙 Turo
🚀 Shipped October 2017
📱 iOS, Android, and Web