Passion Project— Traverse: Building an app focused on accessibility

1. Project Overview

1.0–My role

My main role was as the Project Manager working in a group with two other UX designers. This project took two weeks to complete. My role within the group consisted of:

  • Organizing and keeping track of team progress
  • Brainstorming together to come up with design solutions
  • Leading design direction
  • Designing the mobile prototype in Sketch
  • Conducting user testing
  • Conducting user interviews

1.1–The objective

The objective was to come up with a problem we wanted to solve, and then as a team, work collaboratively:

  • Choose a brand that would fit our needs for our problem
  • Decide what platform to design for (Mobile, desktop, etc.)
  • Research the technical constraints involved with our decisions
  • Build and design the product in Sketch
  • Conduct research, user test, and prototype
  • Create a project proposal and timeline
  • Present this project privately to 2 clients
We wanted to solve a problem for the social good.

As a group, we unanimously decided that we wanted to solve a problem for the social good. We brainstormed for awhile at the whiteboard, thinking of all sorts of problems, but not exactly arriving at a clearly defined problem for bit. We went from thinking about dealing with anxiety, to families traveling on a budget, all the way to traveling with a physical disability.

We decided to focus on the task of traveling with a physical disability within NYC. First, we did some quick research. We found out that only 24% of subway stations in NYC were ADA accessible, and there are currently no apps that help give you directions for ADA points in New York City.

We decided to build an app to solve this problem. We named it Traverse.

1.2–Defining the problem

People with physical disabilities are unaware of how to reach their destinations via public transportation using a mobile device. Current apps do not provide filters or options to accommodate users that require platforms, ramps, or elevators.

1.3–Choosing a brand — Why Sidewalk Labs?

We chose to work with Sidewalk labs

We chose Sidewalk labs for our brand. Sidewalk Labs recognizes that technology can help mitigate our “big urban accessibility problems.” Innovative products and services not only create a symbiotic relationship between technology and urbanism, but also better the lives of the very people living amongst its urban framework. Our approach to problem-solving coincides with Sidewalk Labs’ principle:

“Cities are about people — whenever we improve the human experience, we improve the city.”

Sidewalk Labs works to build a “data ecosystem,” the backbone behind urban change. We plan to build upon this ecosystem with our app, identifying problems and experiences that can be remedied by Traverse.

1.4–Defining “physical disability” for our purpose

We chose not to limit the scope of physical disability to permanent, but to any person who may have a temporary mobility problem — on crutches, pregnancy, brief injuries, etc. This is key because we want to target a larger audience for our app.

1.5–Understanding the tech constraints

We decided to utlitize Google’s mapping API’s for our app. We wanted to develop a mapping service that allows the physically disabled to access ADA routes and points. We also wanted to create this app to encourage the ADA community to engage in discussion within NYC, by giving advice or recommendations for routes or specific subway stations.

1.6–Third Party Services

The MTA (Metropolitan Transit Authority) provides data and real-time updates of transportation conditions on their website: a listed resource of out-of-service elevators and escalators and information for ADA accessible stops. We would integrate this data into our app.

2. Research

2.0 — Comparative Analysis

To understand the market, we produced a comparative analysis of current services and organizations that would identify areas of growth and opportunity. There are only desktop solutions available for people looking to travel in NYC with a physical disability. As stated earlier, there are currently no apps available that solve this problem. Our research confirmed this. Therefore, we have a competitive advantage by building this app.

Comparative analysis chart

2.1–Addressing the user

We administered a screener survey, with the recognition that the term, “disabled,” once again, would be extended to include temporary impairments to mobility (pregnancy, casted leg, etc.). The surveys generated our users, the individuals we wanted to learn more about. We interviewed with 6 users.

2.2–Interviewing our users

We conducted user interviews to better understand the behaviors, pains, and needs of our users. Our participants included permanently disabled users, individuals battling a sports injury, and pregnant women. The results identified issues with the MTA accessibility and their overall mobility as a disabled individual.

One user expressed a few issues within the NYC subway system that we have never even realized, such as the subway platforms being uneven for wheelchairs, and even people using the elevators as bathrooms! We definitely empathized with our users during this process.

These are a few key quotes from our interviews:

“I wanted to help other disabled people, but I was too shy to speak up.” “It was a nightmare to travel with a disability!”
“I am more sympathetic to the disabled now.”
 “It’s [checking MTA website]
an extra step to my routine that I have to add.”
“I like when the community helps eachother.” “For the most part, I just can’t take it [public transportation].”
“I’ve lived in the city all my life and had no idea which stops were ADA friendly.

2.3— Spotting trends

Affinity mapping

Our interviews produced insights and design recommendations. We then took those insights, and utlitized the method of affinity mapping. Affinity mapping is a process in which we grouped together behaviors, context, pains, and pleasures on post-it-notes. With these insights, we were able to organize it and highlight the trends that would define our personas. Personas are characters representative of our users.

Takeaways from the Affinity mapping

2.4–Creating user personas

With the trends identified from our affinity mapping, one of the UX Designers on the team created and designed the three personas. Our primary persona, Dillon May, is temporarily disabled with a torn ACL. We consider him our power user because he is most likely to use the app and all of the features we want to implement in it.

Our three personas

2.5–Feature Prioritization

We utilized the MOSCOW method to help us narrow down our features. The MOSCOW method organizes features into these 4 categories: Must, should, could, and won’t. As a team, worked together to decide where the categories would be placed.

MOSCOW chart

2.6–User flows

We wanted to look at the flow of Waze and Google in regards to getting directions in their mobile app. We looked at these apps in particular because our users said they used them the most. We discovered that both apps only had a 5-step process. So, we wanted to make sure that our app would have 5-steps or less to accomplish the task of getting directions.

User flows for Waze and Google Maps

3. The proposed solution

3.0–Initial sketching

First, we sketched out our ideas on the whiteboard. Yes — it’s messy! Some of these ideas were later shot down during user testing, but it’s a part of the process. The main features we originally wanted to test with included:

  • The ability to get directions with ADA points
  • A place to rate subway stations
  • The ability to save locations such as work or home
  • A separate section that would show ADA points
  • Pop-ups for map points that would display quick information
Rapidly sketching out our ideas

3.1–Paper prototype

I designed the first version of the app in Sketch. To get feedback on the design immediately, we decided to conduct a round of paper prototyping with 3 users. I printed out the app, and then asked the users to get directions. I asked how they felt about each screen, and their first impressions.

the paper prototype

It proved extremely useful to conduct the paper prototyping. The feedback we received allowed us to save time before we designed the rest of the app.

The main takeaways were:

  • Users didn’t understand the importance of “rating” a subway station
  • The icons we used were confusing
  • The titles we started with for our toolbar navigation were confusing (home, profile, ratings, and destination)
  • Didn’t understand the searchbar in one spot

3.2–User testing and iterations

After the paper prototyping, we went through an additional 4 rounds of iterations. With each round, we continuously refined the process. We changed the navigation names several times, too. I’ll annotate the key feedback from each round.

Iteration #2
  • A: The pop-up that displays quick current information about the stop (elevator service, reviews, etc.) wasn’t perceived well. Users didn’t understand the use of it.
  • B: Although the alerts section was perceived well and to be useful, the design needed to be improved upon. The Icons above the lines confused the users.
  • C: “Default” didn’t make sense. It’s intended use is to access saved locations, but the users did not understand that.
  • D: Reviewing a location seemed odd — no one said they would use this.
  • E: Default locations is confusing.
Iteration #3
  • A: We really wanted this pop-up to be successful in testing, so we modified it again. No luck, it still didn’t make sense to users.
  • B: Changed from “alerts” to “status.” The idea being that you would check to see the status of a selected train line. The colored line still didn’t make sense to users. Also, users didn’t understand where this information was coming from and if it was updated.
  • C: We changed this section to “reports.” Users said they were more likely to leave a review if it was not working, so we thought “reports” fit this need better.
  • D: Users said that the icons didn’t make sense because if, for example, the elevator was broken yesterday, what purpose does it serve to know it now?
  • E: Removing “default” locations, and changed it to “my places.” Users understood this change. It is consistent with this iteration of the places page.
Iteration #4
  • A: We attempted one more iteration with the pop-up. This time though, the pop-up appeared after entering in the address to get directions instead of existing on the map beforehand. We scrapped it after this iteration.
  • B: Users wanted to know where the information was coming from in the last iteration, so we added in the MTA logo and update info. Users perceived this well, but then one user said the train line looked like Christmas lights — We had to rethink this design choice.
  • C: The MTA update info was added to this page, but users said it makes no sense because it’s conflicting with reports being past information, with the update being current information.
Iteration #5
  • A: With the pop-up now removed, users went through the navigation without much hassle.
  • B: Adding in more context to the status section, it was understood much easier, but, the choice of the checkboxes confused one user.
  • C: We changed “reports” to “tips.”

3.3–Information Architecture: the appmap

The final appmap that we came up with after testing.


3.4–Final prototype in Invision

4. Next steps and closing thoughts

4.0–Client demonstration feedback

During our client demonstration of the project, we talked about the possibility of integrating our app in an already existing app like Google Maps, instead of creating a stand-alone app. It was an interesting perspective offered, and would probably be more practical and cost-effective. It was a new experience to present a project proposal privately, and I liked the real-world aspect that it brought.

4.1–Acknowledging the downfalls

We had good intentions when designing Traverse. We wanted to create an app that would give directions for ADA points, provide real-time updates for subway stations, and allow the community to leave feedback in the app. I think we had too many ideas and, honestly, even one part of Traverse could’ve been it’s own app. Going forward though, I will seek to understand the tech and budgetary constraints of a project on a much deeper level.

4.2–Closing thoughts

I really enjoyed working with my group and figuring out a creative way to solve our problem. We had an awesome team dynamic. One thing that I would like to keep an eye on going forward is time management within a team — I feel that the final product could’ve been a lot more polished if we worked a bit smarter with our time. Nonetheless, I am still happy with how everything turned out and it was a great learning experience.