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

🚀 Shipped November 2019
📱 iOS, Android, and Web
✏️ Lead Designer

Trust is the core of our marketplace. Turo’s guests are less likely to book cars with low quality photos that don’t inspire confidence. In other words, a hosts ability to take great photos can make or break their success on the platform. I led design on a team effort to overhaul the experience of adding photos to new cars. We built tools to guide hosts to take choose the right shots, and execute them. We reduced low quality listings, and contributed to a 3%+ checkout conversion lift.

Bad car photos diminish trust, and hurt hosts chances of success.

If a guest can’t get a good understanding of a cars quality from it’s photos, they’re unlikely to book it. The difference between one photo or three has a non-trivial impact on a cars chance of getting booked. The lack of trust from bad photos can also have a market level impact. That's especially true in places with fewer cars where each of those options is more visible.

Our executive team wanted to set our newer markets up for success. They directed our UK & Germany business teams review every new listing for quality. The team would restrict low quality cars until they could coach the host on how to improve. This rough experience had good intentions, but no product support. The result often led to frustrated new hosts leaving the platform. The biggest contributor to those restrictions was bad photos (stock photos, blurriness etc). They could account for upwards of 90% of restrictions on a given day.

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, and web). We managed expectations with our UK & Germany teams, and our Host product domain. I got valuable feedback from other members of the design & product org.

We aimed to build trust by helping new hosts take photos that inspire confidence in guests.

Photo quality is subjective, and tough to place a direct measure on. It’s not impossible though! I established some indirect measures with the help of my team. This enabled to move forward with a shared understanding of success.

Primary metrics

1. Restrictions due to photo quality
   We want these to go down. Higher quality photos should mean our UK & Germany teams restrict less cars.

2. New listing activation rate and time
   How many new hosts getting booked, and how long does that first booking take? If better photos boost confidence, we’d want to see activation rate to go up, and time to go down.

Counter metric
Impact on listing flow completion rates
The listing flow is where car owners add their cars to marketplace. They add photos before completing that process. Any changes could add friction (positive or negative), and lead to hosts abandoning the process.

I needed to understand the problem space. I did that through research, market analysis, divergent brainstorming, and unmoderated testing.

A recent study on the usability of the listing flow by our Research Team had a very relevant takeaway:

Hosts want more guidance, particularly around which photos to take.

We gave them almost zero guidance around photos, so this was understandable! This was a glaring pain point off the bat. We wanted to do our due diligence though. We needed to explore other directions that could impact our goal. 

I first completed a market analysis of how other products guide users to take the right photos. Next I went through a process of individual and formal team brainstorming. these tactics helped identify and explore a list of 10+ divergent project directions. I laid out a rough elevator pitch for each direction with feedback from my team. This included required product changes, rough scope estimates, and pros / cons.

We also wanted to supplement our knowledge on the initial pain point — lack of guidance. I ran an unmoderated user test on usertesting.com. I tested three clickable prototypes with potential hosts. Each had a different type of guidance: tips, specific photo prompts, and example photos. Our goal wasn’t to pick one of these types of guidance. We wanted qualitative feedback indicating how new hosts respond to different educational tools.

We learned our hosts wanted more guidance. Specific photos prompts eliminated frustrating guesswork, and example photos boosted host confidence.

This supported our initial suspicion — providing better guidance would empower hosts. With those takeaways in mind, my team aligned on a specific project direction.

We decided to prompt hosts to take specific photos. We'd help them execute with tips, camera overlays, and good photo examples.

In other words — tell hosts which photos to take, and give them the tools to do it themselves. There was an allure to some of the shinier solutions we considered. For example: alerting hosts of auto-detected blur photos — super cool! My team felt a better first step would be to provide this baseline level of guidance though. We used what we learned to foster buy in with our stakeholders & product leadership. We strengthened our case by comparing and contrasting other directions considered.

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. A couple stories in our project included:

• As a Host, I want to know which photos I should include. 

• As a Host, I want to know how I should align my car when taking photos

While planning, it was obvious our iOS & Android flows were too “upload from gallery” focused. This conflicted with our camera focused project direction. We knew we needed to rethink that architecture (see the diagram below). This presented some opportunities for incremental shipping too. We could ship an introduction screen with new tips. We could also ship a reshuffled flow architecture with a prioritized camera path. That would buy more time to refine the new camera experience.

🚫 Current — Gallery First

🚫 Proposed A — Camera First

✅ Proposed B — Two Paths

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

Explore, document, get feedback, repeat. That’s where the magic is. Informal feedback & formal design critiques helped me refine the interface and interactions. Transparent documentation of my process let me share rationale and fill in gaps on the fly.

We shipped stronger guidance on all platforms. The star was a guided camera experience on iOS and Android.

I used motion to ease the transitions between each step.

We request six shots in an order that guides the host in an organic order around and then into their car. We localize the content in right hand drive countries by mirroring certain overlays and example photos. There was a balance to strike here: give guests enough information, but avoid too much host friction. We landed on these six shots through rapid fire internal feedback. It felt like a good starting point that we could test & iterate on later.

Our initial plan included a more robust carousel component. It used motion to create a sense of progress and accomplishment through the flow (see below). The carousel would have doubled as a navigational element as well. Hosts could move forward or backward to view and retake photos.

Due to late in the game priority shifts, we scaled back that experience. Company leadership summoned our team for an effort to address a shortfall in revenue. This disappointed my team and I, but understood the severity of the need. The timeline to wrap up contracted from 1.5 months to 2 weeks. I presented my team with a range of options to cut scope while still delivering on our projects goals. The polished carousel, while valuable, represented the highest engineering scope. It wasn’t something we could get built & tested in the compromised timeline.

We chose example photos that felt polished, but achievable.

Overlays on the camera helped hosts nail every shot.

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 with some trivial native styling differences. We were able to match the camera UI with 3rd party camera libraries Turo was already using.

And here’s web.

We leaned on the stronger content introduced elsewhere. Without a camera, this meant tips and example photos. This was a much lighter weight approach than the apps. It enabled quick delivery of project goals. It also let us focus more energy in the mobile experience where a majority of our hosts list their cars.

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

Usability testing!
Due to the accelerated project ending, we weren’t able to secure resources from our Research team. That meant no usability testing of the final product before launch. Turo’s Research org doesn’t empower designer led research beyond simple prototypes. That didn’t feel like the right method to test our end product. We compensated by leaning more on internal feedback. We stress tested the experience by sharing a test build, and testing in the real world. We centralized feedback in a single doc, and prioritized fixes based on impact.

I made sure to coordinate with the Design Director of our Host Team after though. I evangelized the need for usability testing, and submitted follow up research request.

Let’s deliver the full carousel.
I’d love to see the team build out the more robust carousel experience. We still feel confident that our V1 delivered on the goals of our project. The more fluid interface & motion would elevate the experience though.

Customized overlays & example photos can help the flow feel more natural.
At the point of taking photos, we already know what category of vehicle a host is listing (sedan, van, SUV etc). In the next iteration, I’d love to use custom overlays and example photos per vehicle type. Our existing overlays & example photos are still a helpful reference in how to frame a shot. Customizing guidance per vehicle type would help the flow feel even more personalized.

We can enhance the web experience.
I would have also loved to provide a prominent call to take photos in our app with the guided camera experience. This was de-prioritized due to some tech complexity in deep linking to that flow in the apps. I also explore more web-native solutions. Those included imposing overlays on uploaded photos, and adding a photo checklist. We opted to keep the first iteration lightweight though. That let us shift our web engineers to other priorities, and focus on the mobile experience.

The guided camera can add value elsewhere in the product.
It could be useful when managing photos on existing cars, or taking photos during trip check in/out. The use cases of each flow would need some adaptations to what we built though. Managing existing listings photos might not mean taking a full new photo set. A time sensitive key handoff won't always allow a careful photo taking process. We had moved away from our existing “one size fits all” upload experience with intention. We wanted something custom fit for taking photos of a new listing. Many elements of the new camera experience could help improve those flows as well. We should introduce them elsewhere, but change them to fit each use case.

That’s the end of that case study.

Here’s some other work I’ve done:

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

Setting expectations by structuring airport settings.

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