Designing an app for a friction-less ride booking experience to help users with their daily commute.

Published in

Bootcamp

15 min readAug 10, 2021

In this case study, I will take you through my process of designing a B2C app for commuters that I did as my capstone project from the 10kdesigners cohort.

Problem Space

Story

Pune is a booming tech hub also with an increasing number of working professionals from different parts of the city, employees find it difficult to commute and reach their offices on time due to uncertainty and the late arrival of public transportation.

To counter this issue most companies provide pickup and drop services to employees which are usually outsourced to travel and transportation companies.

Transzip is one such transportation company that provides these services with a fleet of buses, cabs, and vans which run on multiple routes and shifts across Pune city. They provide these services only to those companies who are associated with transzip to help their employees commute to the workplace.

📝 Current Process

Transzip currently uses excel to keep a track of clients, payments, vehicles, routes, drivers and to roster their bus rides.
Employees usually are given paper passes from their companies which they show to the driver before boarding the vehicle. These passes can either be free or the company might charge a nominal amount which is deducted from their compensation.

👀 Problems with the current process

🚎 From Transzip’s Perspective:-

Maintaining sheets for all this data is a tedious job.
Transzip couldn’t keep track of the live location of their vehicles
Transzip has to roster and design routes manually to pick up all the employees from different locations.
Drivers tend to cheat with the wrong odometer reading. They sell excess fuel and con Transzip.
Transzip complains that employees whose passes were expired still board the bus. Ex-employees of the companies take undue advantage and travel for free.
A lot of Transzip’s buses run with low occupancy and rides are not optimized. This is taking a lot of toll on Tranzip’s business.

👨🏻‍💻 From employees( Customer) Perspective:-

No visibility in the system:- intimation on boarding time and boarding points if there is a change or other updates.
Employees complain that they have to pay for a month’s subscription. They wish to pay only for the days they travel.
Fixed billing and fixed routes.
No reliable tracking system in the present system thus questioning women’s safety (especially late night workers.)

Deliverables

Below is the list of choices given to pick from and work on.

💻 B2B Web App for Transzip:-

With functionalities to monitor drivers/fleets and SOS real-time, create and roster routes, assign drivers, manage fleets, finance, and drivers salary and profiles.

📱 B2C Customer App for Employees:-

With functionalities to book buses and passes for the daily commute, real-time updates and tracking of their rides, app wallet, and setting up their profile like home and office addresses.

Here I have chosen to design the “B2C Customer app” and in this case study, I’ll explain my approach to designing it.

🔍 Research

Before jumping right into the design and approaching the solutions I went ahead and looked for some existing players and wanted to understand,

How do the booking flow and experience work?
What or how do the business model and fare charges work?
What are all the necessary real-time updates the user would need to see from the app on day to day basis for a seamless experience?
What are all the pain points that the users experience with current solutions?. To understand their mental model on how a user experience for an app like this should work.

👩🏻‍🤝‍👨🏾 Defining user groups

Since this is a closed system and employees who are working in the companies that transzip is associated as travel parter provider are the ones going to be use it.

But those employees and be divided into user groups as actual and potentials users.

Actual users: Employess who already use tranzip’s services by signing up in office for transzip

Potential users: Employess who use public transportation, book cabs (like ola, uber etc,.) and own transportation.

All these potential are using their own mode of transportation either because of their own convinience or may because transzip’s service is not operating to their place, not a reliable service could also be the reasons to missing out on these potential users.

So, if transzip’s service could be made in such a way that it’s reliable, effiective and cost efficient that what they (Potential users)use currently they could be converted into transzip’s users.

To get provide such service I went and did secondary research on existing players, their service and the product offering that they provide.

📉 Competitive Analysis

Since most of the commuters prefer their own mode of transportation to the workplace or they use ola and uber or in some cases public transportation there are not many players in this space to explore and look for and the existing ones work in selected cities alone. Some of them with more active users and 10,000 bookings per day are listed below,

Common pain points identified

Unreliable tracking and updates on rides.
Multiple steps and too much effort to book a ride.
Challenging UX (Because of non-familiarity).
Charging monthly premium upfront and automatic money deduction without intimation.
Fixed routes and fixed boarding points couldn’t raise requests.
Lack of communication between drivers and system (Some human errors).

💡 Insights from competitive analysis….

Users want a seamless and simple booking experience for booking their daily rides.
They wanted to get real-time updates on their rides (everything right from the Live Tracking, Driver’s Location, Pickup Timings, Pickup Locations, Fare Details, Cancellation Requests, Prior information on any changes on rides status like schedule Timing, Late arrival).
Users wanted to pay only for the rides they’ve taken instead of paying a month’s premium beforehand with a huge amount which even includes the off days that they don’t even go for work.
Users expect to book their rides for multiple days at the same time (Bulk booking whenever they wish to do so) instead of booking it on daily basis.

🤔Ideation

Before jumping straight away into the ideation I’ve just made few basic assumptions from my understandings on the problem space, users, and the companies to proceed and work on,

Transzip is a closed service system which means it provides services only to those companies which are associated with transzip to help their employees commute to the workplace. Other than that one can avail transzip’s service.
These associated companies are not contracted directly with transzip to pay for their employee’s travel expenses. Employees have to pay for their rides and these companies are just in association with transzip a travel partner. But if the companies take care of their employee’s travel expenses well and good they can redeem from the company itself if they have such provision to do so.
Transzip provides fleets ranging from buses, cars, and vans for the companies associated with them, and also they almost cover every part of the city(PUNE) in and out with their fleet’s routes.
Employees register at their companies for transzip to avail this transportation service.
Since it is a closed system company provide transzip with their employee’s basic details(like phone number, email id, and company’s shift timings) for the app login and authentication purposes.

Now with all this information, I started ideating about the functionality and the user flows of the app.

🧩 Functionalities that should be present:-

User Profile — to set and edit their home location and boarding points(which most of the time gonna remain same but still changes some days based on user’s interest) and ability to set and change their shift timings(which may from time to time sometimes in companies).
Calendar — to schedule their rides, mark off days, changing shift timings for particular days(overtime peeps), changing pickup location for a particular day(just an additional feature to help the user) basically to make changes apart from their usual office rides schedules.
Wallet — this should be an in-app wallet where the users have to recharge and maintain sufficient balance for their rides because the money deduction for their rides happens here. Deduction of money only happens for the rides they’ve taken.
Realtime updates — on their rides, schedule changes, live tracking and
SOS Trigger — mainly for women’s safety (helpful for those who board for late-night rides )and general SOS purposes too.

Main User flow for the app:-

Now with the assumptions that I’ve made and the functionalities that should be present in our app, I started laying out the various possible user flows before breaking it down into IA and ended up with this one since this requires minimal user’s effort while booking rides and that’s is also what the user expects.

📃 Justification for the user flow

Including shift timing, home location, and boarding point set up on onboarding itself — since these are going to remain the same most of the time I’ve made the set up on onboarding itself. The changes in these take place only when the user wishes to do overtime or a shift timing change by the company for few days or the user wishes to board from a different boarding point for a particular day or few days. These are not regular cases but are edge case or rare case scenarios. So if the user wishes to edit apart from their regular schedule they can edit that in the calendar section.
Calendar section to just make the changes — Rides are auto booked every day for the user because booking rides daily makes it an extra effort for the user to remember and sometimes they even forget. So for these reasons I’ve just made the calendar section to mark off days and change schedules apart from the regular schedule for their office and they’ll get the rides accordingly.
Wallet payment — since the user doesn’t want to pay a huge upfront amount for a monthly pass and wanted to pay only for the rides they’ve taken I’ve decided to implement in-app wallet payment so that users can recharge for an amount sufficient for the rides and deduct only for every single ride they’ve taken. Also, this can be useful for integration auto deduction with the system only from the wallet and not from the debit or credit cards which was the biggest complaint from most of the users.
Auto Deduction of money from the wallet — Since we’re deducting money from the wallet only for the rides that the user takes there comes to a question that when the auto deduction happens from the wallet and also the user has to have money in the wallet to deduct. This can be approached in two ways, (i) Deduction while scanning to board — This one works in a great way. But what if the user has zero balance in the wallet? This was an edge case to think of. Obviously, we don’t allow them to board. But leaving stranded makes it a bad customer experience. We can send low balance notifications too but what if the user fails to notice it. so this approach fails. (ii) Deducting a day before for the next day’s ride alone — With this approach, the system checks the amount in the user wallet a day before, and if yes money gets deducted, and issue a boarding pass. If there is zero or insufficient balance the system will not issue the boarding pass and also intimates the user with an alert on the app a day before itself so that he notices, recharges, and maintains his wallet balance for sufficient rides. This reminds the user that he/she has to maintain sufficient balance to get seamless rides.

Now after setting things up clear let’s next dive and break things into Information Architecture and Wireframing.🤙🏻

📌Information Architecture

Now it’s time to break things up clearly into each and every functionality and sort them into a clear hierarchy of features before sketching ideas for the actual screens.

✏️ Wireframing

It’s time to start sketching the app screens before starting designing in figma just to try out the different layout that’s possible.

Visual Design

Now let’s dive into the most awaited part of the entire case study.😉

Color Palette

Since it’s an app for booking office rides I don’t want it to be with striking colors going and wanted it to be as simple and minimalistic as possible, the reason behind this is just don’t want to stress the office peeps visually🤭. So I chose light or let’s say a shade of green that looks calming or toned down as brand color and used neutral shades mostly just to achieve that simple and minimalistic look.

Typography

I wanted a sans serif font that has a balanced look and multiple font weights to play around and go with the simple and minimalistic look. Lato is a sans serif typeface family which has a balanced look and the letterform preserving harmony with elements. It also supports multiple weights, including Thin, Thin Italic, Light Italic, Regular, Regular Italic, Bold, Bold Italic, Black, and Black Italic. So I went ahead with Lato.

Branding

Logo plays a very important role in conveying the brand name as well as the purpose of any company. This app deals with end-to-end ride service(i.e., home to work and vice versa) also deals with roads and rides. To convey these messages I’ve designed the logo in such a way that conveys what transzip actually does. The font used in the logo is Kodchasan which has nice and sleek curves that blend with the brand identity. Without deviating much from the logo the app icon has been designed while retaining the brand identity.

Onboarding

Onboarding plays a major role in converting the users and making them use the app. So it is crucial to covey the value that the product brings to the user clearly and also making the onboarding experience seamless to avoid drop-off. There is only login for the app and no signups because the user has already registered for Transzip’s service at their company.

Since this is a closed system where companies that are associated with Transzip and employees who have registered for Transzip’s service at their company can only login and access this app I come up with this flow on onboarding for verification and authentication.

I’ve included the ride details setup and estimated fare charges details for their daily commute in the onboarding itself because this doesn’t change most of the time and this is the basic travel loop that they follow almost every working day.

Home Screen

Narrowing down to the solution for the home screen was the most confusing part that I’ve gone through. There are several ways in which the home screen can be designed but showing the necessary and most important details upon which the user takes action was the most important thing to consider. Also, the user should not feel challenged to perform tasks as well as seeing necessary information needed.

Initially, at the time of ideation, I thought of allowing users to select the bus they want to travel based on the boarding time and seats to choose from, etc, but this increases the user's cognitive load and booking it every day. Sometimes the user may forget to book or choosing the wrong timings.

So what is their ultimate goal? To reach the office on time, they needed a ride that always appears without having to worry about missing it if they forget to book or schedule it.

So I ended up suggesting users with the boarding time for a bus that drops them on time based on the shift timings that the user has already entered. Now the user can just relax and have to follow the timings alone without having to remember constantly to book every day.

I went ahead with side pane navigation and bottom sheet in home screen with live status instead of tab-based navigation and cards with just information which most of the apps in this space did and users find that a little challenging.

The reason I chose side pane app navigation and bottom sheet in the home screen with the live status are that the user wants real-time updates on the ride and in with approach everything in the home screen changes dynamically based on the ride status. Also other famous ride-booking apps like Ola, Uber, Lyft, etc,.. has the same experience on the home screen to which most of the users got used.

In this state, the bottom sheet changes dynamically to before boarding state where the user is presented with the driver’s info, vehicle number, and type as well as live tracking of the bus. This becomes active when the driver starts the ride on his driver app to pick up employees in the route.

When the scan to board button is pressed the QR CODE pass opens up which acts as authentication for boarding and also changes for every new ride that doesn’t remain the same.

After boarding the bottom sheet changes to boarded state and the ride to home or work is on.

Calendar

Presenting the right information to the user without confusing them was so crucial in this section. Also not making them feel challenging to complete a task was another thing to consider. I approached this in two ways.

The above approach for the calendar has a lot of redundant information going on on the screen and it’s too much for the user to consume. Also for marking off days the user doesn’t have to wait until the last week of the month. The user should be able to do it and change it whenever they wish for whichever date he wants. So tried clearing up things and came up with another solution after iterating.

The above approach allows users to edit the schedule whenever they wish whether it is for multiple days or any single day also with less visual clutter while showing all the necessary information. So I went ahead with iteration 2.

Offs days, shift timings, Pickup locations change

Wallet

The users have to maintain sufficient balance for their rides so I’ve included the rides metrics here on the wallet page because that is the deciding factor for users based on which they recharge the amount necessary into the wallet.

I also went ahead and created some of the notification pop-ups that could be there for this app.

📱 App Prototype

Check out the prototype😉. I’ve shown how the user flow works. Please set the video quality at 720P while watching.

Learnings and Reflections

Building an app from scratch requires thinking critically about a lot of constraints and edge cases that may arise. Working on this problem statement has really helped me to realize it and gained confidence from it.
Learned how to design for a real-world problem, how to approach a problem statement, and questioning myself before jumping into a solution.
Colors play an important role in conveying the brand identity of the product and balanced usage of it throughout the product in a subtle way is important. It was fun learning how to play with colors.

🎉And that’s a wrap…..

I hope it was insightful.

A huge thanks to Yugandhar Bhamare for mentoring throughout this capstone project🤗🙌🏻.

I’m currently looking for job opportunities as a Product Designer. If you’re hiring, I’d love to have a conversation with you.
You can reach out to me on LinkedIn and Twitter. 😉