Juno
How we tackled an unexpected decrease in support calls after a massive app redesign, and got back on track.
Late 2018 • Product designer • Mobile app design, prototyping, wireframe to handoff
Late 2018 • Product designer • Mobile app design, prototyping, wireframe to handoff
Juno's ride-hailing services were famous by its 24/7 live support, and many detailed articles in the Help center. After we noticed that many support calls are related to previous rides, we added a 'Support’ feature inside a 'Trip-history' ticket – but things didn't go as planned.
The basic scope was to offer popular, trip-related support articles, as well as a quick shortcut to the Help-center, and an option to call the driver - primarily to be used by those who forgot items in the car.
People used it, but not as much as we planned them to. We still had a lot of support calls by those who forgot items, or just wondering about their trip fare. Issues that could have easily been resolved after reading a support article. So, we dove into the data.
On this short funnel, a 6% completion rate was pretty poor for us. Not only that, but we had the support calls to validate that people reach out to support on issues that could have easily be resolved by reading a quick article. We assumed our main problem was feature exposure, more than the actual usage of those who saw it. We aimed to increase that 13%, and fast.
While I was doing my regular benchmark research – examining other apps in and out of the ride-hailing context – I also had some thoughts about the current screen layout and overall design.
• Poor accessibility
• Challenging unconventional layout
• Problematic spacing system
• Conservative approach - just finished a redesign
• Relatively small team & minor issue
With all this in mind, I wanted to know more about the reason people accessing a trip-history-ticket, and specifically looking for support. I conducted a mini-survey among our support specialists, resulted in interesting takes. Seems like the majority of people viewing a trip-history ticket (and reaching to support about it) are looking for clarifications about one of the two - the trip fare, or asking for the driver’s details.
Eventually I brought 3 options to discussion, with their pro's and con's.
✅ Maintain UI component
✅ Better, clearer page categorisation
✅ Bring help section higher in hierarchy
❌ Detached from the focus of this page
❌ Damage map view & aesthetics
✅ Native, familiar functionality
✅ Reduces complexity and simplifies the layout
❌ Detached from the focus of this page
❌ Lowers the help button in hierarchy
✅ Easy & intuitive gesture
✅ Related to the focus of the page
✅ Better hierarchy
❌ Help is almost hidden
❌ Drawers weren’t so popular at the time
Eventually, using the insights from the support-specialists questionnaire I mentioned previously - assuming that visual relation to what people were looking is important - we decided to ship the drawer component. It did feel like kinda the opposite of what we intended to do (expose the help section), so some persuasion was needed, but we sent it to an A/B test, and results were beyond expectation.
The A/B Test showed a dramatic increase in exposure compared to the current version we had. After the gradual rollout we realized that exposure rate has more than doubled itself, stabilizing on ~30% (Drawer opened event). Exposure to usage ratio remains the same.
In retrospect, I thought it was a good project for me. I was disappointed I didn’t get to validate any solution with a usability test, and it took me precious time to come up with the support-specialist questionnaire, yet overall I was still satisfied. After 3 months in the role I understood what data implies about behavior, and how I could test it within my solutions.