Managing office commute through Track-on-Travels: A Case Study

“…And if you don’t know where you’re going,
Any road will take you there…”- Any Road, George Harrisson
Although Georgie’s words make sense poetically, not knowing where you’re going might lead to a lot of trouble in the real world. And when it’s a daily commute, knowing the details of your ride is crucial to your routine. That’s where Track-on-Travels (or ToT, as we like to call it) comes in.
AFour has a fleet of buses that run through multiple routes in Pune to pick-up and drop employees. ToT assists these employees to manage their daily rides to and from the office premises. It also allows the administration to monitor and manage the running buses.
Side Note: ToT was the brain-child of Darshan Gaikwad and team, while they were a part of Hack-D-Day, a 24-hour hackathon event at AFour. Because of the impressive work that they did, the stakeholders decided to take it up as an internal project and see it through completion. I spearheaded the design of the app when it started out as an internal project.

Project Highlights
Timeline: Nov-Dec ‘18
My Role: UX and UI Design
Team: 1 UX/UI Designer (me), 2 iOS Developers, 1 Full-Stack Developer, 2 Software Test Engineers, and Product Manager

Current Process and Pain Points
To understand how users currently manage their commute, I took up guerrilla interviews. It proved to be a time-effective, low-cost way to way understand and learn about travelers’ and admins’ current experience.
The Goal
The goal of the interview was simple. Through the travelers, I wanted to know how they currently keep track of the running bus. And as for the administration, the focus was on the hiccups in the current process of onboarding the users and monitoring the buses daily.
Participation Criteria
The only participation criteria for the interviews was that the individual should be a regular traveler on the office bus.
In addition to the travelers, I also had a quick word with the bus drivers to get an idea of their daily routine while on the bus.

Key Findings
What I learned about the current process and pain points fell under the following three heads.

1. The WhatsApp Group
No running buses currently have location monitors on them. However, the current travelers have implemented a workaround for their ease. They have a WhatsApp group in place wherein the first individual to onboard the bus shares his/her live location with the group.

This practice, although innovative, is prone to human error. There had been days when no employee boarded the bus on the first stop and the location of the bus was unknown to those boarding next.
“ I think the WhatsApp group helps. People just update the status of bus on the group and then I can plan my mornings accordingly.”

2. Manual Onboarding
First-time travelers need to contact admins physically to check availability and get themselves added to any route. The process was often exhausting and susceptible to delays.
“ I had to spend an afternoon getting to know the routes and seeing if there’s a stop closest to my home.”

3. Unwanted Delays
Another issue which the travelers mentioned was the frequent delays while traveling. This often led to collective trouble.
Most of them also agreed that they’ve been the cause of these delays, at least once. And since no measures were in place to hold them accountable, a general sense of complacency towards punctuality prevailed.
“ If everyone boards the bus on time, I think we’ll be able to save an hour or more of our time every week.”

What lies at the end of the road? — Goals and Scope
We now knew the primary issues that were to be addressed through ToT. These issues were the single source of truth while locking down the goals and scope for the app.
Goals
As a response to the identified issues, the following goals were set to evaluate our success once the app is developed.
1. A seamless experience
A fast and smooth experience of onboarding and tracking the location of running buses for employees.
2. Reduced offline tasks
Reduced workload for the administration related to monitoring and managing the fleet of buses.
3. Traffic and location data
Insights from the daily traffic data and employees’ timings would improve accountability and help in planning better routes.
Scope
Since a couple of resources who weren’t a part of the team initially (including me) came on board, making sure that all of them are clear on the scope of the app was crucial.
Enter, User Stories.
The purpose of using User Stories at the inception of the project was bifold. First, it allowed us to set clear and feasible goals for the MVP and second, everyone had a clear picture of what fell in their task bucket.
Here’s what our high-level, informal user stories looked like.

Once we had the user stories in place, it became really easy to estimate and prioritize them for the MVP. For example, we deprioritized the in-app chatroom to get done with the admin console in the initial sprints.

Wireflows as a UX deliverable
Since the app was confined to a couple of pages that changed dynamically based on user interaction, wireflows were the best choice to give the team an idea of the information flow in the context of common user tasks.
Before starting with wireflows, I sketched a flowchart of the primary actions in the app for the stakeholders to sign-off. This made sure that I’m on the right track with the design and no information is being lapsed.


And then came the wireflows…

Beep beep! Your app is here.
And just like that, the design for the Track-on-Travels app was complete. The admin panel, however, contained minimal functionalities for the MVP, i.e., reviewing the onboarding requests and gathering metrics like travel frequency and delays.
Here are a couple of screens showing the core functionalities in the app.
1. Onboarding
New users can place a request to be added to a route through the app. Once approved, they’d be notified daily about their rides.

2. Real-Time Tracking
Travelers can view real-time location updates of the bus while it’s traveling. They also get notified when the bus initiates its journey to or from the office premises.

3. Geofencing Notifications
The app notifies the travelers once the bus reaches within a 2 km radius of the pickup/drop point.

4. Chatroom
Since the users were used to conversations while in or out of the bus, an integrated chatroom was a positive nudge to the application. It allowed them to converse without switching frequently between apps.

5. And then some illustrations…
Adding these fun illustrations to the empty or error states of the app made the experience a bit more delightful.

Outcomes
Currently, an alpha version of the app has been developed and is being tested on one of the buses. The development team is consistently working on identifying and resolving all functional or visual bugs.
What’s next?
Since we wanted to make the admin console just functional enough for the time being, we’re looking into adding more analytical capabilities to it. As more features come into the picture, a dedicated design sprint would be undertaken as we go ahead. In the meantime, the location and delays data is being recorded to analyze and plan better routes in the future.
The job, for now, stands done.
Pradyumn out. *drops mic*

