Bound Transit App

Bound is a look at the way we commute in NYC. Bound tries to imagine an app that would focus on the user's most travelled to and from locations.

I researched, designed, tested, & validated this in its entirety myself.

Springboard UX Intensive
Based In
New York, NY
Scroll Down

Table of contents

The Challenge

The MTA is one of the largest transit systems on Earth. It’s also one of the oldest. This equation results in a growing set of inefficiencies that adversely impact the user experience for the average passenger. The solution, typically, has been to rely on an ever growing list of apps to gather any information that can help make the experience more tolerable.

The solution

Bound is an attempt at bridging the information gap while creating a more personal relationship between the rider and the system. It aims to provide common sense tools to alleviate the frustration that can come from dealing with delays, train reroutes, or flat out cancellations.

Survey Research

Research is a vital component of the UX process. I wouldn’t have been able to distill the kind of information I was after or validate my concept without extensive surveying and interviews. To this end, I created a 5 minute survey via Google Forms and received 35 responses over a week.

I think the real success of basic user research is dependent on the kinds of questions asked. If, for instance, the survey is stacked with binary questions; the result is going to be lackluster in depth of research and quality of responses. So, the questions have to be empathetic. They have to frame the problem very clearly and elicit an investment from your survey respondent.

Short answer example

What would you change about how delays are addressed by the MTA?

    Options based example

    How satisfied are you with the MTA system on a scale of 1-10?

      The questions above helped me frame the issue around the numbers below. I found that asking more short answer questions increased the level of unpredictability in types of responses I received. However, the usefulness of taking this qualitative information and creating quantitative data allowed me to measure the emotional basis that survey respondents were coming from and allowed me to empathize with some specific pain points & opportunities for a solution.


      use the MTA system daily


      use more than one transit app


      find out about delays at the station or not at all


      list unreliability as their main concern

      Contextual Inquiry


      Concise Information

      Pain points

      No information
      No details

      I conducted qualitative in-person interviews of 4 people so I could reveal  subtle behavioral reactions to questions and pronounced physical responses to emotional stimuli. The interviews helped me understand users in context so that I could isolate what I needed to focus on.

      Heuristic Analysis

      I was able to settle on 5 apps to conduct an analysis on after collecting survey & interview data. I took the top 5 most mentioned apps in both research contexts and conducted a NNG based usability analysis across 3 factors that I thought captured both the concerns of the research participants and a way to validate the need for a solution.

      NNG usability Heuristics
      Recognition rather than recall
      Flexibility & efficiency of use
      Aesthetic & minimalist design
      MTA Subway Time
      MTA Bus Time
      Google Maps
      City mapper
      Subway: NYC

      User Personas

      Information Architecture

      At this point in the process the design was barely developed. I had a ton of data but I still hadn't implemented any solutions. I found that setting up the core architecture of the app would be really beneficial to focusing the design instead of going down blind alleys. So, I set about the four step process outlined below.

      I created the Bound sitemap based on the results gathered in the card sort. I wanted to create an intuitive and simple layout that met all user expectations and needs.

      The original site map contained a set of 4 menus and had extensive steps. I felt that this would hamper the ease of use in the app, so I wanted to find a way to incorporate some screens and make them more visible and easily accessible.

      After working through iterations of the app, I found that I could simplify the user flows. I realized that the app should be intuitive no matter the situation. I wanted to reduce the overall number of screens and menus required. So, the updated user flows show a process that I feel meets the user needs more than the initial iterations. Below is an exported image of user flows constructed in

      Visual Design & Testing

      This was definitely the most labor intensive part of the process. I learned a lot about visual design tools and how difficult it can be to coordinate in-person testing. However, this was also the most rewarding part of the process. I felt that I was really able to address the issues, that I've been digging up and analyzing, in a comprehensive design solution.

      The sketches below show the different user flows I began with. I wanted to see how each flow would look visually, and see if there was any deficiency in the process. Sketching them out allowed me to create the bones of what my design would eventually look like. The wireframes are lo-fi representations of my sketches made in sketch. I was able to get a better idea of my design aesthetic, and user flow with this whole process.

      I created hi fidelity screens in Sketch from my lo-fi wireframes. I wanted to create an overall design aesthetic and have UI elements carry through the app. I then exported these screens to to create a prototype that has transitions and showcases the fluidity of the app.
      The embed to the right shows the screens + flow of the here to see the interactive prototype

      I tested 4 users in the 25-30 age range. I conducted the tests in person. Each test took about 30-45 minutes. The results shown to the right touch upon the patterns that emerged across the majority of testers. Overall the focus was on clarity across the board.


      100% want static maps
      75% want better UI hierarchy
      100% want clear time indicators
      100% want walking times included in total time
      75% want indications for swipe-able UI elements

      Iterative changes

      Clarifying UI element hierarchy
      Clarifying route guidance
      Clear indication of ETAs
      Adding walking distance estimates
      Adjusting hierarchy of text

      Final Design & Thoughts

      The "final" design of Bound hasn't really stayed final. I spent 3 months re-designing the screens after I had finished up the project. I think that speaks to how much can change in such little time. I eventually ported this design from Sketch to Framer X to use it as a vehicle to get a better handle on React. I've used this project to further my design skills and to further the challenge of designing to the parameters set up by the research.


      Healthcare platform design

      UI/UX platform design case study