Revamping the Income Statement for Pathao Riders

Why did we do what we did?

Drivers are the backbone of our ride-sharing system. Catering to the drivers automatically means we cater to the users’ needs. Making life easier for the drivers inevitably leads to a far better user experience.

In our never-ending pursuit towards a better driver and, in turn, user experience, we took upon the daunting task of revamping the income statement for our driver app.

What is the income statement?

The income statement is a very important part of the drivers’ experience of Pathao, if not THE most important experience- as they use this to keep track of their earnings. Having an income statement that is complex not only breeds confusion among the drivers but also translates to a lot of time on our Customer Service’s end, having to explain their earnings to the drivers.

However, the fact is that income statements are inherently complicated. The biggest challenge that we had to face and overcome was to simplify a complex topic to such an extent that drivers- from veterans to newcomers- can just take a glance and completely understand the flow of their hard-earned money.

Expectations:

One particular thorn in the ride-sharing industry’s side is the prevalence of rides taken outside the app, otherwise known as offline trips. These trips are not only unsafe for the customers but also lack features to aid drivers like incentives, navigation and insurance. Having a clear cut income statement will afford the drivers a proper understanding of their earnings and let them keep track of their finances in a more systematic way. Thus, an intuitive income statement has the potential to be a differentiating factor for Pathao in the long run.

On top of that, our customer service team has to go through a ton of calls everyday, resolving various queries from the drivers about their income-related inquiries. Having an easy-to-understand income statement will alleviate this issue- letting us be more efficient in utilizing our resources.

Problems with the old income statement :

• The breakdowns of the earnings could be much more clear cut for the drivers
• No viewpoint for historical/old earnings information
• No provision for checking specific dates
• No way to toggle between weekly (preferred by car drivers) and daily (preferred by bike riders) views of the earnings
• No reflection of incentives and adjustments
• Excessive information like “today’s ratings” in the income statement
• Our customer service teams also have to use up a significant portion of their working hours dealing with enquiries regarding drivers’ earnings

The Execution:

Once we outlined the problems with the old income statement, we went about executing the new one, step by step. We knew from the get-go that we’d have to maintain a delicate balance; too much change from the current income statement will end up alienating our driver base, while on the flip side, not enough change will still end up creating a crippled user experience.

• Step 1: Driver interviews

The first phase of the execution was to talk to the end-users: the drivers themselves. Our product team sat with the drivers on multiple occasions to try to understand what their expectation of an ideal income statement was. Sitting with them gave us a lot of insights into how they think their earnings should be reflected in the app; after all, that is the single most important factor that will either make or break the product.

• Step 2: Iterations. Lots of them.

Once we had the rough ideas nailed down about the general direction, we started off in the old fashioned way- pen and paper. After multiple iterations of low fidelity wireframes, it was time for us to translate our solutions to pixels. The bulk of the design work had begun. After every major iteration, we conducted small scale usability tests with the drivers to see if the income statement was matching up to their expectations.

• Step 3: Usability testing on a larger scale

After several rounds of small scale testing and gathering the drivers’ feedback, we felt confident enough to try this out in the real world on a much larger scale. We selected much broader cohorts for this, separately for bike riders, car drivers, food delivery men and parcel delivery men; since different types of users perceive the same solution in different ways. We released the new driver app in a closed cohort of a few hundred drivers, talked to them directly and asked them to give us feedback via voice messages in WhatsApp groups if they couldn’t make it for face to face sessions. Our product team then went through all the messages in order to understand the reception of the new app in a more nuanced way.

We also ran surveys among different driver cohorts to get more quantitative data and combined the qualitative data from the user studies to come to conclusions.

• Step 4: Analysis

Analyzing the results gave us a strong indication of what features in the income statement we needed to keep and what we needed to trim.

For example, our initial assumption was to give the drivers a view of daily, weekly and monthly earnings in the income statement. In reality, however, it turned out that about 94% of the drivers surveyed did not see the monthly view of earning with any sort of importance. This was further supported by our findings from the usability testing, where drivers simply didn’t even look at that option when asked to view their earnings. When asked later, it was revealed that most drivers thought monthly earnings were superfluous- thus making it easier for us to decide not to include it in the shipped version.

Technical changes:

A vast amount of effort was also put into re-evaluating our backend for the income statement. Here are the following changes we made, keeping in mind the future possibilities:

• Income statements and ledgers that they’re generated from are supposed to be immutable. This wasn’t the case in our previous backend system. In this new release, we made sure all the entries were immutable to prevent undesired changes in state.
• We restructured our backend to support double-entry bookkeeping. Previously the system only supported single entries- which were simple to understand, but did not give us the flexibility we needed. Furthermore, single-entry bookkeeping systems do not differentiate between assets and liabilities, so it’s much harder to get an accurate picture of the financials. Switching to a double-entry bookkeeping system in the backend allowed us to go past these limitations and it bodes well for future development while aiding in accounting and audits.
• On the backend, we modified our intra-service communication and made them event-based for a more fault-tolerant, eventually-consistent system. This allowed us to maintain system reliability even if multiple services experienced outages.
• We made sure all current and future financial statements for the drivers come from a single source of truth to avoid any confusion.
• On top of this, we introduced a data caching layer to make dynamic report generation much faster and up-to-date, leading to better UX.

The outcome:

After months of intense iterations, we finally rolled out the new and improved Income statement for all the drivers in September. So far, the response from the drivers has been overwhelmingly positive. Not resting on our laurels, we are already working on the next big improvement to make the user experience more enjoyable and seamless. Keep an eye out for more exciting updates!