Buster: A bus tracking app for the city of Detroit

UX Design Sprint
Project Overview
Many Midwestern cities are doing their best to stretch public transit funds by reconfiguring existing infrastructure. While these initiatives create a leaner bus system, sudden changes can leave current riders frustrated and confused, and potential new riders turned off.

In Detroit, these consolidation efforts are at their most confusing downtown, with one stop in particular, Washington Blvd. at State St., which now services 7 bus routes. How can we remove a barrier between an action designed to help riders and the confusion of learning something new?

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.
Roles + Responsiblities
Roles: UX Design, UI Design, UX Research
Tools Used: Figma, Miro, Google Forms
Deliverables: Target Audience Report, User Personas, User Flows, Sketches, Wireframes, Paper Prototype, Clickable Prototype, (low fidelity), User Testing Summary, Summary of Findings, Development Plan
Jump to section:
Problem/Solution
Research/Discovery
Information Architecture
Branding
User Testing
Next Steps
Clickable Protoype
Iphone on a blue background with the logo for a bus app on the screen.
Problem: Riders have to acclimate quickly to new service changes, and have been “learning the hard way” about the updates by missing transfers, running for the wrong bus, and a bevy of other pain points.

Solution: Buster provides real time tracking of city busses. Riders will know how much time they have to get from their location to a stop, see which bus is coming next to that stop, and plan future trips based on future arrival times, all wrapped up in a clean interface that can be used while running to the bus stop.
Problem + Solution
Apr 2015 — Mar 2016
Apr 2015 — Mar 2016

Part 1: Research & Discovery

User Survey:

The process began with a user survey to determine users’ pain points and desires in a transit app, as well as to determine viewport requirements and identify competitors. Our survey ran for one week in various transit Facebook groups and Subreddits.

Research Highlights:

49%

Ride the bus at least 5 days a week

56%

Miss the bus at least once a month

78%

Make no transfers
Top 3 most requested features

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.

User Interviews:

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:

Competitive Analysis

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.

Google Maps

The Google Maps logo
Strengths:

Name recognition
High level mapping showing stops integrated with other landmarks

Weaknesses:

Does not offer live updates
Can't search by route

Opportunities:

Offer real time information

Threats:

Local transit agencies creating own apps instead of collaborating with Google

Citymapper

The Citymapper app logo
Strengths:

Offers live updates of vehicles
Robust search function

Weaknesses:

Live updates for only certain routes
Map view does not show all possible stops

Opportunities:

Show all possible stops around user's location

Threats:

An app with regular access to live updates

Moovit

Logo for the app Moovit.
Strengths:

Countdown until bus arrival
Shows all bus stops near a users location

Weaknesses:

UI crowded with multiple confusing icons
No heirarchy amongst text

Opportunities:

Streamline UI

Threats:

An app with the same features but clean interface

User Personas

After my user survey and interviews, I funneled that information into these user personas. They represent our target audience

Image of a woman for a user persona

Evelyn

42 year old Paralegal
Motivations:

Evelyn has a car but works in the city center and prefers to use the bus to avoid paying for parking and the struggles of finding a spot.

Goals:

Evelyn wants to make it to the bus on time or she will have to drive to work to make it in on time.

Frustrations

Having to juggle between several apps to try to estimate when the bus will actually come.

Image of a woman for a user persona

Vikki

29 year old librarian
Motivations:

Vikki cares about the earth but city traffic is too unpredictable for her to feel safe commuting by bike.

Goals:

Vikki wants to commute safely and quickly. She lives near several bus routes so there is no reason not to take the bus.

Frustrations:

There are several busses that can get her to her destination, and often she sees one leaving from another stop while she is stuck waiting at another one.

Image of a man for a user persona

Dan

33 year old nurse
Motivations:

Dan works long hours and public transit is a great way to relax while also getting to work safely. As long as things are timed right he can get a nap in before or after a shift.

Goals:

Get downtown in time for a transfer

Frustrations:

Incorrect information has Dan missing his connecting busses and adding to his commute time

Part 2: Information Architecture

User Stories

In order to stay within the scope of our MVP, I generated User Stories, which prioritize important features for the app that align with the users' goals.

Chart of an app user's important tasks to complete

User Flow

A user flow begins the process of converting our research into actionable screens.

User flow diagram showing how the app will function

Sketches/Paper Prototype

I created some rough sketches based on the user flow diagram which allowed me to test the flow and experiment with some basic layout choices

Rough sketches of the layout of a mobile app

Wireframes

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.

Image of a map on a screen of a phoneImage of a map on a screen of a phoneImage of a map on a screen of a phoneImage showing directions and a map on a phone screenImage showing a map and bus arrival times on a phone screenImage showing a map and bus arrival times on a phone screenApp screen with message "Success! Stop name has been added to your stops"Image of an app screen with the message "Sucess! Stop name has been removed from your stops!"Image of a mapImage showing a map and bus arrival times on a phone screenList of bookmarked bus stops on an appList of bookmarked bus stops on an app

Part 3: Branding

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.

Mood Board:

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.

Mood board for an app. It shows a grid of images of a smiling bus, a vintage alarm clock, fun upholstery and fruit shaped bus stops.

Color, Type, & Logo

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.

This is a style tile for an app. It shows several colors that will be used and samples of typography.

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.

A B with a star as a logo for a mobile bus appA map pin with a bus contained in it.An illustration of an unfolded map with the word BUSTER underneath.

Part 4: User Testing + MVP

Cllickable Prototype

User Testing

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.

1. Confusing use of color

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.

App showing bus arrival times
App showing bus arrival times

2. Adding Route Info for All Stops

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.

App showing bus arrival times
App showing bus arrival times

Working Prototype

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.

Part 5: Takeaways & Next Steps

What I learned:

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.

Next Steps:

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.

See Next Project
Bunker Projects Web Mag

Want to get in touch?
Drop me a line!

Questions? Comments?Critiques? Collabrations? 
Let's go!

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.