Project Update
February 10, 2022
Redesigning the Harvard Shuttle app
We designed a new version of the Harvard Shuttle app to enable ride booking, scheduling and accessibility accommodate.
Project Dates: FEBRUARY 2022
Built with: Figma
As part of my coursework in CS179: Design of Useful and Usable Interactive Systems, I worked with a team to solve a novel problem specific to Harvard's campus. The new shuttle system launching at Harvard requires a new app to improve the current user experience. With such a mission in mind, our group aimed to design a new experience that is both delightful and welcoming. We started from user interviews to understand the user flow when Harvard students take the shuttle. Based on the main findings, we generated a user story map and information architecture so that we can connect the dots and start prototyping. After we received feedback from the studio and cognitive walkthrough, we revised our prototype. Lastly, we did usability evaluation with potential users to further improve our prototype.
Initial Interviews
The main goal of our interview was to better understand the user flow and different personas of Harvard students taking the school shuttle. Our group interviewed 9 students attending Harvard University. Out of the 9 people, 3 are males and 6 are females. 5 of them are college students, 2 are master students, and 2 are Phd students. We also feature a diverse background of majors, ranging from history, chemistry, to data science. Some of them are first and second year students, and some are third year students, so we made sure students have different experience and familiarity levels with the campus. We acknowledge due to limitations, we did not interview any students who need accessibility support.
During our interviews, we mainly asked about the students' past experiences in taking the shuttles. Specifically, we asked about their usual destinations, how long they usually wait, and if they had any bad experiences. We found that:
Two most popular destinations of the shuttle are the Science and Engineering Complex and the Quad. The top reason students take the shuttle is to go to class. Some other reasons include grocery shopping and visiting friends.
During peak time when most classes start and end, students find the frequency of the shuttle is not enough. If the student misses the bus, they have to wait another 30 minutes for some stops or they would choose to walk to class.
Even though the current shuttle app tries to provide real-time information about the shuttle, students find the information not accurate enough.
Students want to receive recurring ETA notifications for marked routes and stops at designated times and days.
Some students bookmark their mostly used routes, while others really like a filtering feature.
One edge case we identified was students using the transit display board at the Science and Engineering Complex when checking the shuttle, while others mostly only use the app. The shuttle website is used by most students at the beginning of the semester to check which bus to take, but is rarely used later in the semester. One student checks the website when they are in class right before leaving. We did not find obvious contradictions, but students have different opinions about the overall user experience with the app. Some students find it little to complain, while others think it is terrible.
The initial user story map we created. Check the Resources section at the end of this page for the PDF version.
Designing the prototype
One of the main design goals that informed our design decisions was simplicity and readiness for use. Our users in the respective user interviews told us that they expected the process to be simple, and they did not want fancy features that complicated the process of getting to their destination. Therefore, our process starts extremely simply. By logging in with HarvardKey, we do not need to have users verify their email addresses or set and remember new passwords. The only information we collect is a preferred name, and accessibility options that the user might need, so that we can tailor their experience. Finally, after we collect their permissions for location and notifications, we give the users a few slides in a pop-up in lieu of an app orientation. Now, the users are ready to book a shuttle.
Screenshots of the Harvard Shuttle app design showing the log-in, accommodations picker and home screens.
We wanted to streamline the process both for making a trip in the moment and for scheduling ahead. We added the latter capability, as people in our user interviews told us that they would be excited to know that a shuttle is on their way once they leave class or have another commitment to get to. When a user tries to book a ride that happens in less than an hour, they are presented with the optimal pick-up stop for their destination, along with a few more options that are around them. This is because a user might want to travel to a specific side of campus before hopping on a bus, as some users told us in interviews. However, to maintain the responsiveness of our service, a popup will appear in case a user chooses a suboptimal pick-up stop reminding them of the time they could save by choosing the suggested route (we consider this a form of a nudge). In the rare case where trip will take 1.5x the time with the shuttle compared to walking to destination, or if walking takes less than 10 minutes and system is overloaded, the user will receive a pop-up encouraging them to walk instead of waiting for the shuttle (accessibility concerns and weather conditions are also considered when deciding whether to show this warning). This decision was informed by our user interviewees and their responses of when they would give up on a shuttle ride and walk instead.
Screenshots of the Harvard Shuttle app design showing the ride request flow.
Once the trip is confirmed, the user will see a map with their location and navigation instructions to their stop. Some users told us that stop naming and location is obscure, and we wanted to make it as easy as possible to navigate to the stop without having to leave the app. When at the stop, the user will get a card overlay with the shuttle number that will be picking them up. We decided to use numbers instead of colors, emojis, images, or names to protect the privacy of our users and for our app to work better with screen readers. When the shuttle is two minutes away, the app will generate a vibrating notification to alert the user and show another notification when the bus has arrived. We wanted to make sure that the bus was easy to find in a stop with many shuttles arriving at the same time, so we added a large print of the bus number on the app screen and an audible bus number announcement when it stops and opens its doors (we were inspired by the MBTA busses). The accessibility page at sign-up also gives the shuttles an easy way to understand what options they need to offer at every stop, including lowering the bus doorstep height, or using a panel for a wheelchair. We decided to offer a simple authentication method of an HUID tap at the front of the bus to speed up boarding.
Screenshots of the Harvard Shuttle app design showing how the app might suggest a better pickup stop to a user.
During the trip, the user is presented with a route map along with their ETA and the next stops. For accessibility reasons and to help anyone that is not familiar with the shuttles stops, we added “next” and “this is” audible stop notifications in the bus. The app also provides a vibrating notification that the next stop is the user’s drop-off stop, and when the shuttle arrives at the user’s drop-off stop. Because we aimed for simplicity of interactions of the user with the system, Movement tracking around the bus is used to determine whether the user has exited the bus by tracking the identified user from HUID scan to drop-off. The shuttles will wait 2 mins for users to get off before alerting the support staff and continuing the ride (time adjusted accordingly for accessibility reasons or when movement is detected).
Screenshots of the Harvard Shuttle app design showing the ride experience, including how the app notifies a rider that they have arrived at their destination.
Finally, we wanted to offer the flexibility of cancellations and modifications. Because we understand the speediness of the service makes it hard to modify an existing trip, we only offer cancellations for trips happening in less than an hour, as they enter a shuttle’s route list immediately after requesting. We also wanted to discourage multiple cancellations when the shuttle was almost at the stop, so we added a penalty for canceling if the shuttle is less than 2 minutes away. If it is a scheduled ride in more than a week (up to 7 days ahead), we offer the option to change specific parts of the ride.
User evaluation study
We ran a user evaluation with four users being presented with different scenarios that reflected the different circumstances users might experience when using our app, including different location, time of day, or wanting to schedule a ride instead of requesting an instant ride.
Based on the usability evaluation, we were able to spot some minor bugs or incorrect flows we had in our prototype. For instance, the cancel button was not working properly at the page one minute before the shuttle arrived. In addition, we added the flow that supports users to schedule a shuttle 2 hours from now if they are riding alone. We also generally improved user experience. Participants mentioned that some of the buttons move between pages. We tried to adjust them through grids so users can have a better user experience. One participant inspired us to add a notification/popup that informs the user that the bus will depart in one minute if they do not get off.
We took in the suggestions of the section participants from our class to make maps more consistent by removing scaling between pages (e.g. when selecting a pickup stop), but the users did not appreciate the small icons of stops and generally the fact that they had to squint to see all available information. We reverted to the original design and our users reacted favorably. We also decided against including the walking alternative to the user’s destinations, as many of our users told us that they would not open the shuttle app if they knew they could get there faster by walking, especially given the efficiency of pickups guaranteed by the new shuttle service.
Notes
This work was co-developed with the help of my teammates Rachna Gupta and Joslyn Fu.
