Challenge & Goals

Prior to every SHARE NOW rental, the user is able to reserve the desired car for free for 20 minutes. They can use this period for example to finish their errands and make their way to the car. Once this reservation time has expired however, the car cannot be reserved again for another two hours, though it can be rented directly.
However, 20 minutes are not sufficient for every use case. From experience, quite often things get in the way that would prevent the user from reaching his reserved car in 20 minutes.

How might we enable users who need more than the default reservation time to extend their reservation and thus start a rental?

Putting the feature into context with a basic customer journey map

Design Sprint

Initial Research

To start work on this feature, we decided to run a design sprint. Before the kick-off, our user researcher gathered some qualitative and quantitative data about our users' current behaviour.

We learned that about 70% of all rentals had a reservation before. Overall, the amounts of reservations and rentals per day were also pretty equal. Through the interviews we also found out that people mainly use the reservation when they rely on car2go and there's a risk of losing the ride. That meant that users already settled on using car2go as a mode of transport and that there's only a small amount of cars around the user's location.

“It would be important to have reservation time from 30 to 90 minutes.”

In remote interviews, we asked users about how long they would like to be able to reserve a car in the morning and in the evening. They largely responded with timeframes from 20 to 90 minutes. One user said: “In the evening there's much higher risk for running late because you're for example with friends at a bar and get lost in conversation. That's why it would be important to have a reservation time from 30 to 90 minutes.”



“How Might We” Questions

One step during the initial design sprint was to align on the most important things the feature needs to do. For this we sat down with our stakeholders and defined some "How Might We" questions.

How might we offer the most convenient option to extend the reservation (minute rate vs. interval/package)?

How might we offer the reservation extension times that fit different use cases?

How might we offer flexibility on the reservation extension?

How might we increase planability for our members?

How might we enable individual reservation time per member?

Usability Testing

First Test

At the end of the design sprint week, we had a prototype which we went on to test remotely through UserTesting.com. The participants of the study were car2go users living in a German or Austrian car2go location. The tasks were to reserve a vehicle, extend the reservation and check the status of the reservation.

The prototype was heavily based on the status quo with only small adjustments to implement the extension feature. We changed the look of the reservation timer and added a + icon next to it. Additionally we implemented one screen for the purchase flow which contained the selected rate (although we test with only one at that time) and one screen for the reservation status. The status screen would only be available if the user had already extended the reservation and contained information about how much time is left of the free reservation or how long the extended paid reservation has already been running – and thus how high the costs were.

The results were that the timer and the call-to-action to extend the reservation (screens 1 & 2) are easily overlooked. Many participants didn't immediately notice it. Although buying the extension (2) itself went smoothly, it generally wasn't understood that the extension was minute-based. Also the status display (4 & 5) didn't make the difference between the free and the paid reservation clear. Therefore we knew that we needed to do at least one more iteration.


Second Test

We went into the second testing with the same screening criteria as the first one. For this iteration we did some bigger changes that included a complete redesign of the vehicle panel (screens 1 & 3). We moved all action items into the panel instead of spreading them on the whole area in an attempt to give the information more clarity. We kept the purchasing screen (2) as it had worked well in the previous test as well as the information screen (4 & 5) for now.

In this test we learned that while the entry point to extending the reservation was a lot more intuitive now, the problems around the reservation status information were confirmed by the second test group. Additionally, it was not even less clear how to get to that status display as the button didn't show enough affordance to be tapped on.

One other issue from stakeholder's perspective was that the redesign of the vehicle panel would result in a lot of work while it was of course preferred to keep development effort as low as possible. As the pros user experience didn't outweigh this issue, we decided to abandon this option.


Third Test

For the third test, we decided to try out some different screening criteria to recruit the study participants. This time, we showed the prototype to people from a North American car2go location to see if there were any differences. Design-wise, we went closer again to the first iteration that was based on the status quo. We kept the minute rate approach but decided to cap it at a maximum of thirty minutes. The user would still pay by the minute though. That way we could keep the timer counting down, hoping to increase understanding of the reservation status.

However, we ran into similar issues as we did in the first test. The entry point to the feature wasn't discoverable enough. Plus, even though we had attempted to simplify the information display, the reservation structure still wasn't clear enough.


Minimum Viable Product

Since all of the tests weren't completely successful, we decided to run with a lean approach and release a minimum viable product with small development effort in order for us to learn fast about the acceptance of the feature.

For the first iteration, we decided to go with extension "packages" instead of a minute rate. This meant that users would pay a fixed amount of money for a fixed amount of time. Even though we knew from the initial study that this wasn't necessarily the user's preferred method, it kept implementation effort much lower as we could rely on systems that were already in place.

In collaboration with our Business Intelligence team, we decided that users would be able to extend their reservation by 15 additional minutes for 1,99 €. This extension could be bought multiple times, so that the reservation could in theory be extended infinitely in 15 minute steps.

Additionally, this meant that we could get rid of the information screen as the timer already conveyed all information around the reservation time. Through some quick interviews with in-house developers, we learned that this concept was also better understood than the previous one.


Rollout

The rollout of the feature followed in several steps so we could learn about the acceptance of the feature and tweak things if necessary.

First we launched Stuttgart and Hamburg on 23rd November 2018. When we saw that the feature performed better than expected, we launched in the remaining German regions three days later and another week later in all the other European locations. At that point, we had about 1’000 reservation extensions per day. As the numbers still looked better than anticipated, we rolled the feature out in North America as well, so that reservation extensions would be enabled in every car2go location.

With the rollout in the North American region as well as a generally growing amount of customers, the number increased further to 2’000 to 3’000 extensions on average as of today – the lowest day of the week usually being Sunday and the highest one being Friday.


Lessons

When we launched the feature, the estimation was that we could gain around 300’000 Euro per year. Today's numbers however actually translate into a business case about 5 times the size of that. Therefore it can be said that the feature exceeded expectations as was a success.

The key to this success was the lean approach of releasing an MVP instead of spending lots of time and resources on finding a solution. However, there were no further iterations happening after the initial release, thus probably losing some of its potential.

What I learned

Build quick MVPs, learn from them, and iterate on them.

Do testing, but don't rely only on it.