The Scope
Roles:
- UX Research
- UX Design
- Visual Design
- Prototyping
- Usability Testing
Tools:
- Figma
- Google Surveys
Team and Timeframe:
Four weeks from initial planning to final prototype. As my first solo project, I relied heavily on my cohort-mates and instructors at Thinkful, including my mentor, Tom Green.
The Background
The fictional transit agency Midwest Metro oversees public transportation for a mid-sized metropolitan area. Due to an expansion of services and an increase in the number of running bus lines, they have deemed it necessary to create an app for their riders.
The Problem
Simply put, Bus riders need an app that clearly communicates when each bus arrives at the Washington & State stop, how much time to get to the stop before the bus arrives and shows all of the ETAs for any given line at the stop. The solution to this issue should deliver an effective way to discover and display this information, whenever the bus riders need it.
As such, the app needs to address the following questions:
- First, how might we inform riders when each bus arrives at a bus stop (for example, the troublesome Washington & State stop)?
- How might we ensure that riders know how much time they have so they can get from their current location to the stop before the bus arrives?
- How might we allow riders to view all the ETAs for a specific bus line (for example, any of the seven that service Washington & State)?
In addition to answering these questions, I was allowed to add an extra feature based on my research.
The Users
Ideally, anyone who came to this metropolitan area and rode the bus in any capacity would be able to use and understand the app. However, for the purposes of the project, I narrowed my target audience to the following:
- Users over the age of 15.
- Users who ride the bus at least once a week.*
- Users who have used transportation apps (such as Google Maps or Transit) in the past.
*Due to the COVID-19 pandemic changing the habits of bus riders everywhere, users were allowed to indicate they rode once per week before the pandemic to pass the survey and user testing screening processes.
The Solution
The fully-functioning app — called “CHASR” — allows users to search for their bus stop, see when specific lines are arriving, and report suspicious activity to transit authorities. While currently populated with fictional bus stops, the app is styled and branded, so future development is possible.
DISCOVERY
Proto-Personas | User Surveys |User Interviews |Competitive Analysis
The Research
To start, I built several proto-personas to get a feel for what I might be looking at in terms of user needs and frustrations. I created these personas from several instances where I interacted with the bus system in my college days.
With this baseline established, I wanted to examine the thought processes and tools utilized when choosing to ride the bus. This drive resulted in three primary research objectives:
- Uncover participants’ thought processes and prior experiences in finding a bus to ride.
- Discover the different tools participants use when choosing a bus and how they feel about each one.
- Learn about pain points the participants are encountering during their journey and what improvements they would implement or suggest.
With this in mind, I started with some statistical research. First, I looked up information from RTD-Denver and the Chicago Transit Agency (CTA) regarding the number of boardings they have in a year, the number of lines, the number of stops, and their reported accuracy numbers. I also looked up data from the U.S. Census Bureau as to how many people ride the bus. This information helped inform the screeners I wrote for my survey and interviews and gave me an idea of just how many might use the app in the future.
For my competitive analysis, I compared the features across three popular transportation apps (Google Maps, Transit, and Citymapper) and one independent app with schedules and routes for the CTA (Transit Stop). Key features I examined included app store ratings, notifications features, travel options and stop features. In addition, I completed in-depth SWOT analyses for Google Maps and Transit Stop to take a closer look at possible viable features.
With all of this generative research completed, I built a survey to gain quantitative data regarding users’ experience with their current bus system. This data would also serve as the base demographic data for the later personas. To complement the information gathered in the surveys, I also conducted interviews with survey-takers who agreed to additional research. This qualitative data gave me more specific insight into pain points and individual experiences, which the survey couldn’t capture.
The Findings
Let’s take a look at some key findings:
Millions of people ride the bus.
- Based on the census data and a quick Google search about the population of the Midwest, about 2 million people used the bus to get to work in that region in 2019.
- The American Public Transit Authority (APTA) expects a rise in ridership with loosening COVID-19 restrictions. (Not surprising, but still relevant)
- 95% of surveyed bus riders who ride the bus more than once a week used an app to plan their bus trips. This data indicates I’m reaching a wide demographic.
Users think the bus isn’t as accurate as it may be.
- According to a federal study, CTA’s buses are on-time 92% of the time.
- RTD-Denver reports their buses are on-time 87% of the time.
- While this is all well and good, on average, the surveyed and interviewed riders feel that the buses are closer to 67% accurate. Additionally, the interviewees felt the apps they currently use do not reflect the most up-to-date times — making it a challenge to overcome.
Users use Google Maps but feel it isn’t accurate.
- 16 of 21 survey-takers use Google Maps. Of these, half also use other apps to plan their trips (most of them directly associated with a regional transportation agency).
- Users expressed concerns that Google Maps uses the same information as a paper schedule – which doesn’t help figure out a plan.
- Google Maps ratings are lower than other apps on the Google Play Store.
- Reviews on the Google Play Store indicate the app’s accuracy is in slow decline.
Crowding and safety are some of the chief complaints among users.
Notable Quotes:
- “It can get crowded at peak times and uncomfortable.”
- “Less people, more comfortable.”
- “… overcrowding at rush hour…”
- “Some people seem to take bus etiquette very easily, while others stretch everywhere or talk very loudly. Most people want a quiet ride.”
- “There’s a lot of sex-based harassment.”
- “… there are also safety concerns.”
DEFINITION
Personas | Experience Mapping | User Stories
From the collected and collated data, I built four distinct personas. While this may seem like a lot, I felt this gave me a complete picture of the data acquired to this point.
With these personas, I constructed an empathy map and a journey map. Like the personas, these helped shape the user experience so I could physically see and track. Finally, with everything in place, I created a collection of user stories to help determine the high-priority flows of the project.
Some of the user stories I did not pursue:
Using location services to see how to get to a bus stop.
- This feature would fall under trip planning. While it’s practical, it’s a standard feature among transportation apps, and I wanted to differentiate from the market at large.
Showing the user traffic alerts.
- Rider alerts like this are common in transportation apps, but at present, the concern primarily surrounds when the bus is arriving, not why. There are also certain instances where there is no way to accurately tie an alert to an ETA (i.e., mechanical failure or emergencies).
Saving bus stops or bus lines.
- While this should certainly be an option in the future, I opted against it for the time being, as the brief focuses explicitly on one bus stop: Washington and State. In addition, it wouldn’t make sense at this juncture to favorite bus stops or lines that don’t have anything to do with that stop.
The Planned Route
With all of this data, I was able to plot out the app’s direction:
- The app’s interface should be straightforward. Many of the current apps on the market have interfaces with too many features or information overload.
- Based on my research, I opted to create a reporting feature. I deduced that making a feature regarding the crowding on the bus wouldn’t be feasible – the transit agency likely doesn’t have the means to record when a rider boards and disembarks. Furthermore, it doesn’t seem likely that a user would be willing to constantly update the app about the conditions on the bus (i.e., crowdsourcing).
- I looked at the Uber and Lyft app models and a lack of incident reporting outside of ride reviewing. It’s not an overly common feature (aside from RTD-Denver’s independent app) on bus apps, which may appeal to female riders. Considering a function like this reminded me of a roommate’s experiences as a bus driver. She’s virulently allergic to marijuana, and there were several occasions where a passenger smoked it and sent her to the hospital. A report feature may provide the opportunity to investigate issues like this better.
DEVELOPMENT
User Flows | Sitemap | Sketches | Wireframes | Prototype, v1
I developed four user flows from my user stories: three to address the main project brief and an additional for my reporting feature.
These user flows governed the creation of my sitemap. The sitemap gave me an idea of how to proceed with sketching and wireframes.
With my wireframes, I wanted to keep the design as basic as I could. On the other hand, I had no idea what to expect regarding layout and the number of pages. This inexperience led to more pages than needed in the low-fidelity prototype, but I did not have a way to parse this down.
DESIGN
Branding | Prototype, v2
The Aesthetic
I started my design process by giving the app a personality of its own. This quasi-persona, Chase, informed my mood-board search, broken into three components: colors, styles from Dribbble and Behance, and bus designs. I wanted to convey a relevant and youthful design that still evoked the imagery of a bus. The app personality also influenced the app’s name, as “CHASR” is a natural extension of the name “Chase.”
The color scheme was based, in part, on a single color found in the mood board: one of the Sherwin-Williams colors for the state of Ohio. I found the color very visually appealing, and it doesn’t seem to cause any wear on the eyes. However, I also opted to design the app with a darker color scheme due to personal preference (I often use ‘dark modes’ in any applications or websites because the bright white backgrounds in ‘light mode’ are often too harsh for me).
I continued searching through Adobe Behance for typefaces, where I found Atami. This open text font is easy to convert and has an appealing, approachable appearance — it’s great for headings. To complement this, I chose the Alata Google typeface for the body text. It closely resembles Atami’s lines and is easily used for app and web use.
The Atami typeface has several font styles: Display, Regular, and Stencil. For the logo, the ‘CHAS’ is in the regular font, while the ‘R’ is in the display font. In addition, an arrow runs through the ‘HASR’ to evoke the common theme of lines on a bus.
Keeping it Accessible
I achieved accessibility in the app in several ways:
- All buttons have icons that reflect the meaning of the buttons.
- Color contrasts are, at minimum, WCAG AA compliant across the board. (Most are also AAA compliant for large text and icons).
- The minimum size font is 16pt, and it appears sparingly. The following largest font is 18pt.
- Aside from the home page and the report landing page, all pages are consistent in layout, and all icons meet iOS’s size requirements for a minimum touchable area.
- Finally, when fully developed, voice commands via the search bar and keyboard would be available.
With the branding completed, I could finally develop a high-fidelity prototype:
The Testing
I conducted user testing with three participants — two from the user survey and one outside the target audience (as a test-to-break scenario) — via Zoom. They walked through two scenes to test the app’s primary business goals and flows in this testing.
The Good
- The app is easy to use overall.
- Users praised the design and had minimal design inputs.
- The use of symbols was effective – no user had trouble understanding their meanings.
- On user suggestion, future versions may have a more descriptive map.
The Bad
- Misclicks were mainly due to confusion on the Washington & State Stop Page.
- Dropdown menus on Washington & State Stop Page were ineffective.
- The direction of the chevrons (currently pointing to the right) confused users into thinking it was directing them to a new page.
- The chevron’s touchpoint was too small – the entire row should activate the dropdown.
- The chevron was too close/outside of safe area margins.
- The descriptive text for bus lines was too small.
DELIVERY
Prototype, v3 | Mockups
The Final Product
With the data I gained from the user testing, I developed this final prototype. This MVP successfully fulfills all three points of the original brief, and the users who have tested it enjoyed the interface’s look, and the simplicity of the user flows. In addition, the additional reporting feature is practical and easy to understand.
Recommendations for the Future
Were this an app that was in development, I would recommend the following:
- While I opted against creating a trip planning feature for the minimum viable product, it’s something that developers should add in the future.
- In addition, I’d also recommend adding an agency alert feature. It would enable riders to understand potential obstacles in their journey (such as COVID-19 rider restrictions or traffic hazards).
- Another feature that would be useful to add soon would be live bus tracking. This aspect was mentioned by some of the interviewees – particularly about Uber’s driver tracking.
A Few Final Thoughts
As my first project in UX, I learned quite a bit about the research process.
- Specifically, I learned that I may have been too strict with my survey screeners early on. For example, the initial user group had to ride the bus twice a week, but early survey results showed that most of the people who had taken the survey did not ride with that frequency. So, for the remainder of the study, I adjusted the screener — users only had to ride once per week to participate.
- In addition, I feel that I would have benefitted from having my usability testers give an overall rating for the prototype’s design and experience. These ratings would help me focus on the big picture for the testing and keep the size of any issues in perspective.
- Finally, I struggled to keep the scope of the project in mind. As a result, I often added more features than allowed, which slowed down the process in the early stages. In the future, I will need to keep a better focus on the scope so my projects will be more laser targeted.
Thank you for reading!
Feel free to check out my other case studies: