View the original post
This case study explores the user flows and journey of the users while navigating a mobility app
Design a B2C app for employees to use the transport services provided by Tranzip (a fictional company).
Pune is a booming tech hub. There is an increase in the number of working professionals settling in different parts of the city. Though it is one of the bigger cities in Maharashtra, the public transport is not good. Employees find it difficult to commute and reach their offices on time with a flawed public transport system. To counter this problem, many companies provide pickup and drop services to their employees.
Overview of Tranzip
Tranzip is a transportation company, based in Pune, that provides pickup and drop services to employees of companies registered with it. They have a fleet of buses and cars which run on multiple routes throughout the day in shifts. Some drivers are under their payroll, while some are on a contract and hired via third-party providers.
Defining the users
This section takes a deep dive into understanding the problem space and articulating the pain points of the users.
Understanding the problem space
To get a lay of the land and understand the problem space, started with secondary research. Conducted competitive analysis to understand the model, patterns, and flows in the pre-existing apps operating in the mobility sector.
Simultaneously set up user interviews to understand and empathise with the target audience of the app. Conducted a few conversational-style user interviews with my friends and family who used the office bus service as the primary mode of transport to and from their workplace.
It helped me understand the existing model of the bus service in the real world and the related pain points of the users.
Insights from user interviews
Why is Tranzip needed?
People don’t prefer the public transport service, Pune Mahanagar Parivahan Mahamandal Limited (PMPML), as it is unpredictable and makes it difficult for the employees to commute and reach their offices on time.
The unreliable service of the PMPML buses is because of
1. Less frequency and late arrivals of the buses
2. Frequent breakdowns of the buses
How is it happening right now?
Some features and functionalities of the existing model of the bus service provided by most companies,
- Availing to the bus service: There are a fixed number of predefined, pre-existing bus routes that any employee can subscribe to. The employee has to fill a form or directly inform HR about his chosen route. If none of the routes are close to an employee’s residence, the user can Raise a request.
- Subscription model: It ranges from quarterly to biannual where a standard fee is deducted at the end of every month. The fee is fixed for all.
- Sign up: The user has to sign up for the service before the next cycle begins. If the company follows a quarterly model, the user has to opt-in for the service before the start of the next quarter. Once subscribed, cannot opt-out in the middle of the quarter.
- Communication: When the bus is running late the status of the bus is conveyed through a WhatsApp or Telegram group (all the people travelling on that bus are a part of this group).
- Helpline numbers: There are helpline numbers for emergencies. If a single female employee is remaining on the bus, there is compulsorily a male escort. The female employee is dropped off first and only then the male employee is dropped at his stop.
- Validation of users of the service: The users have an ID card that enables them to use the bus service. This ID card is used to identify and validate the bus route of the user.
An assumption was that the user has a smartphone with access to wifi or cellullar data.
A constraint to be noted was that the app operates in an ecosystem of
- B2B web app (for fleet management)
- B2C customer app for employees (the app in consideration here)
- B2B driver app
Based on preliminary understanding and research, picked up the Subscription-based model in the first iteration. It gave users the flexibility to choose from a one-time ride, weekly or monthly subscription. In this model, they could cancel rides but within the cut-off time. The balance rides would be adjusted and carried forward accordingly.
This model replicated the public transport model with fixed routes and fixed rates. It was a fixed system.
The subscription-based model worked on fixed fares and routes. Even though the Subscription model in a closed setup did solve the problem statement (for the B2C employees app), it did not consider the business side of things.
In the subscription model, buses travelling empty would have led to inefficient use of resources and an increased cost to the company (for providing the service). It would also have a detrimental effect on the environment. Hence, this model was dropped.
Considering the business constraint, switched gears and designed for a dynamic system. It was anticipated and configured to deliver maximum productivity, efficiency, and realisation (of seats). In a dynamic system, the routes change daily, and consequently, the fares vary. Dynamic pricing is a function of the dynamic routes. The routes change daily to maximise the realisation of seats.
By maximising the realisation of seats, the business could cut costs and generate more revenue in the dynamic system. The buses don’t go empty, the company saves fuel and the environmental impact is better.
The following sections explore the final designs defining the user flows and journey of the users while navigating the app.
A. User flow for sign up
Presuming here that Tranzip would have a list of companies and its employees. The Tranzip database would have the following data points of every registered employee
From the above listed data points, the Company ID, Mobile number and Work email ID would be unique for every employee. Hence, using the unique Mobile number to match against the Tranzip database for verification purposes during sign up.
Whenever a number is inputted in the app, the system will search for the number in the Tranzip database. There can be 2 scenarios,
This would make it a closed setup and eliminate the outsiders from getting access to the app.
The input of the Home location or its geolocation gives users the output of 3 pickup points in the vicinity of their Home location.
B. User flow for the trip
Home screen design: Instead of reinventing the wheel, took inspiration from the existing apps in the mobility space. Took this approach to empower users to use existing mental models to focus on their tasks; and not on learning new models to navigate the app.
Validation of passes
How are the passes validated?
QR code scanner/reader: It allows only those with a valid ticket to board the bus. There could be 2 scenarios here,
- Manual: an attendant with a scanner validates and lets through the users
- Automated: the turnstile inside the bus lets through only the users who successfully scan and validate their tickets on the QR code scanner/reader fitted inside the bus
Booking ID: The Booking ID is a unique identifier that a user could verbally speak out to the driver or the attendant to validate their ticket when the phone’s power is out.
- Tranzip can track the vehicle in real-time through the driver’s smartphone device. The driver would have the drivers app installed on his phone. As long as the device is on, the company knows the driver (and vehicle) location.
- If required, based on business requirements, the company could install Global Positioning System (GPS) enabled tracking system in all the buses on the platform. The installation of such a system would help improve safety of women.
C. User flow for recharging the wallet
D. User flow for editing trip details
The Trip calendar enables the users to select a date and
- Mark a leave
- Edit the default Trip settings
The users could also have changed their Trip type for a day or days based on their emergent requirement enabling them to opt-out of pickup or drop for a day or days. This feature could be additionally designed based on business requirements in a real-life scenario. However, being a theoretical problem statement exercise this has not been incorporated in the Trip calendar.
E. User flow for updating profile details
The user can update his profile details, address and pickup location from the Profile.
The solution was crafted to encapsulate the problem statement. However, for a real-life scenario and a business opportunity based on the competitive scenarios and the needs of users, the solution can be modified accordingly.
I took up this problem statement as the capstone project of 10kdesigners (an online masterclass in design).
Reflection and takeaways
Research to lay a solid foundation: Deep diving into the problem space helped me gain a better understanding of the problem statement and hence the app requirements.
Listen carefully and take notes: User interviews helped me in uncovering the hidden solutions that emerged as key features of the app.
Use pen and paper: Laying out the ideas on paper helped save time. A stitch in time saves nine.
Have trust in the process, keep a level head: The design process was messy, iterative, and long. A tiny bit chaotic at times, like one of those snowstorms in a jar. With patience and perseverance, things fell in place.
Phone a friend: Having a support system, someone be my north star and sounding board helped in this long process of designing the app.
Case study: Designing a mobility app for daily office commute was originally published in Muzli – Design Inspiration on Medium, where people are continuing the conversation by highlighting and responding to this story.