BusyBus: A Case Study in Public Transit Applications
As a student in a UX/UI design program since October I have learned an overwhelming amount of new information and have been thrown head first into new skills and technologies. To put all of this into practice, I have created parts of a mobile app called BusyBus. In this blog I am going to walk you through my steps that lead me to my final prototype and a reflection of my work and feedback from each section.
Design Problem
The scenario for this application is a large city transit system that recently underwent an expansion. This expansion has led to the addition of many new bus routes. While expansions can definitely lead to benefits, they can also lead to added complexity for the users. In this case, users were specifically complaining about stops that serve multiple bus lines.
Picture this for a second: you are a user of this public transit system. You are walking towards your regular bus stop from which you commute to work. You are about a block away when you see a bus pull up. You hold your bag tight and run to the bus stop only to find out that… it is not your bus. This situation can be easily avoided with a mobile app that reliably and accurately gives the users information about the bus stops in this city transit system.
Questions addressed by the app:
Which bus line is arriving next?
When will it arrive?
How long does the user have to get to that stop?
Research and Discovery
The first phase in creating this application was the research and discovery phase. I started by conducting both user surveys and user interviews. My user survey was completed by over 30 participants from all over the world. The survey asked them questions about their public transportation usage, their current and preferred ways to navigate their public transit systems, the applications they use (if any), and their preferences and usage of these apps.
Click here to view this survey.
I chose 2 participants from the survey to conduct interviews with. You can view the interviews here.
From the survey and interviews my main takeaways were…
70% of users feel that the most important feature on a public transit app is access to schedule and times.
67% of users feel that there are aspects of inaccuracy in the current apps they use.
65% of users feel that their apps are in some way not user friendly.
The most surprising thing I discovered from the surveys and interviews was that many people, though they may want to try a locally or regionally specific application, continue using Google apps because other apps externalize information in the sense that different features have to be viewed in a different window, on a different website, or even in a completely different application.
While completing user surveys and and interviews, I also completed a competitive analysis of the Googles Maps and RTD Denver mobile apps. I completed a SWOT competitive analysis of these two apps in order to understand the strengths and weaknesses of these apps as well as find the market opportunity for my BusyBus app.
From the SWOT analysis, I found that both of these applications were created for the purpose of helping users get to their destinations in the best way possible. Both applications use a real time navigation map to show users their current locations as well as ways to get to their destinations. The RTD Denver application sets itself apart from Google Maps by specifically focusing on the details of the Denver public transit system. This includes the routes, stations, and schedules for the street level buses and rail system. The benefit of using the RTD app is that it provides system maps and station information that Google Maps does not provide. However, this app’s weaknesses include an interface that is busy and confusing to navigate. RTD Denver also often provides inaccurate schedule and time information.
Google Maps differentiates itself from local/ regional transit apps like RTD Denver by being globally known as a reliable navigation app for multiple modes of transportation including cars, buses, bikes, walking etc. Google Maps has name recognition from the Google platform and also provides a much broader lens in terms of location and navigation. Google maps is also known for its accuracy and reliability in terms of journey times and distances. However, the weakness of Google Maps in this situation is that it does not provide bus stop specific information which is what was specifically asked for by users in this case study design brief.
From this SWOT analysis, I discovered that the opportunity for my BusyBus app would be a locally specific, reliable and accurate transit app where users can find everything they need in one app (does not externalize information). The BusyBus user interface would also need to be easy to be intuitive and easy to use in order to stay competitive in the category of transit applications. You can view a more comprehensive version of my SWOT analysis here.
I used the information I gained from this research to create a list of user priorities in the form of user stories. I created user stories in order to make sure that when I moved to the design phase, I would be able to stay focused on the most important features that would actually solve the original problem and the address needs of the users (aka avoid scope creep as much as possible)! As you can see below, the highest priorities also match those outlined in the original problem statement.
Information Architecture and Visual Design
After conducting user surveys, interviews, and a competitive analysis, I transitioned to the information architecture phase. I stared by creating sketches and lo-fi paper prototypes.
I presented my lo-fi paper prototype to different users in order to conduct usability testing.
From the usability testing, I gathered three main important takeaways:
-Participants reported feeling that app was user friendly.
-Not all participants knew that the map was interactive.
-Participants were unsure where back buttons were leading to.
I integrated this feedback into the creation of a clickable prototype in Figma. In order to address the issues brought up by the participants of the usability tests, I created clear labels for the back buttons, and made sure that the map design was created in a way that clearly showed interactive aspects. This was done by placing familiar icons such as location icons. In creating this clickable prototype I also followed the iOS Human Interface Guidelines to maintain consistency throughout my design. Here is a breakdown of how these guidelines helped inform my design decisions:
Colors
I tried to use colors to communicate and colors that would not conflict or distract from one another. I chose to use a blue to show when specific items or icons were clickable as well as to show connections between items chosen and new pages. I tried to keep my color palette consistent throughout the different screens from the button colors, information colors, and background colors. I also tried to make sure to avoid using colors that make it hard for people to perceive the content. I made sure, using the Contrast app from Apple, that my contrast ratios received an AA or AAA rating so that my app would provide optimal legibility for all users.
Bars (Status and Nav)
I used the specified navigation and status bars found within the iOS resources created for Figma that satisfied the Apple Human Interface Guidelines.
Typography
I used the typography guidelines outlined within the iOS resources created for Figma and cross referenced my choices with the Apple Human Interface Guidelines. I stuck to SF Pro Text or SF Pro Display for any text within my prototype. I used these fonts because the interface guidelines discussed how they can be used in a flexible manner at different sizes and weights while still maintaining legibility. I also used different sizes and weights to establish hierarchy of information. For example, I used font size 20 and bold style for titles. I also minimized the number of typefaces I used as per recommendation by the guidelines.
Icons
In terms of icons, I used the SF Symbols app to retrieve some icons. Other icons, I got directly from the iOS resources created for Figma. I used icon size to dictate hierarchy while also trying to maintain consistency in terms of icon size for different sections or use of icon. I provided text for some of the icons but placed the text underneath instead of within the container of the icon based on the recommendations from the interface guidelines.
Spacing
In terms of spacing, I tried to minimize the amount of information on each screen and use the whitespace to direct the user’s eye to the important information on the screen. I tried to provide breathing room between the separate pieces of information as well as provide space in a way that would make it clear when one section begun and another one ended so that content sections were clearly divided.
Development/Final Prototype
My final step in creating this application was to code the final prototype. I used basic knowledge or HTML and CSS to create the third screen of the visual prototype which lists the busses that arrive at a specific bus stop. For this final prototype, I was given more information that I needed to account for that I did not plan for in my original design such as direction of travel, busses that were rerouted, and busses that were out of service. I made decisions in the creation of this final prototype so that it would maintain consistency with the visual design and the iOS human interface guidelines in terms of features such as space, typography, hierarchy, and color choice. Due to the fact that I needed to incorporate more information than I had previously planned for, I also decided to add more labels that helped with organization of the information such as the labels “Next Bus” and “Arriving In”. During the process I faced many new challenges from figuring out how to avoid “divitus” and properly organizing the semantics of my code to figuring out how to create inline displays and other CSS basics. Though I overcame these challenges and was able to create a finished product, I know there is much more to learn and more ways that I can revise this work.
In the end, this final prototype is a solution for the problem of a transit system expansion that has led to a complexity of usage for the users of the transit system. This final product provides a simple, organized, and accurate way for riders to know what the next arriving bus us, when it will be there, and how long they have to get to the bus stop.
Presentation
The last step in the creation of this mobile app was to present my process to my project mentor. This was my first presentation of a UX/ UI based project and for it, I created this slideshow. My goal was to keep my slides simple and low in text. I wanted to present the steps I took in creating this app while proving how its creation addressed the original problem statement and the needs of the users that I discovered during the research phase of my my design process. I received extremely helpful feedback that I will incorporate into my next presentation:
-SAVE ALL ITERATIONS! → I admit that I did not save iterations thoroughly enough and now realize the importance of being able to refer back to them.
-Make it more conversational by asking questions during the presentation. Engage your audience by gathering background information at the beginning of the presentation. Pause after each section, ask if you’ve covered this portion in enough detail.
I will be working with the application more as I learn more through my program. Thank you for taking the time to read about my design process and please feel free to provide any feedback. I am excited to learn and improve!
