BusStop
Timeline: 1 month
Team: Solo project
My Role: UX designer and researcher
Case Type: App Redesign, Design Systems, User Research, UX Design
BusStop is a school bus tracking app targeted to teachers and bus drivers.
When a parent puts their child on a bus to go to school, the parent never knows where the bus is, whether the bus is depositing their child to school efficiently or not, or if something has happened to the bus and the precious cargo it’s carrying.
There are many apps out there that offer efficient tracking systems and who work with schools, school districts, and bus companies so that all individuals involved: parents, school administrators, and bus companies, could make sure students are where they are supposed to be. However, one particular pain point that is not addressed by the three dozen or so apps on the market is an exclusively parental one: not knowing when the bus will arrive in the morning to pick up their child.
The stress of never really knowing when the bus may come is a headache that can cause parents to be unable to coordinate other important parts of their life — a carpool for a younger child, a meeting at work, or even a workout class they would like to attend. If we can see the estimated time of arrival for our uber or Doordash order, why can’t we see the estimated time of arrival for morning pickup for children going to school?
BusStop solves these problems by:
BusStop is an app to help parents track their children’s bus for both pick-up and drop-off. This gives parents peace of mind so that they can see where their child is located both to and from school, but that they would be able to know exactly when the bus comes, so they don’t have to wait interminably long at the bus stop if the bus will arrive late. Both bus drivers and parents sign up with the app, with parents paying $5 a month for the service, $2 of which goes to the bus driver.
I came on to the project after the app had already been designed and programmed in beta. I was asked by the stakeholder of BusStop to give the app a “run-through” because it needed “help”. The app had a lot of user issues, including an inefficient form of tracking using license plates and a poor user flow to creating a bus route for parents and bus drivers. It also suffered from design issues that made the product look dated and aesthetically garish. In addition, the stakeholder wanted there to be more hand-holding in general, with better CTAs and descriptions explaining the process of signing up.
A sampling of some of the original screens. The left screen shows how it tracked buses by license plate; center screen has a weird optional “nickname” option, with no explanation given as to why the option to name it is needed and why it’s optional; right screen has a confusing map interface where it’s not clear what is being tracked.
The main problems I was trying to solve were:
License plates seemed like a bad system for sign up on both the parents and bus drivers’ end because it felt too specific to one vehicle for it to work.
What if the bus driver switched buses?
What if a bus driver calls out sick and needs to get a substitute, who subsequently uses a new bus?
How would we make sure that a parent can track their child no matter the circumstances and make the sign-up process extremely straightforward and self-explanatory?
I wanted to understand how school administrators and bus companies keep track of buses and/or how bus routes work.
I spoke to a local school principal on how busing works and the challenges from his end as an administrator. He said his main problem was that sometimes a child would get on the wrong bus or not get on the bus at all, effectively becoming a missing child. He said he spent way too many hours dealing with that particular issue.
He also said that bus drivers are adverse to having their buses tracked, because they want the freedom to go where they want when they are not on the clock and not have people know where they are.
Interviewing a local principal on how bussing works and is coordinated between schools and bus companies
Based on that conversation, I came up with alternate solutions to the stakeholder’s problem, including disregarding the tracking buses for the sake of tracking buses, and instead approach it from a “missing child” perspective, eliminating the bus driver completely, and only have the app on your child’s phone, with the app alerting you only when your child is seemingly not where he or she is supposed to be.
I then spoke to the client about how to implement those ideas.
For the most part, he disagreed with my ideas, explaining why he wanted to keep it about tracking buses — his app was more about a bottom-up approach, whereas other apps have a top-down approach. Top-down is difficult to do in schools because all it takes is one administrator to not want to use it for it to all fall apart. In addition, according to my stakeholder, paying bus drivers for the service gives them a financial incentive to agree to be tracked and use the app.
After that conversation, I did a lot of competitor research to see how other apps approach the issue. Like my stakeholder had claimed, none of the apps had a “parent-first” or “bus-driver” first approach and treated them as mostly after-thoughts in terms of adoption. The bulk of their focus was getting districts and schools to sign up.
The principal demonstrating the paperwork he receives from the bus companies indicating who is on which bus number and when they are picked up
However, my conversation with the school principal did help explain how the bus system worked.
From my research, I knew that it was most important to focus on bus drivers and parents and their experience with the app. In order for me to work efficiently and to make sure every step of the user journey was thought through, I created an in-depth user flow that explained how the user — both the bus driver and the parent — would go through the app. It would also be a kind of checklist with which I could check my work and see what wireframes I needed to create.
BusStop user flow with the user flow key
Using the valuable bus route information from the school principal, I redesigned the sign up process for both the parents and the bus drivers by making the tracking based off of the bus route number instead of the license plate.
Sign up process using the bus number instead of the license plate. I also got rid of the superfluous and confusing “nickname” feature in the original screens
As I changed the sign up process, it became increasingly clear that the garish and dated color scheme was making it difficult to iterate and create a product that fulfilled the user's needs. So I stepped back and removed the bulk of color from the prototype, creating a clean aesthetic that made it easier to iterate and change the product.
After removing the cacophony of color, the Roboto font that was in place before I came on to the project began to feel extremely staid. Even though the pared-down design was more readable and user-friendly, the lack of color with the Roboto font left the app looking lifeless. I needed to figure out a way to make the app pop visually while also keeping usability and readability in mind. Design considerations included:
I therefore changed the font to Poppins, a sans serif that was wider and bolder, but also playful. Those qualities made the font feel secure, referencing the security a parent feels knowing where their child is and when the bus will come. But the implied playfulness of Poppins also gave it a childish sensibility that was befitting for an app that involved children and school.
After removing the color and adding the font, I began adding color back into the product, playing with the different primary colors (blue, red and yellow) in the app’s color palette to figure out primary and secondary buttons and other CTA’s to be highlighted and draw the user’s attention. I did a few preference tests to figure out things like the best input box and button design.
Preference testing, where the overwhelming feedback was to have the secondary button be an outline. The suggestion for a blue outline became part of the final design, as seen on the wireframe to the right.
I prototyped my wireframes and tested them on a potential user from the parental side. Being that schools and buses are out of commission due to COVID-19 restrictions, I couldn’t find a bus driver to do user testing on.
A usability test done remotely with a parent
From the parental test I found out the following:
Here are some final iterations I made based on the feedback from that usability test:
After further user testing, I realized that the hamburger menu was a dated and less usable than a bottom navigation, which is the gold standard for most kinds of mobile apps. I therefore updated my design to reflect that:
I presented my work to the stakeholder, and while he was happy with my work, he made some points that I realized would need to be fixed design-wise going forward: