How did we solve this problem?

 ⬆️ Define initial entry points

To better align the cross-functional team, I defined the happy path of the driver experience.

Click image to expand

I then ideated on several entry points where we could introduce this new chat feature. Here is an initial suggested entry point, when the driver accepts a new ride and is ready to start navigation.

Click image to expand

✍️ Design refinement

Once entry points were defined, I began to ideate on various design approaches for each instance. One of the most critical was incoming messages while drivers were on their way to pickup a passenger.

To better explain the context of this moment, here is a live photo of a Free Now driver I recently interviewed:

Click image to expand

In these moments, the driver’s cognitive bandwidth is considerably low, as he’s managing five different interfaces:

• The road
• The car dashboard
• The car’s navigation / entertainment system
• Personal phone (often talking to someone)
• Work phone on a stand displaying the Free Now application

Within the Free Now app itself, there are a number of existing elements the driver is constantly scanning - from the turn-by-turn banner, to the map, to the bottom sheet displaying time and distance to the pickup point.

Click image to expand

How should an incoming message live amongst a cognitively demanding environment and within an application containing so much vital information?

My initial proposal to the team was to centralise the experience around audio and voice. There is so much visual noise in the driver’s reality, why add to this? Why not have the app read the message, and allow the driver to use voice to reply? Not only was this the most usable approach, it was the safest. Unfortunately tech constraints didn’t allow this for the MVP.

If we had to rely on visual information, an initial decision I pondered was if it should live inside an existing info container or within a new container. The former approach was constricting, and felt forced. For these reasons I decided on the latter.

Click image to expand

My initial idea was to create a chat bubble (akin to what you’d see in an iMessage screen) overlayed on top of the map. I decided to create a card, as it would better accommodate pre-defined messages, and allow various options for intractability.

Click image to expand

The screen felt busy and information overloaded. I re-evaluated with the team where we could possibly make visual sacrifices. We concluded that the map and turn-by-turn banners were ‘need to haves’, while the bottom sheet was a ‘nice to have’.

Click image to expand

So I decided the incoming message card could sit on top of the bottom sheet, as it was more urgent and important in that moment. I also made several refinements, making the card more simple and visually cleaner.

Click image to expand

🚕 Usability test

I created a prototype and worked with 2 UX researchers to strategise and carry out interviews and usability testing. Here an example screen of the driver receiving a message on approach to the passenger.

Click image to expand

Most of the tasks we asked drivers to carry out were done successfully. However the interaction of the incoming message card caused confusion. The card required an up swipe to expand, and down swipe to dismiss, which weren’t intuitive. I then created two new variations:

Click image to expand

Option 1 would ensure the driver consumed the message as they would be required to tap on a cross to dismiss the card. Yet this would compromise safety, and might be annoying having to dismiss multiple messages in a ride.

Option 2 would ensure safety, as no interaction would be needed to dismiss the card. It also created space to neatly include a chevron, which would make the ‘tap to expand’ interaction more understandable. However, we had concerns the message wouldn’t be consumed before it was dismissed after X seconds.

In the end I deferred to one of our team’s design principle (Driver Safety), to decide on Option 2. Here are the final screens of the chat feature:

🚀 Launch

After making a few design refinements based on feedback from the usability test, I created handover files for the development team. The feature was launched four months later. Results since the launch:

• Tour Completion Rate is 1.9% higher when Chat is used
• When both parties exchange messages Tour Completion Rate increases by 8.5%
• Passengers who use Chat have 20% lower Cancellation Rate
• Calls reduced by 40-50%, which leads to...
• Net savings of 15k€/month by avoiding phone masking service