Unavailable pet sitters is a tough issue at Rover. An owner contacts a sitter to request pet care, discovers they're not available for those date(s), and is forced to find another sitter. Although sitters have an availability calendar in their profile, each sitter uses it differently and it's not always up-to-date—assuming owners find it. This creates undesirable churn, frustration, and damaged trust.

The backups concept was created to alleviate part of this multifaceted issue and increase overall conversion. My team and I audited the existing experience and analyzed relevant data to generate a few options for systems brainstorming.

Data indicated conditions where conversion failure was most likely to occur relating to time elapsed from when an owner contacts a sitter and a sitter's response or lack of response. We also knew likely outcomes when the sitter responded to the owner that they were unavailable.

Availability is a complex issue connected to various points in the ecosystem. We could try improving the calendar, setting better expectations with sitters and their availability, etc. We decided to scope our efforts to a relevant user scenario we hadn't tried before: instead of leaving owners hanging when a sitter is unavailable or not responding, what if we automatically helped them?

Our goal was to see if users would (a) select backup sitters and (b) would the backups convert into a successful booking, thereby improving overall booking rates and mitigating the availability issue. Test quickly and see what we learn.

We ran an A/B test for the first iteration, where we asked owners if they want to automatically (A) or manually (B) contact any backup sitters they specify when contacting a sitter if that sitter doesn't respond.

(I was hoping to ask owners to optionally pick backup sitters at the conversion failure point, but this was outside our engineering limits and timeline.)

Once launched to our test markets, user adoption rates were mixed and not where we'd hoped. More users selected backups in the manual variant but more backups were contacted in the automatic variant. Each survey and learning gathered from users indicated they'd be enthusiastic about our approach, so there was a disconnect somewhere in our solution, what they claimed they wanted, and what they actually wanted.

We dug back into the data and talked with more users. Potential improvements included more sitter information for owners to make an informed choice, include new sitters they hadn't used before as backup choices, and modified the trigger conditions for this feature.

The big user challenge here was understanding what information owners needed to see and how to display it. Trust and safety for owners selecting sitters is vital, but we also didn't want owners leaving the booking funnel to explore full sitter profiles. To address that, we ran a user test to determine which criteria users felt were most important, and paired that with known data. After examining various versions, and given extreme technical constraints on the sitter search cards in the UI—we added a repeat clients chip to the card and enabled a richer, but mini, profile view. (We also identified, in future versions, we could make the mini profile extensible for the rest of the company, which would spawn various design discussions.)

Iteration 2 was testing more favorably than iteration 1. Resulting data pushed me back to my original hypothesis: we should be asking owners to select backup providers only when the sitter claims they're unavailable or doesn't respond. Then owners are never left hanging, and selecting a backup provider would make more sense at that stage. With such a list, we could illustrate which sitters we believe would be a good fit, which could eventually lead to a purely automated approach.

For the Rover grooming business line I designed, we created a calendar system where owners could view and pick from available grooming times while booking online. After, we added the requirement that owners could also choose to book specific groomers they'd used in the past.

Any component we used needed to be mobile-optimized (a natural priority for the company based on our platform usage rates). I also kept these in mind:

I whipped up a few prototypes to discuss with the team. The control would change the calendar to display either all available grooming times or those of a particular groomer. I also ran them by the design system owner to see which solutions could be reasonably created as a new design system component.

The concept was received very well by the design team as a reusable component and successfully incorporated into the design system. The grooming team was also happy, and excitingly, also our users.

This was the first significant project I worked on in the company. Rover sends report cards to owners after sitters complete certain services (e.g., dog walks). The goal was to strengthen owner trust and boost delight by having sitters keep track of a pet sitting experience in real-time and send proof after the fact, with photos, while making it shareable to boost customer engagement on and off platform.

The original concept was to have sitters only track dog walks, one at a time. We had a simple, sleek design. But the business wanted the project to be more inclusive and support walking multiple dogs, across multiple service types, with multiple owners, all of which can start and stop at different times. It could become a hub where sitters go to handle all of their tasks for a day. Great concept, but turns out it was technically impossible to fully realize it at that time, and we were left with a complex mishmash of features.

I inherited the project around that realization point. Myself and the team needed to complete the project, and we didn't have time to go back to the drawing board. So how do we accommodate this complexity while keeping it simple and useful for our users?

To simplify as much as possible, we consolidated all of our existing efforts to prioritize which were most beneficial to our users and the business. Given the tight timeline, we scoped our work to the sitter side of the report card system. We needed to (a) clarify how the concept worked, (b) when to use this feature, and (c) how to consolidate related but different services being active at once.

To clarify the concept, we created a highlight tutorial illustrating broad strokes of the functionality. We wanted to do a feature walkthrough, but we didn’t have the technical bandwidth.

To clarify when the feature should be used, we utilized operations and marketing to contact sitters as well as include instructional content in the empty state of the feature.

And to consolidate active services, we created a “visor” to keep all active services grouped together.

This was a prime example of feature bloat. The design team was afraid of this early on but wanted to ensure the business could satisfy its goals. When I joined the team and in future iterations, we were much more militant about keeping focused and simplifying. Today, it’s been simplified even further to be included as part of the main sitter dashboard flow—exactly where we felt it should be originally.

Fortunately, owners love the result of this work. They can see their pets being taken care of and have a history of that happiness. That's the essence of a great Rover experience.