Setting expectations by structuring airport settings.

🚀 Shipped September 2017
📱 iOS, Android, and Web
✏️ Lead Designer

Airport delivery trips represent a huge chunk of Turo’s revenue. Despite that, our team hadn’t updated the product experience in over two years. I led design on a team effort to add more structure for our guests and hosts. Our effort supported continued growth of airport revenue. However… this is also a case study on how a good decisions don’t always have the desired impact. This project failed to move quality metrics in a meaningful way. It taught me to balance big bets with smaller wins, and validate thoroughly.

Airport trips represent 40%+ of Turo’s revenue. We hadn't touched the experience in two years though.

Our MVP airport product let hosts opt into delivery to nearby airports, and set a price per airport. We didn’t provide guidance on how to handle that experience though. There was no direct facilitation of planning between hosts and guests. This often led to complaints from guests.

I led design on a multidisciplinary team.

My project team included a product manager, an engineering manager, and cross platform engineers (iOS, Android, web, and back end). We managed expectations with executive leadership. I also collaborated with the wider design team.

We aimed provide a higher quality delivery experience. We hoped to support continued revenue growth, and boost our quality related metrics.

Primary

1. Percentage of trips with 5 star ratings
   We want these to go up at airports.

2. Support calls about airport trips
   We want these to go down.

Secondary

1. Positive feedback
   Our review system lets guest select positive attributes about their trip. We’d want more guests to not “Pickup & return” as positive for airport trips.

2. Repeat usage of delivery
   We want more of this. With better experiences, guests should continue to use Turo at airports.

We conducted research to identify pain points.

Our Researcher Michelle ran point on this. My product manager and I helped plan and execute each component.

We surveyed hosts.
We solicited feedback from 100 Turo hosts currently offering airport delivery. We wanted numbers on how they currently approach airport delivery. We offered some free form qualitative inputs as well.

We interviewed guests and hosts.
We wanted to dive deeper into what we learned from the surveys. We interviewed guests who had recently used delivery. We also spoke with hosts to understand their mental model for airport deliveries. 

We reviewed airport trip reviews from guests.
We compiled a giant Google Doc of these. We tagged common complaints to get a sense of scale.

We identified misaligned expectations about the delivery process as a primary pain point. We learned most hosts stuck to a preferred delivery plan. We also learned multi-car hosts were generating a disproportionate amount of revenue.

Misaligned expectations are a bummer.
When a guest booked an airport trip, they often had preconceived notions about how it worked. For example, they might expect the host to meet them curbside. Different hosts had different plans though. They might meet the guest curbside. They might leave the car in a parking garage. They might even ask the guests to Uber to a lot outside the airport (yikes). Some hosts communicated this in their car descriptions pre-booking, but not all did. This meant surprises for guests how the hosts wants them to meet. That might happen right after booking, or — worst case scenario — as they’re waiting for the car to show up.

Hosts usually run the same routine for each trip.
This felt like an opportunity to address misaligned expectations. Surfacing a hosts preferred delivery method could help avoid surprises. One key sub-learning though — a host might prefer a different method per airport. That diverged from the offering in the existing product.

Hosts with more than one car have a huge impact on airport revenue.
After talking to some multi-car hosts, we dove into the data a bit more. It turned out they represented a disproportionate chunk of airport trips. We knew we’d need to keep that cohort top of mind. That way we cold avoid decisions that might have an outsized effect on airport revenue.

We decided to set clearer expectations between hosts & guests. 

Sharing plans for hand off at airports had the potential reduce frustrating surprises. This addressed guests primary pain point, and aligned with current host behavior. We knew some hosts preferred to wing each trip, and this might deter them. Lack of clear plans caused bad experiences though. Turo views itself as an active hand in the experience — we’re okay stepping in to curb harmful behavior.

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

These helped us understand what product changes we’d need. From there we could prioritize how to design, build, and ship the work. A couple stories in our project included:

• As a Host, I want to set a delivery method for each airport I offer

• As a Guest, I want to know how delivery works before booking a car

That translated into a rough set of product changes:

1. Structure hand off methods. Offer host settings for each airport. Guide hosts toward the choices guests prefer.

2. Inform guests. Let them know how hand off will work before they book a trip.

3. Reduce friction. Keep multi-car hosts happy by exploring shortcuts to batch apply settings.

I dove into wire framing. I worked my way toward polished interfaces & interactions through an iterative feedback process.

Through that process we identified trade offs and explored options. I documented my thought process, and solicited feedback from my team and others. I also conducted formal crits with the design team.

Accommodating more settings.
Current controls for each airport existed in a single static view. We needed architectural changes on desktop & mobile to keep to UI focused.

Systematizing rides to & from the airport.
We considered outright banning these. Most hosts relied on them though, and the team was wary of reducing airport adoption. We compromised — we’d have hosts advertise this up front in hopes of curbing the behavior. We’d also try to guide hosts away with UI interventions.

Maintaining “per car” airport settings.
There was a push to transition delivery to a host level setting. In other words, turning on LAX would enable it for all your cars. This worked for some hosts. Research had indicated hosts with more than one car vary price by vehicle though. We decided to keep the “per car” paradigm, but offer a new path to copy settings to other vehicles.

Simplifying guest communication.
We needed to translate host airport settings into digestible summaries for guests. The combination of settings created a huge web though. I worked with engineers to compile settings into shareable summaries.

We shipped structured airport delivery settings for hosts. We shared a delivery summary with guests before & after booking.

Here’s web.

We transitioned each delivery option into an accordion pattern to avoid information overload. That let us surface status up front, and progressively reveal the settings a host was seeking. We built the flow using existing web UI components & patterns.

Here’s iOS.

We created child pages to explore settings in a more focused way. We surface status early in the flow, and let hosts dig in from there. We relied on a combination of native UI & reusable Turo iOS components.

And here’s Android.

Android mirrors iOS in it’s architecture. It also relies on a combination of native UI & reusable Turo Android components.

We let hosts apply their airport settings across more than one cars.

We present a prompt after they save their settings. For hosts with two cars, it’s one click to apply settings to their other car. For hosts with 3+ cars, they can select which cars to apply settings to.

The good

Steady growth of airport delivery.
Revenue and adoption continue to climb. This was heartening, but not the noticeable uptick we had hoped for.

More scalable infrastructure.
Our changes supported more custom settings per location. That new model set the stage for a later, more impactful projects. For example, enabling delivery to non-airport points of interest (hotels, train stations etc).

Tools for fleet hosts.
Allowing hosts to copy settings to other cars was our first dip into fleet management tools. It wasn’t a scalable execution IMO, but it worked for this project. It enabled us to make this change without impacting revenue by frustrating hosts.

The neutral

Quality metric stayed flat.
The share of airport trips with 5 star reviews didn’t budge. That was disappointing. I believe our lack of usability testing on our execution was a driver. We received feedback after that guests were still surprised by hand off at airports. It seemed our display wasn’t visible enough in the booking flow.

Resources allocated didn’t line up with impact.
This project ran over our intended timeline. The lack of impact from a metrics standpoint created a perception that the effort might been a wash. I don’t fully agree – our changes unlocked more impactful projects down the road. I definitely understand the perception though.

A couple issues fed into the scope miscalculation. Our team understood the individual changes well, but lost track of the bigger picture. Some things weren’t built in ways took the full spectrum of changes into account. That led to wasted time. This was a communication issue between myself, my PM, and our engineers.

This project was a huge learning opportunity for me. It helped me fill in gaps in my process.

Sometimes you have to fail to succeed. This project taught me to a few key things.

1. Balance big bets with small wins. Look for value you can deliver along the way. The finish line might be months out, but you can often create impact today.

2. Validate, validate, validate. More than project direction – execution too. This feels like a no brainer now. This showed the cost in concrete terms for me.

3. Don’t lose sight of the big picture. It’s easy to get lost in the weeds on large, strategic initiatives. I create guard rails with shared definitions of project success now. “Take a step back” as the cliche goes. 

4. Show, don’t tell. A set of static screens isn’t enough. I use tools like prototyping to show how everything connects now. Telling can only get you so far. 

I’m glad I had the opportunity to learn these lessons. I internalized what I learned, and my process is stronger for it.

That’s the end of that case study.

Here’s some other work I’ve done:

Building trust by coaching new hosts on how 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

Allowing hosts to list & earn anywhere.

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