Redesigning the OneBusAway App
Feb to May 2015
This was a 4-months long masters thesis project undertaken by me alone, under the guidance of my ever helpful guide, Prof. Kari Watkins. In this project, I redesigned the OneBusAway app.
OneBusAway is an open-source app that presents realtime information about when a bus/train arrives at a stop/station. I was a frequent user of this app, and I felt it could use a some user-focused design to improve the experience of its users.
I conducted my research by speaking with 100 random public transit riders. I learned about transit usage patterns, use of schedules, and attitudes towards realtime information. I also learned more about the demographic of the users of the app. I used the insights from my research to build a prototype of the redesigned app, and tested it with actual users to uncover aspects of teh design that didn't work, and to improve the design. I conducted three iterations, each time learning more from the testing phase.
Why Work on OneBusAway?
1. Realtime information is proven to improve the ridership experience. A lot of past work has been done on the value of access to realtime transit information. It can make riders feel like they're having to wait for lesser time    to catch their bus/train. It also boosts satisfaction with the transit system  , and potentially leads to increased ridership (which makes transit more viable in turn - a virtuous cycle).
2. Mass transit is more carbon efficient and space efficient. With each passing day, we know two things are happenning: the world is growing both warmer, and more populous. Effective mass transit can help reduce per-capita carbon emissions at a scale that no other technology facilitates. One other factor is this: space in our cities is a limited resource, and mass transit makes efficient use of public space by far. We've all seen images like this:
My hope is that a better transit riding experience can lead to more people choosing to take transit more frequently.
This is the high level sequence of steps I planned to follow during this project. I started by conducting a survey to learn more about transit riders — their habits, preferences and attitudes towards transit information. Then I followed it up with iterative design, prototyping and testing.
The target audience of the OneBusAway app is transit riders. I realized that I needed to know the answers to the following questions about transit riders in order to inform the design of this app:
- What does the "repeat behaviour" of transit riders look like?
- How do they use transit schedules currently?
- How valueable do they think realtime transit information is to them?
To learn about all these aspects, I conducted short 15-minute-long stuctured interviews with 100 randomized transit riders from various bus and train stations around Atlanta, and analysed the data that I collected during the interviews.
1. Repeat Behaviour
I found that almost 80% of riders repeated the same trips 4 times a week, and used a very small number of routes over and over again.
2. Use of Schedules
About 35% of riders either remembered the schedule, or looked it up a day before, and didn't refer to schedules at all subsequently, while 46% or riders looked up the schedule either a few minutes before leaving for the transit stop, or on their way to the stop.
3. Attitudes towards Realtime Information
All respondents were asked what they thought about realtime arrivals info. A few emergent themes from their responses were:
- Planning: This was the most emergent theme from all the answers. Realtime information is only helpful several minutes before their trip starts, and does not help in planning trips at all. Even among riders who used realtime information, 40% of riders said they thought schedules were important to them.
- Reliability: Many respondents had tried realtime information apps in the past, and they had found the information to be unreliable, and hence had lost faith in realtime information.
- Lack of mobile internet: Another prominent theme was that a large portion of the survey population did not have persistent data connections on their phones. Without this, realtime information will not be available at all.
I drew a few key insights from my observations:
- Transit usage is overwhelmingly habitual. This gives the app an opportunity to learn and predict what information is most useful to a user at a given time, day and location, and should be able to surface the relevant information automatically. This would hopefully reduce the need for the user to search for the relevant information manually.
- Schedules are important, despite realtime information. A significant subset of tarnsit riders look up transit information well before they need to catch their bus/train. For such users, realtime transit information adds no value. For these users, OneBusAway app be beneficial only if it provided scheduled information as well.
- Transit riders may not mobile data on their phone.. This makes it impossible to serve realtime data to this set of users when they're at a bus/train stop without access to wi-fi. This further strengthens the case for serving schedules as well.
A note about offline usage
OneBusAway also supports an SMS interface for users who do not have a smartphone, or a mobile data connection. A rider can text a stopcode to it, and get back arrivals information. The affordances of that interaction do not support a lot of convenient information discovery though. I chose to not design for that interace, as it would be a separate project on its own.
A Heuristic Evaluation
Before heading on to do a redesign, I also reviewed OneBusAway's current design and made notes about interactions that could be improved.
Screenshots of the Android and iOS apps at that time
- Map-first interface was not the best for usability. It was hard to locate and pick stops on that map, especially when the map was zoomed out too far, or in crowded areas where transit stops were densely packed in space.
- The app did not capitalize on the habitual nature of taking transit. There was no notion of recent stops. While stops could be bookmarked, the "bookmarks" were buried inside a hamburger menu, and were not easily discoverable and accessible.
- The app did not display transit routes - only stops. This seemed like a lost opportunity, since displaying routes on the map can lend structure to the stops shown on it, which otherwise seemed like a random distribution.
- Unintuitive color codes: The app uses arbitrary/unintuitive colour codes to represent lateness/earliness in arrival ETAs when realtime data is present.
- Unintuitive search: The "search" feature in the app is not intuitive. The results don't distinguish between stops and routes, which makes the results confusing to the average user.
- There were other unintuitive elements. The app used arbitrary colour codes that indicated whether a bus/train is late or early. The app's search feature returned both matchign stops and routes, without distinguishing between them clearly.
Based on the insights of the user research, and a heuristic review of the then current app, I chose four main focus areas for the new designs:
Focus areas for the redesigned app
Aspects that were not focussed on deliberately
I saw that there were other opportunities to improve the app as well. Transit planning was a feature that the app didn't have, but is very useful to new transit riders. However I didn't focus on that because I would need to research a different segment of users to understand them. There were also opportunities for improving the search functionality, but those were not addressed purely based on constraints in time.
The First Iteration
Screenshots from the first prototype
I conducted user testing with a few volunteers, to find out whether:
- The design is easy to understand and learn without assistance
- Users can tell the arrival ETAs from the design easily
- Users can discover the route schedules and understand them easily
- To see if showing routes and vehicle positions on the map is reported as being helpful
- Whether users can understand and use the notion of faviourite stops easily
Testing with this first prototype revealed several flaws with the design.
Feedback collected from user testing
Second Iteration - A High Fidelity Prototype with Improvements
As a next step, I built a high-fidelity prototype of the app. This prototype looked and felt like a real app, and problematic interaction patterns from the previous design were fixed.Prototype 2
In this design, I had fixed several interaction quirks that were discovered from the previous round of testing. Feedback from this version was more positive than from the first prototype:
Feedback collected from testing the second iteration of design
In this iteration, the display of summary information was enlarged, and the presentation of detailed arrivals information was fixed, and combined with a preview of the schedule. The representation of vehicles positions on the map was also fixed to avoid confusion with other icons.
With this prototype, I conducted more full-fledged usability tests with 12 participants.
- During each testing session, the dummy data in the prototype was customized based on the location where the test was conducted. This way the test felt more realistic.
- Each testing session lasted around 15 minutes. The test participants were asked to perform several tasks, like finding the ETA of a bus at a given stop, looking up the schedule, making/removing favourites, etc.
- Test participants were asked to voice their thoughts aloud as they performed the tasks, and at the end, to give general feedback about the whole experience.
- Ease of use: This final prototype performed the best of all. All 12 test participants were able to use it without prompting. The information architecture was instantly understood, and there was no confusion as to which information was being presented. Interactions such as side scrolling, locating vehicles on a map etc were done easily.
- Use of favourites: All participants were able to identify the favourites, and add remove stops from the favourites. When asked what they thought this meant, they were able to express that this was meant to help them see their most used stops at the top of the list.
- ETAs and Schedules: During the test, testers were asked to tell when a specific bus would arrive at a stop. All participants did this without fail. Another information retrieval task was to find out how often that bus arrives in the evening after 5pm, and they were able to look up the schedule, and see this information.
- General feedback: The concensus from all the participants was that the app was very simple and easy to use on the whole. However on the subject of the usefulness of seeing vehicle positions on the map, opinion was divided. Some said that the map positions were useful, while others said they would not rely on it at all, and only found the numerical ETA helpful.
The process taught me several things about doing design:
- Keep research cycles short: I realized that I should have done a shorter research cycle, and analysed my collected data periodically to see if collecting more data is changing my overall observations. I could have reached the same conclusions in a smaller time span.
- Keep an eye out for unexpected discoveries: When I started research, the aspect whether users had data plans was not even part of my research questions. Yet, that insight strengthened my conclusion that serving offline schedules should be a part of this app.
Is There More?
While this app is focuses on providing transit arrivals information, this is not everything that a transit rider looks for. Some aspects of transit that also merit attention are:
- Trip planning is another frequent activity that riders do, but frequent riders and new riders do it differently.
- Communication between riders and transit agencies is another area to look at. Many transit agencies are looking for better ways to interact with their riders, e.g., to get feedback, to disseminate travel alerts and changes in schedules, to crowdsource service/infrastructure issues etc.