Jump to final solution

Final
solution

Final
solution

UX Design Interaction Design Prototyping

UX Design Interaction Design Prototyping

UX Design Interaction Design Prototyping

Addressing Rider Discomforts on BART with a Mobile App

Addressing Rider Discomforts on BART with a Mobile App

Addressing Rider Discomforts on BART with a Mobile App

Role

UX Designer

Context

UC Berkeley Human-Centered Design course project

Timeline

April 2020

Team

Solo project

Problem

Users are frustrated and fearful when taking BART, the major subway in the Bay Area.

Users are frustrated and fearful when riding BART trains.

Solution

A mobile app that not only modernizes paying for BART fares, but also connects riders to BART police and staff quickly so that they can feel safer.

A mobile app that not only modernizes paying for BART fares, but also connects riders to BART police and staff quickly so that riders can feel safer.

Background

BART, or the Bay Area Rapid Transit subway system, is the cheapest way to get around the Bay Area while avoiding driving in heavy commuter traffic. Many Bay Area residents hesitate to take advantage of this transportation option.

User interviews reveal consistent stress when taking BART

Many Bay Area residents hesitate to take advantage of this transportation option. 12 BART users were interviewed to better understand how the experience of riding BART could be more appealing.

Based on these interviews, the journey map below indicates the level of stress that a BART rider undergoes at each step of the travel experience.

Issues that users have with BART:

  • Riders do not want to refill Clipper cards at machines at the station because they are outdated, slow, and confusing.

  • The trains and stations are visibly dirty and unsanitary.

  • Riders do not feel safe at stations or on trains.

Prioritizing only the most impactful features

I started with rough sketches to map out the user experience and to decide which features were ready to be designed, which needed more refinement, and which could be cut entirely.

I started with rough sketches to map out the user experience and to decide which features were ready to be designed, which needed more refinement, and which could be cut entirely.

I started with rough sketches to map out the user experience and to decide which features were ready to be designed, which needed more refinement, and which could be cut entirely.

I explored ideas such as Google Maps integration, but given the time constraint of this project, I decided to focus on features that were directly relevant to the key pain points from user research.

I explored ideas such as Google Maps integration, but given the time constraint of this project, I decided to focus on features that were directly relevant to the key pain points from user research.

I explored ideas such as Google Maps integration, but given the time constraint of this project, I decided to focus on features that were directly relevant to the key pain points from user research.

Key features

  1. "Refill your Clipper" & "Purchase a ticket" 💸
    So that riders don’t have to use the station machines

  1. "File a cleanliness concern" 🧹
    So that stations are cleaned more frequently

  1. "Emergency button" (call BART police) 🚨
    So that riders feel protected

Rethinking the "Emergency button"

-User testing quote

"You should be able to define what the emergency is when you press that button." - User testing quote

"You should be able to define what the emergency is when you press that button."

After presenting sketches of the four key features to two users, the feature that changed the most was the “call BART police” button.

After presenting sketches of the four key features to two users, the feature that changed the most was the “call BART police” button.

After presenting sketches of the four key features to two users, the feature that changed the most was the “call BART police” button.

One of the users recommended that I focus on making the feature about sending the police a more descriptive message, rather than a general alert, to maximize the speed with which authorities can help.

One of the users recommended that I focus on making the feature about sending the police a more descriptive message, rather than a general alert, to maximize the speed with which authorities can help.

One of the users recommended that I focus on making the feature about sending the police a more descriptive message, rather than a general alert, to maximize the speed with which authorities can help.

This got me thinking about how I could make the alert fast, but also adequately descriptive for the BART police on the receiving end.

This got me thinking about how I could make the alert fast, but also adequately descriptive for the BART police on the receiving end.

This got me thinking about how I could make the alert fast, but also adequately descriptive for the BART police on the receiving end.

Wireframes and initial user testing

With the first round of feedback noted, I made a wireframe of an emergency button with a drop down menu, so users could quickly choose a category that their alert falls into without having to type out a message. I also made wireframers of the other features and conducted a usability test.

With the first round of feedback noted, I made a wireframe of an emergency button with a drop down menu, so users could quickly choose a category that their alert falls into without having to type out a message. I also made wireframers of the other features and conducted a usability test.

With the first round of feedback noted, I made a wireframe of an emergency button with a drop down menu, so users could quickly choose a category that their alert falls into without having to type out a message. I also made wireframers of the other features and conducted a usability test.

I also made wireframes of other features to conduct usability tests for those as well.

I also made wireframes of other features to conduct usability tests for those as well.

I also made wireframes of other features to conduct usability tests for those as well.

I also made wireframes of the payment features and submitting a cleanliness report, to conduct usability tests for those as well.

Insights from testing—Users didn’t understand the features and system statuses

"Is there a way to add the selected amount to my card? I don't see a button.”

"I would like to see a confirmation message after submitting a cleanliness concern."

"Is refilling my clipper card and purchasing a ticket the same thing?"

Overall, testing indicated that some of the features and functions were not being communicated sufficiently to the user.

Overall, testing indicated that some of the features and functions were not being communicated sufficiently to the user.

Overall, testing indicated that some of the features and functions were not being communicated sufficiently to the user.

For the high fidelity iteration, I took this feedback into account by adding more confirmation messages, "submit" buttons, and explanations for what different pages are meant to be used for.

For the high fidelity iteration, I took this feedback into account by adding more confirmation messages, "submit" buttons, and explanations for what different pages are meant to be used for.

For the high fidelity iteration, I took this feedback into account by adding more confirmation messages, "submit" buttons, and explanations for what different pages are meant to be used for.

Final solution: Giving the user more information in high fidelity prototype

For the high fidelity prototype of the app, I integrated the feedback I received from the usability test by adding confirmation pages, toggles for different system states, and more text descriptions.

For the high fidelity prototype of the app, I integrated the feedback I received from the usability test by adding confirmation pages, toggles for different system states, and more text descriptions.

For the high fidelity prototype of the app, I integrated the feedback I received from the usability test by adding confirmation pages, toggles for different system states, and more text descriptions.

I incorporated visual style from the official BART branding guide, such as the logo, colors, and fonts.

I incorporated visual style from the official BART branding guide, such as the logo, colors, and fonts.

I incorporated visual style from the official BART branding guide, such as the logo, colors, and fonts.

<— The circular countdown emergency button was changed to a regular rectangular button to maintain more consistency within the design system, as well as being more space efficient.

The circular countdown emergency button was changed to a regular rectangular button to maintain more consistency within the design system, as well as being more space efficient.

The circular countdown emergency button was changed to a regular rectangular button to maintain more consistency within the design system, as well as being more space efficient.

<— The circular countdown emergency button was changed to a regular rectangular button to maintain more consistency within the design system, as well as being more space efficient.

<— The toggle was added for the user to quickly see different options for quickly adding money to their Clipper card, for clearer visibility of system status.

The toggle was added for the user to quickly see different options for quickly adding money to their Clipper card, for clearer visibility of system status.

The toggle was added for the user to quickly see different options for quickly adding money to their Clipper card, for clearer visibility of system status.

<— The toggle was added for the user to quickly see different options for quickly adding money to their Clipper card, and clearer visibility of system status.

<— The cost was made larger and in bold for improved visual hierarchy, as users need to be able to scan the page for information.

The trip cost was made larger and in bold for improved visual hierarchy, as users need to be able to scan the page for information.

The trip cost was made larger and in bold for improved visual hierarchy, as users need to be able to scan the page for information.

<—The cost was made larger and in bold for improved visual hierarchy, as users need to be able to scan the page for information.

<— I changed the side navigational bar to a static bottom navigation bar. This increase in visibility will make it faster for users to navigate to different pages.

I changed the side navigational bar to a static bottom navigation bar. This increase in visibility will make it faster for users to navigate to different pages throughout the app.

I changed the side navigational bar to a static bottom navigation bar. This increase in visibility will make it faster for users to navigate to different pages throughout the app.

File a cleanliness concern feature

If I could go back, I would…

  • Do competitive analyses, especially for the emergency button, to draw inspiration for what a user’s mental model may look like for each feature before jumping into design

  • Conduct concept validation testing with the high fidelity prototype instead of just the low fidelity prototypes. Low fidelity prototypes are harder for users to interpret, so they may have clearer or stronger opinions based on a more realistic visual representation.

  • Get a quantitative metric for how likely people would’ve rode BART without this app vs. with this app to obtain a clear measure of success.

  • Do more design explorations of the other features and screens besides the emergency button.

What’s next?

What’s next?

What’s next?