Potential hosts were being blocked from listing at their home address.

Every car on Turo needs a base where host can meet their guests. This is the first piece of information we collect from owners before they list their car. Our existing collection tool was a Google powered autocomplete form. This worked great in most cases, but wasn't perfect. Some legitimate addresses, particularly international ones, weren't recognized. This was a total roadblock, and led to a lot of support calls from from potential international hosts. Our international business teams reported it was frequent issue. It was happening enough that it blocked certain markets from launching.

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

I worked on this project with my cross discipline project team - myself, a PM, an engineering manager, and cross platform engineers (iOS, Android, front end web, and back end). We managed expectations with our Host product domain and our international business dev team. I got valuable feedback from other members of the design & product org.

We aimed to unblock frustrated hosts, and let them earn anywhere.

Metrics

1. Host complaints
   These should go down. If hosts reported the issue less, it would be a rough indicator of positive impact.

2. International YoY revenue growth
   This should go up. Accelerated growth in affected markets would be a direct sign of impact.

We started by building a deeper understanding of why some addresses failed.

Our international business team had been documenting the case of each blocked hosts. This let us review their direct feedback from frustrated hosts. I grouped these failure cases into categories:

• Some addresses prompted results in autocomplete. Selection threw a "Please provide complete address" error though.

• Some addresses only prompted results if you rearranged their order.

• Some addresses didn't prompt any results.

Our engineers spent time identifying specific failure reasons in each case. That started to paint a clearer picture of Google Location Service's nuances. It also illuminated failures in our own mapping of the data we received from Google. That let engineers dive in and make improvements that didn't need product changes.

One key learning — it's not that Google didn't have an address for these locations. They usually do. There's often a disconnect between Google's data and the hosts localized input though. We needed to bridge the gap between between the two.

I used what we learned to diverge on project directions.

Market analysis was a good place to start. We weren't reinventing the wheel. It made sense to see how great products accommodate address input. This turned up a mix of methods from basic input fields to Uber style "Pin on map" selection.

I laid out some competing options for project direction. Some ideas weren't great. For example: removing autocomplete, and using standard address input fields. Autocomplete enabled faster entry and worked a vast majority of the time though. This didn't make much sense. Better options included that Uber style "Pin on map" as a confirmation step. This felt needed, but wasn't the full picture. We still needed to let hosts enter an address before they could confirm the location on a map. For each of these directions, I laid out a rough pitch. That included a quick summary, product changes required, and pros and cons. Thorough documentation enabled quick feedback from my project team and other stakeholders.

We decided to provide a secondary confirmation path for blocked hosts. We'd branch that from the existing autocomplete tool.

There was consensus that we should maintain autocomplete address entry. It almost always worked, and that's great. We'd need a secondary path when it didn't work though.

We broke this direction into smaller, non-prescriptive stories.

User driven stories help us understand what product changes we need. From there we can prioritize how to design, build, and ship the work. The main stories in our project included:

• As a Host, I want a path forward when my address isn't recognized

• As a blocked Host, I to enter my address without autocomplete

• As Turo, we want hosts to confirm their address on a map for guaranteed accuracy

I collaborated with my team to compare directions, and gain clarity on the interface. First we looked at flow architecture. We decided to collect an address first, then have the host confirm the location on a map.

🚫
1. Address & map on the same step.
One step is less steps than two — yay! The map & address could have a dynamic interaction. We could pull an address from Google to reduce friction as a host moved the map pin.

This felt busy though. Should a host adjust the map, or enter an address? The order of operations wasn't clear. It left room for confusion.

🚫
2. Map location, then address confirmation.
We could pull an address from Google based on the map location. That could remove the address confirmation step in some cases.

One glaring problem though: how do we place a map pin with no address? We considered using current location. Lots of the blocked hosts managed cars in more than on location though. We would often guess the wrong location. This was a blocker.

✅
3. Address input, then map confirmation.
We could use the address to make our best guess on the map. This made the most sense. It kept a focused path. It also reduced map confirmation friction as it would let us get that map location right more often.

Next we explored the address input step. We settled on using structured input fields.

🚫
1. Free form entry
Hosts know what their address is. They're the expert. Free form entry would let them enter an address the right way.

We didn't have a great way to parse that free form text though. We could build a way, but that would add a lot of scope. Short of that, we wouldn't be able to make a great guess on the map location. Hosts would often need to adjust wrong guesses, which could erode trust.

✅
2. Structured inputs
This was a common pattern for collecting address from a variety of locales. If the fields were generic, it could work for any address. Generic meant non-localized though. That's a bummer. It wouldn't feel natural for all hosts. It would also leave us with not great fields like "State / Region / Province (optional)".

We chose this option anyways though — it would give us stronger data. We could use that data to make map confirmation easier for hosts. It would also enable more accurate locations for guests. We wanted to localize collection for our major markets though (the US and Canada). If a host selected one of those markets, we could localize the following inputs. This would leave other countries with generic inputs, but build a base we could expand on later.

We nailed down the map confirmation features and interaction last.

How can hosts adjust the pin location?
We debated letting them adjust off the bat, or adding an "Adjust" action to unlock the map. We worried hosts could move the pin by accident without noticing. That would lead to a less accurate location for guests. We opted to add an "Adjust action".

Could we use Google to pull an address in a local format?
We planned to compile addresses in a generic format with the info from the structure inputs. It was possible to pull a better address from Google using the map pin though. In an ideal world, that could bridge that gap between a hosts location and Google's data. This would have added extra scope. We opted to document the idea, and defer it to future iterations.

We shipped a map based remediation path. It included standard address input fields, and a map based confirmation step.

Blocked hosts can assert that they don't see their address if autocomplete fails. We try to pull address components from anything typed in the autocomplete field. Any pulled components get prefilled in the next step — structured address input. We ask for any missing required address components.

Hosts confirm their location with a map based tool. We take our best guess on pin location with information they submitted on the previous step. If we don't nail it, they can adjust the pin. Guests will see the address the host entered, and the pin location they confirmed.

Here’s iOS.

Here’s Android.

We didn’t run into any situations that called for platform specific approaches. Android mirrors iOS in its architecture. We use native components where possible.

And here’s web.

On web, we opted for a modal based flow. We did this with our eyes on the future of this feature: a modal flow could be accessed from other parts of the app for other use cases, like a guest entering an unrecognized address for delivery.

Hosts were 100% unblocked. International revenue jumped by 25%+ in the next few months.

From our Business Development Manager in London, Rory Brimmer:

From a qualitative perspective, it was fantastic. Because of the feature, we were able to launch multiple new markets, including Dubai, which is growing at a fantastic rate accounting for around 20% of international host revenue last month! We no longer have any hosts who are unable to list their vehicles, anywhere.

This was awesome to see. Hosts were no longer blocked, we launched new markets, and revenue jumped.

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

We should make address input more dynamic.
Non-localized addresses make Turo feel like it wasn't made for some users. It leaves room for confusion, and hurts trust. Dynamic address inputs for each country would make Turo more usable for more people. We passed on that functionality for V1 because it represented a huge scope increase. There wasn't a universal source we could pull from. We saw more value in nailing our major markets, and building a base we could expand on in the future.

We should localize addresses for guests.
We compile and display addresses to guests in a generic format.

[Address], [City], [State / Region / Province], [Postal Code], [Country].

This ordering is correct for some countries, but not all. We haven’t gotten direct complaints of this leading to guest confusion. At the very least, the pin location is always accurate. Addresses that aren’t localized can feel broken or foreign though. The ideal tool would accommodate local address formats. We could do this by expanding our dynamic address input logic. We could also let hosts edit the generic address format after we compile it.

We should run usability testing.
It's great that the feature solved the issues. I'd love to understand how hosts are actually using the tool though. What are their biggest pain points? How could we improve the feature?

There's other product areas this feature would benefit.
We only launched this flow for the listing flow. It would be useful in more use cases though. For example: when guests want a car delivered to an unrecognized address.

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

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

Improving marketplace safety by adding positive friction.

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

Setting expectations by structuring airport settings.

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