Drivy.com | App review

A neat user experience. My proposals to (im)prove it.

I recently interviewed at Drivy Paris office for joining as product manager. Drivy is a carsharing app allowing you to rent your car or to rent the car of some individual around you.

I won’t joint the team (not my choice ;)) but I’ve learnt a lot during the process. I propose here to share the app review I’ve made for the first part of the application process.

Drivy ask you to answer 3 simple questions: What do you like about our product? What you don’t like in the app? What would you improve first? My answers below!

With insight (it has been nearly a month I wrote that) what I would do differently:

• Step back more and write more from a macro perspective: how I think the product should evolve according to Drivy vision of mobility
• Link to online mock-ups in Invision (I sent them in .png …)
• Get into more details regarding the analytics to be followed

Have you done the same exercise on the Drivy app or are reviewing apps in your free time? How have you or would you do it differently? What do you think of my work below? Feel free to spam the comments !

Good luck to you all! Peace

What do you like about our product?

Overall features

• Drivy open (for readers: allows you to open car with your smartphone, no need to meet the car owner)
• Electronic contract (for readers: no paper any longer when you pick up and return the car)
• ‘smart match’ feature (for readers: the platform sends requests on your behalf similar to the one you made to maximise your change of finding a car)

Renter | Web app desktop — FR — Search results view

• The split between the time & geography of rental (picks_search_box black on the top) and the characteristics of the car (picks_filters_panel white on the left)
• The structure the colour code brings to information: on the search page black for date & geo, white for car features, individual card for each car and the grey fixed panel inviting you to select at least 3 cars
• The lateral panel which show on the right of the search results view when one clicks on ‘plus d’information’
• The button ‘suivant’ which fills third by third in fluo green when the cars are selected
• The icons to help you select the type of car (much faster than reading the text)

Renter | Android mobile app — FR

• The overall design: easy to get info, easy to make choice
• The ‘programme’ font, very easy to read on mobile
• The fluidity of the switch from results displayed by list to results displayed by map
• The ability to use a ‘drivy open’ filter
• The short user flow: ability to rent a car in 4 clicks (once profile created) versus 6 clicks on web app desktop

What don’t you like about our product?

Overall Features

• Smart match: not being able to select the length (5, 10, 15) and the metrics (‘marche’ make sense in a town, kilometers make more sense for non urban zone etc.)

Renter | Web app desktop — FR — Search results view:

• Not being able to search a specific car brand
• The price slider: ‘150 € et plus’ is not clear
• The price slider: steps are not regular (5 euros steps put one finds 19€, 54€)
• The fact that you don’t clearly understand between clicking on the card to select if for an enquiry or clicking on it to have more info on the car and the user
• I do not get how are the elements displayed, is it by price first, by distance first, it seems it’s a mix, and nowhere it is explained to me (I checked the FAQ)

Renter | Web app desktop — EN & GER — Search results view

- The map does not update in real time when you move over it

Owner | Web app desktop & android app — FR

• The fact that you’re not informed of the decrease in price for longer than 1 day rental when you list your car. There is a message under the price slider but not much clear, you need to get to the price ‘tab’ to realize the degressive price.

Renter | Android mobile app — FR

• Not being able to sort the displayed results by distance (although the map allows to more or less have a visual clue about it)

What would you improve first?

Here I made an assumption since I do not know the internal priorities of Drivy.

I assumed that on the french perimeter the priority is to make the already large user base to work, which translates mainly in increasing customer engagement (It’s voluntarily a bit over simplistic..).

Project 1 (no mock-ups)

OPTIMIZE DESIGN FOR SPEEDING CAR SEARCH

HOW: some incremental improvements could make the app more clear for the user

• Web app: add a hover effect (underline) on the distance component (for instance: ‘3 km’ of the bottom part of the card so that the user understand that clicking will led him to have more info on it.

It will also make clearer the difference between clicking on the car card picture and on the white bottom of the card. Clicking on the car card picture allows to select the car for a rental enquiry. Clicking on the white bottom of the car card allows to have information on the car/owner/rating.

• Web app: change the ‘150€ et plus’ for ‘tous les prix’ (as it is in android app)
• Web app: make the integer in the slider increment of 5 euros (as it is in android app)

EXPECTED IMPACT: medium

COST: low

METRICS to watch: time on task (task defined as search and booking request sent), task success rate (task defined as above)

Project 2 (see mock-ups 1, 2 & 3)

PROMOTE ‘DRIVY OPEN’ AS A MEANS TO REDUCE THE TIME FOR A RENTER TO BOOK A CAR (FROM SEARCH TO PAYMENT)

! Assumption made: the car owner are highly likely to answer positively to any rental enquiry on a car equipped with ‘drivy open’

HOW:

Emphasize the use of Drivy open

• Web app: add a ‘drivy open’ option on filter of search results (see mock-up 1)

• Android app: move-up the ‘drivy open’ option above the ‘category option’ (see mock-up 2)

Highlight cars with fast answer time (allow user to filter search results based on answer time)

• Android app: be able to list search results by price / distance / time to answer / drivy algorithm (default display) (see mock-up 3). Assumption made here is that it will ease use of the product and feeling of ownership of the product.

EXPECTED IMPACT:high

COST: medium — For the sort, Drivy already has data on price, distance, average time to answer, hence the sort should not be that pricy. Speed of the query may be tricky and sorting results like that may result in less car owners answering to the user. It consecutively could lead to less likelyhood of concluding a rental.

Metrics on Drivy search result recommandation impact on rate of booking should be carefully analysed before this project is started (if Drivy algo recommendations showed strong improvements in rate of rentals over years this feature value is highly questionnable).

METRICS to watch: time on task (task defined as search + booking request sent + booking paid after positive answer received from owner), net promoter score

Project 3 (no mock-ups)

INCREASE SUCCESS RATE OF A BOOKING REQUEST

HOW: by making the smart match feature tailored made to the user needs.

• Web app:

Let the user selects the length of time: 5, 10, 15 etc.

Let the user selects the metric to add to the length: ‘minutes à pied’, ‘minutes en voiture’, ‘kilometers’ etc.

A 15 minutes walk make sense in a city, not in less dense area where a 10 minute car ride may make more sense. In a city, 15 minutes is a long time (I’m living at metro ‘Pyrennées’ in Paris France, I think in 15 minutes I’m getting to metro ‘République’ which is really not the same neighbourhood).

• Android app: harder to apply on bookings as they are made one by one instead of by batch (see webb app invitation to select at least 3 cars). References of smart match have to be updated after each new booking request for a given set of dates and car.

EXPECTED IMPACT: medium — Calendar check and Drivy algorithm for display of available car (speed to answer request, rating) is the main factor in the probability of a successful booking. Smart match is hence evaluated to have a low / medium impact.

Yet for users in non urban area it will make sense to have an option that really means something.

COST: medium. Need to update back-end, to change front-end view to add 2 input fields (length and medium (walk, car, horse, camel). It makes the user flow more complex.

METRICS to watch: task success rate (task defined as search + booking request sent + booking paid after positive answer received from owner)

Project 4 (no mock-ups)

REDUCE THE TIME FOR A RENTER TO DRIVE A CAR (FROM SEARCH TO DRIVING THE CAR)

HOW: Work on a ‘rent now’ option: for user needing to move fast, an option with car available in the next hour can be highly valuable.

EXPECTED IMPACT: high. It gives much flexibility to the user for short notice departure, unplanned few hours needs etc.

COST: high — A whole process has to be designed by Drivy to define what is a ‘rent now’ car. Car owner will have to input that data on their profile. Besides data needs to be collected on the same day bookings to see their rate of success and the need for that ‘rent now’ option. Maybe same day booking request have already a decent fullfillment rate.

METRICS to watch: task success rate (task defined as search + booking request sent + booking paid after positive answer received from owner) on same day booking request, net promoter score on this segment of user with and without this feature.

Project 5 (see mock-ups 4 & 5)

INCENTIVE USER TO RENT A CAR BY REDUCING THE INFORMATION FRICTION ON THE ROAD TO GET TO A GIVEN CAR

HOW: give the user more info upfront on how he will get to the car.

Web app:

• For non urban zones: add a ‘livraison du véhicule’ option because the distance to get to the car really does not have the same impact than in a city (in fact when check over the car listing commentaries, it seems that a lot of car owner are delivering the car) (see mock-up 4)

• For urban zone connect with citymapper to display on search results the delay to reach the car

Android app:

• For urban zone connect with citymapper to display on search results the delay to reach the car (see mock-up 5)

EXPECTED IMPACT: medium — For the user knowing upfront that the car can be delivered to him may entice him to use drivy more often. In a qualitative study we should first assess whether or not car delivery in non urban zone is a lot of hassle.

COST: high — the connection with the citymapper API can slow the display time of the results page which is today very fluid. Besides we would have to make heavy UI choices on which information to display when clicking on the icon, either opening the citymapper app or web app to display the details (take our user out of Drivy, bad), or to open an info window inside our app with the info (better) etc.

METRICS to watch:

• Urban zone: Click rate on citymapper icon ; task success rate (task defined as search + booking request sent)
• Non urban zone: are cars with this option rented more than other car ?