Challenge & Goals
The merger of car2go and DriveNow into SHARE NOW meant for us as a design team, that we needed to turn every stone in both apps to optimise the user experience for the new product. One of aspects stones was the in-app experience during a rental. Something very special about this part of the customer journey is that the app is barely used since the user's main touchpoint during a rental is the car. The app is mainly used for ending the trip and looking for support, but it isn’t kept open throughout the rental. The next specialty was that it – although the project is referred to as Rental Screen – it is a collection of multiple screens. Included were for example also the Help Screen as well as the rating at the end of a trip. The car2go design was actually one of my first projects when I joined the team as a working student in 2015. However, the product has gotten a lot more complex since then. New features were added such as different car types and security measures. The elements were only added onto the existing screen though and it never got the overhaul it needed. The redesign finally offered that opportunity.
How might we optimise the in-app user experience for customers during a SHARE NOW rental?
Since the project covered a broad range of topics, we narrowed it down to 3 main goals:
Improve the visual and informational hierarchy
Provide more flexible and contextual information
Make it ready for future changes
Throughout the project, I got massive help from Florent Gouëllo, a designer who had just joined the team. He guided both us as well as the responsible Product Owner through the design process and taught me a lot of things along the way which I've added to my toolbox since. The project started with an analysis of the current car2go design as well as this of our main competitors at that time: DriveNow and Sixt. We came up with a long list of pain points per service and narrowed them down into a couple of clusters: Layout & Hierarchy, Information, Usability, Support & FAQs and Rating. Afterwards, we translated these clusters into Jobs To Be Done to define the scope as well as the focus of this project.
Jobs To Be Done
When I'm in an accident I want to find a clear CTA so I can call customer support.
When I notice a damage I want to find a clear CTA so I can deport this damage.
When I'm at the end of my trip I want to find a clear CTA so I can end the rental.
When I'm in the ride I want to find important information at a glance so I can focus on driving and don't need to spend my attention on the phone.
When I'm in a rental I want to how long my rental has been so far and find out about additional fees apply so I can expect what I'll need to pay.
When ending the rental fails I want to get clear information and instructions so I can end my trip.
When I need to explore the map for park spots or gas or charging stations I want to be able to enlarge the map so I can see a large as possible area and can find things faster.
When I need to refuel station I want to find instructions on how fuelling works so I can refuel the car.
When I'm about to start my first rental in a car model I've never driven before I want to get instructions on how the car works so I can avoid having trouble with the car during the trip.
These considerations led into the first round of wireframing. For this, we again invested a lot of time in researching what competitors are doing. This time though, we looked outside of the car-sharing space and looked for analogies like music or running apps because the basic concept behind media players is not too far from that of a running car rental. Derived from these patters we worked on wireframes for our rental system.
We reviewed these wireframes after about a week and voted on the ideas we liked. These were refined for a second iteration with the goal of ending up two paper prototypes that could be tested in-house with car2go employees.
The testings showed that both concepts had good ideas, but that there was no clear winner. So we went back to the drawing board for a third iteration to see how we could merge both concepts into one. We tested this third iteration again with some in-house employees and learned that we were actually on a good way. Based on the learnings, we kept defining the concept, translated them into final designs and made sure to keep all key stakeholders in the loop throughout the design phase.
The final prototype could be split into three different parts:
1. The rental 'hub' which contains information about the active rental
2. The help section which users could enter if they need support with something
3. The rating at the end of a trip
The rental screen is the core of the project. For that one, we decided to strengthen the existing concept of having cards to display information. However, we wanted to make the concept more scalable so multiple cards could fit the screen, much like Google Now does for example. That way we could improve the messaging and status display by showing more than one card at a time – for example the rental status, instructions on how to charge an electric vehicle and the information that the user is outside of the home area and cannot end the rental there.
While already before it was possible to stack multiple cards, the screen wasn't scrollable and it covered up the map in the background. Hence we needed to move the map somewhere else and decided to give it the whole screen estate instead. "Hiding" the map behind a button of course meant that it was way less obvious. This decision however was based on qualitative research we've done before where we found out that the map doesn't provide too much value in this situation. However, it was still necessary to have accessible in order to find park spots or fuel stations.
Having multiple cards also meant that we needed to have some sort of prioritization to determine in which order to show cards.
We assumed that the information of the user being outside of the home area was the highest priority. After that came the message that the engine has been secured and needs to be re-enabled by the user. Third was the message that the car battery is low (only displayed in electric vehicles). The reason this wasn't higher up was because the information is also displayed inside the car itself and the app would only be the secondary touchpoint. Below followed the rental status (time and distance driven), the cleanliness rating of the car (taken over from the status quo) and lastly the vehicle information.
The second part of the project was to improve the help-related topics in the application. In the car2go app, they were scattered in many different places. The HowTos for example were placed on the rental screen with other buttons leading to the damage reporting and calling customer support, while the FAQs were only accessible through the main menu.
Talking with stakeholders during the project, we also learned about the main reasons people call customer support for and that many of those calls could be prevented with some better in-app explanations. Therefore we decided to merge all of those topics into one single screen and simply calling the entry point on the rental screen “Help”. In the concept, this help screen would contain the question to most asked questions during a rental and link out to damage reporting and FAQs. We still included a button to call customer support of course and made that sticky to the bottom right for best accessibility, similar to Android's concept of the Floating Action Button.
Finally, we looked at improving the offboarding – meaning the moment the rental has ended. As a first measure we included the pricing information and some basic statistics like how long the rental was in terms of time and distance.
Mainly though, we were looking into improving the process of rating the trip. While DriveNow didn't have such a feature in the application at all, in car2go it was quite hidden and only showed the next time the user opened the app together with the notification about the price of the last trip.
We wanted to use this new offboarding screen to make this feature more prominent and thus hoping to obtain more meaningful data on the service. We also redesigned it in a way that it would require less effort for the user in regular cases. We replaced the free-text form with optional pre-defined cues based on the star-rating the user had previously selected and the most common ratings we have gotten before. There would still be the possibility to enter free-text in case the user wanted to mention something the system didn't cover.
Unfortunately, this part of the concept was never fully finished as it was clear that it wouldn't get into the app for priority reasons. Further thoughts that hadn't been elaborated yet were if the ratings steps were too many for users and should therefore be reduced, in what way the cues made most sense to be implemented and if this rating should be displayed to the user after every rental or less often. Also, we haven't yet settled on KPIs that made sense to measure with the roll-out of this feature.
Unfortunately, the full concept didn't materialise yet because of time constraints. However, parts of it could be implemented along with other challenges we were tackling. The improved help section made it to the SHARE NOW which is live today. Some sacrifices had to be made though: instead of showing the most asked questions, as a quick win we decided to move the "How To" tutorials in that place.
All in all, this project was the first one in which I learned to follow a more thorough design process. Even though I've done plenty of competitor research before, I never went into that depth and also looked outside the own field into similar indirect competitors.
Also other parts of the process like doing quick interviews or testings with in-house employees are something that I've been doing ever since and helped me improve my design process. All this resulted in a much more solid concept that anything I've done before.
So, despite the fact that – as of now – only a small part of the concept was built, this project still helped me massively in becoming a better designer.