The user survey was able to give me a firm foundation of quantitative data which sometimes differed from my experience as a regular bus rider. Most users were not as worried as I am about making transfers or taking multiple busses to complete a trip.
I was able to find interview participants from the survey process, and we were able to complete a few sessions on Zoom. Key takeaways from these interviews are:
Results from the user survey and interviews as well as market research allowed me to determine our three main competitors. Studying these other apps would allow me to gain insight into the user’s mental model of a transit app as well as see which features we should emulate, as well as those which were missing.
High level mapping showing stops integrated with other landmarks
Does not offer live updates
Can't search by route
Offer real time information
Local transit agencies creating own apps instead of collaborating with Google
Offers live updates of vehicles
Robust search function
Live updates for only certain routes
Map view does not show all possible stops
Show all possible stops around user's location
An app with regular access to live updates
Countdown until bus arrival
Shows all bus stops near a users location
UI crowded with multiple confusing icons
No heirarchy amongst text
An app with the same features but clean interface
These rough sketches were used to inform the creation of wireframes in Figma. These wireframes serve as the foundation for the future UI and allowed me to conduct some user testing on key features early on, which saved me a lot of work in future iterations.
Users wanted to instantly be able to see routes near them and did not appreciate any onboarding, as they saw it as a barrier to the information they needed and just something to make them even later.
Users also commented on wanting clearer iconography, but appreciated the large font sizes in certain spots overall, althought this too needed some finesse: if EVERYTHING is important, then nothing is.
I envisioned the app being as legible and accessible as possible, aiming for a very clean interface that would allow the constantly shifting data to shine through.
This mood board is more about the "mood" of the product, although a lot of the green and blue I saw consistently through these images would make its way into the final UI. I was inspired by small design gestures that aimed to bring delight to public transit, celebrating it as a public good that everyone can be proud of and enjoy.
I wound up going with a very subtle color scheme for the main UI of the app (although some warning colors were added after user testing to let users know when they were going to miss a bus). Colors were tested and selected for WCAG compliance and accessiblity.
Roboto was chosen for its legibilty, variety of weights, and the harmony between it and its serif counterpart, Roboto Slab. This font was used to differentiate landmarks such as bus stops and destinations (fixed information) with the ever changing bold serif numerals of bus routes and arrival/departure times.
The logo went through a few iterations, but I didn't want it to be too similar to competing products, so the map pin idea was abandoned in favor of the stylized map view. The map icon would remind users that this was more than just a schedule, and remind them of the unweildy paper they would be able to abandon with our help.
I decided to name the app Buster, not just as a play on the naming convention of so many apps (Tumblr, Twitter, etc) but also to sort of humanize the app as well. I was inspired by a local bus line that goes through Charles street, flashing the name CHARLES on its display board as if it is telling us all its name. I wanted to work in a little bit of user delight in what would be an otherwise utilitarian companion for Detroit bus riders.
User testing was done via Zoom and with Figma's prototyping feature. I was most interested in ensuring users could easily complete the following tasks:
Overall my test subjects were able to complete these tasks due to familiarty with similar products, but other aspects of the prototype needed to be addressed.
I picked an alternating pastel color scheme to subtly show the differences between two lines of text, which was inspired from many of the paper bus schedules I have used before. Users wanted a little more feedback from the app to emphasize that a bus was coming soon. To reduce their cognitive load, I changed the color of the arriving bus notification bar to a red to suggest urgency.
The search results page would take you directly to the bus stop you were looking for, but did not provide enough information to users who were not familiar with the area.
Guided by the business requirements of the transit agency, and user feedback, I achieved a working prototype. Buster allows users to determine when their bus arrives, where to catch those busses, how much time they have to travel to the stop, and how to get a list of future arrival times.
This design sprint taught me so much about the User Centered Design process, especially to center all users. Although I ride the bus several times a day, I was able to learn so much from listening to users and giving them room to speak. This was my first time testing designs with users, and coming from a more tradtional design background, it was refresing to have data to drive decisions as opposed to purely aesthetic or taste based concerns.
For the next version of this app, I would want to readjust some of the color scheme as well as perform some A/B testing to test for more than just functionality. I would also like to try some bodystorming to see how exactly a user would be viewing the app on their daily commute. How would someone running for a bus read this interface as opposed to someone already seated at a bus? How would a wheelchair user view this information?
I am also be interested in trying to convert this interface into a smartwatch interface to really see how I can push the limits of delivering the most essential information to riders.
Questions? Comments?Critiques? Collabrations?