Launching the inDrive app in Australia: a product designer’s perspective

Posted by Kirill Cherepanov

In 2020 inDrive became a unicorn company with 100 millions of users, 1 billion of rides across 39 countries. On one hand, inDrive was already a successful ride-hailing app competing against Uber, DiDi, Lyft, Yandex and others. On the other hand, there were still huge markets for us with bigger paycheques and we believed that their users would eagerly adopt our model. For these reasons we focused heavily on launching inDrive in Australia.

Problem

The main problem that was uncovered during the research is that there were requirements we did not meet. Building necessary functionality became our launching strategy:

• Drivers need to add his bank account because passengers only pay by card.
• Drivers want to transfer money from their inDrive account to their bank account.
• Drivers need to get tax documents to report their earnings for tax purposes.
• Drivers need to have trip details that include information such as mileage, duration, what they earned and what they paid.
• Drivers must be paid for wait time. inDrive didn’t count it and that often led to disputes whether the passenger owes the driver money and how much.
• Since our passengers are going to be able to change the route of an ongoing trip, drivers should be notified and be able to accept or reject changes. inDrive didn’t allow that recently, drivers and riders had to do that verbally.
• Drivers should be able to stop an ongoing ride and be paid according to a distance.

The main challenge was doing a huge amount of work across various teams and projects simultaneously to help inDrive to scale, build new features and solve existing problems.

Process

When the initial scope of work was defined, it was shared between corresponding cross-functional teams. As a part of the Driver team, the driver-related product part was my main focus. However, since the product for the driver was built by several teams owning different functionality, I had to work closely with the Payments team as well. And apart from that, I was closely collaborating with the Passenger team because in some cases our scenarios are tightly interwoven.

As always, my main design tool was following the tried and trusted Lean UX framework, facilitating workshops and involving the whole team to make strong and reasonable design decisions and be sure that we’ll achieve a desired outcome and deliver in time.

Vision, Framing, and outcomes

In the beginning of work on every piece of functionality I gathered product manager, business developer manager, developers and analytic in a workshop.

First, we defined our desired outcome. What are the benefits our users will get, what should change in their behavior? Then we looked at other problems related to target functionality/experience that is on the way to the outcome.

After understanding and agreeing on the outcome and problem we framed, we shared our assumptions on how to solve the problem. These were abstract and high-level ideas rather than detailed designs. At this point developers started stepping forward and applying restrictions considering the deadline. At the end of this stage we had a ready hypothesis the team believed in.

Design process

At this stage we were shaping up the prioritized assumption to get a detailed notion of how it might work. The main tool I applied here is collaborative design, aimed to get various ideas from everyone, criticize, reinforce and synthesize the most interesting of them into one solution. At this point I involved everyone to contribute and share his vision of how it might be designed using any tool, be it a notebook or a pen and paper, to produce any visual artifacts, such as UI sketches, flow charts and written user stories.

Ideally we should’ve had design sketches from every workshop participant. However, most of the time sketches and drafts were done by me and the team were doing design critique and sharing their ideas verbally. Thus, being their hands as well, I had to be working fast.

As a result of the collaborative design session we had UI drafts of a chosen solution and main user scenarios in UI or a form of an abstract flow chart.

After collaborating with the rest of the team and roughly shaping up our solution I took time to work independently to dive deeper. My goal at this point was to create a prototype of our MVP to give a tangible taste of user experience.

Also during this stage I did design exploration using other apps references and doing iterations of visual and interaction design work. From my experience, first designs are never the best ones so it’s important to commit some time and work with your eyes.

Every user story I represented as a succession of mock-ups. Then the most crucial of them I turned to Figma interactive prototypes to conduct further user testing and get feedback early on.

Feedback

Having built ready-to-test prototypes I moved on to further validate our design. The goal here was to make sure we uncovered most of the problems early on before we go to development and better understood our target user’s behavior and preferences.

I designed test experiments including questions and tasks for participants and asked business development managers to organize video calls with Australian drivers for me to do user testing.

On the call I started with discovery questions and then gave drivers prompts to accomplish tasks using my prototypes. I was following their actions and put down questions they asked and things they struggled with and asked open questions on how valuable that solution would be for them and how they are satisfied with this solution.

Here are some things I found out doing user testing:

• Drivers expected certain behavior they got used to in other apps. For instance, drivers were attempting to report a road accident using the safety button.
• In some cases drivers needed more information to make decisions on the way. For example, when a passenger requests a route change, for a driver it’s not enough to see what has changed. It looks neat, but isn’t helpful enough.
• Drivers wanted to see clearly what’s important. Comparison tests showed that they prefer simple and straightforward design rather than fine and obstructed with too many details.
• Some metaphores used in interactive design had completely different meaning for drivers, which might have negative effect in the future experience

After getting feedback from our users I shared them with the team and we iterated on the design before preparing the project to hand off to developers.

Result

After 6 months of work, on 21st of March 2022, inDrive was finally launched in Brisbane, Australia. We attained our initial goal and the number of users has been steadily increasing. We also see that our business model successfully works in the Australian highly competitive market.

As with every product, we know that launched doesn’t mean perfect. We’re aware that having met the initial requirements there are still many problems and we have to continuously improve our product in many ways.

Learnings

Over the course of this exciting work I learned important lessons:

• User testing is always worth investing as it shows problems of the initial design and this time was no exception
• Something may come along not as planned. Be prepared, don’t lose heart, be flexible. It happened to us. One of the projects was assessed and accepted to development, the overall scope of work increased and to ship the feature on time we had to simplify the design properly
• Involve your design system team early on. Our product grows quickly and it’s natural that I had to invent something brand new where the design system didn’t meet some needs. However, communicating these new features and components to the DS team would save time eventually.