On a bad morning, nobody is ready, and nobody is cooperating. The kids need to make it out the door in a few minutes to make the bus, homework and ballet shoes are nowhere to be seen and you wonder if you even have to figure out where they might be. It’s another stressful start to the day and it’s only 7:30 am.
The disarray is what inspired us to build SchoolBot, a service that gives families the ability to track their children’s school bus to make morning pickups and afternoon drop-offs a little less chaotic.
We launched a web-based beta application in October 2015 and started testing our product with the first round of parents and school districts that fall. We used a hybrid protocol that combined field research and user interviews with a survey to get a better understanding of how we could improve the service. We interviewed 7 parents, each for 40 minutes and conducted 3 onsite visits. The phone interviews conducted with parents helped us learn about communication patterns within their families, school district’s, and larger communities and we specifically asked how SchoolBot fits into this context.
A carefully constructed new-user survey provided us the ability to generate a holistic System Usability Scale grade as a baseline comparative metric. It has been studied widely and in widespread use for decades; generating thousands of ratings for software, websites and mobile devices. We used the System Usability Scale to “grade” our software system for effectiveness, efficiency, satisfaction, and identified pain points for improvement.
There were three pain points:
1. Interacting with the application through a mobile browser
2. Lack of confidence in the timeliness of the data
3. Conceptual debt in the design of the application.
Users had a hard time understanding the underlying technology infrastructure that delivers SchoolBot, and they should not be required to. Part of the user experience design is that applications feel intuitive and seamless to the user. However persistent confusion over terminology (web-based application vs. native application) and a user prejudice in favor of the new paradigm of native applications damaged the first impression of SchoolBot. Some users thought a non-native app was old fashioned while others felt “going to the internet” took too long and therefore, defeated our initial motive.
Starting with a web-based application however did save us development time and resources as we were able to build and fine-tune our idea of schoolbot in a much shorter timeframe. In our first initiative towards eliminating user frustration, we quickly pivoted to a native application and added alongside new features and improvements with the new platform.
We wrote the application in Swift, Apple’s language for creating native applications for iOS. Moving onto a mobile application allowed us to take advantage of the native capabilities users have come to expect from a mobile application, such as push alert notifications, connectivity, and most importantly of all, portability.
In addition to technological confusion there were concerns surrounding signal inaccuracies causing delays in the system, routes changes, buses that are late due to traffic and ever changing New England weather. Users feared that the application or the district infrastructure wouldn’t be able to keep up with these altering conditions.
To remedy this we have implemented a status bar to provide feedback and reassurance to parents when the app successfully gets updates from the buses in addition to updates from individual bus assignments. Along those lines, we also implemented a button that functions to allow parents to refresh the app manually to provide further reassurance that the application is polling correctly and that they are receiving the latest up-to-date information.
Many users were confounded when they logged in and were presented with a map of the school district. When buses did not appear during school hours, they didn’t know if they had to do something to see buses. Users believed they would be able to see buses at all times even when they were not in service. Further questioning revealed users ultimately felt the need to refresh manually. And not without reason, especially when the application indicated “recorded two minutes ago”; users simply couldn’t trust the accuracy of data without some action.
Our interface changes includes a redesign of the bus icons and rewording of the ‘last updated’ message. Our bus icon formerly displayed the child’s initials ( as seen above) had suggested to users the present location of the child rather than its intention which was the location of the bus that child is assigned to. Targeted improvements like these made using SchoolBot more simple and trustworthy to the user.
Alongside the mobile application we have also added an in-app and push notification system as an addition to various map improvements. Currently, under the notification settings, users can set the radius, days and time of notifications they would like to receive for each child. When the bus enters the radius of the user’s home, they shall receive an alert and know that it is time to leave. Appropriate user messages, presented at appropriate moments now relieve the user fears that they’re using the application incorrectly.
We agreed that SchoolBot must make existing and established routines better rather than exist apart from them. There are many interlocking systems at the district and end-user levels that had to be taken into consideration while designing a school bus application. For instance, we came to the understanding short after we started testing the application that parents are familiar with a certain school transportation lexicon such as bus numbers and route names, and if these terms were not present in the user interface, parents may have difficulty understanding what they are looking at. Maintaining such relationships between the bus driver, school district and parents helps them feel their children are safe.
The process excited us from the start as it impacted a lot of people and helped improve the morning and afternoon routine for families. From development to post-launch, working directly with users and closely collaborating with school administrators enabled us to empathize and understand the process users go through almost every morning. Our usability tests helped us build not only a beautiful product but something that arises to the needs of the user.
Note: I’d like to thank Dewar Tan for co-authoring this article.