Transit Authorities Online 

Before kicking off this project I made it a point to familiarize myself with industry standard transit rider tools and metropolitan transit agency websites. I also started using the transit services in my own city to step into the shoes of my end users.

Understanding Existing Rider Behaviors

I began my research by analyzing the existing Google Analytics of the current website. I focused primarily on device usage and browse paths. Event tracking wasn't enabled, so my plan was to investigate interaction-level data in an online survey. I surveyed 660 Users Total - leveraging the client's subscription email lists and outreach teams to recruit new and current transit riders to take the survey.

Diving Deeper with Qualitative Interviews

I conducted follow-up interviews with the same set of users. I interviewed 40 users total over the phone. In these interviews I wanted to unpack the full context and stories behind their actions. I found common trends in the narratives, both positive and negative. I also took this opportunity to get a sense of feature prioritization (see second screenshot). This portion of my researched informed my user personas and user journeys I would develop next.

Key Takeaways

After speaking with dozens of riders, I noticed patterns in their feedback and potential ways in which we could increase rider confidence before, during, and after their trip:

Rider Profiles and Journeys

I classified users based on whether they were a new or current rider, ride frequency, transit-related characteristics, rider goals, motivations, frustrations, and most importantly their ideal browse path.  Next, I developed user journeys for each persona profile to uncover potential website improvements that will not only move users down the ridership funnel but also turn visitors into regular site users.

Site Structure + Content Hierarchy

Creating a trip planning oriented site structure aligned to the primary personas - the New Rider and Exploring Rider.

Integrating with Transit Data

The General Transit Feed Specification (GTFS) is the common format for public transportation schedules and associated geographic information.

Redesigning bus schedules from the ground up required working closely with transit developers and transit planners to understand the variations of schedule states that could occur depending on what route a user selects and what time they select it. 

Schedule States we took into consideration:

• Skipped Trips - some schedules contain trips that skip certain stops at certain times; the schedule design needed to display these changes
• Combo Routes - some routes have a regular route and an express route with the same schedule; the schedule design must clearly reflect which trip is express vs regular
• AM/PM Split - some schedules have different stop times for AM and PM times
• Effective Date of Schedule - data pulls in the particular schedule associated with a certain date; give users ability to toggle between current and future schedules

Execution

After rounds of ideation, I created an interactive wireframe prototype of key sections of the site (Home, Trip Planner, Scheduler) to spark collaborative discussions around design and functionality with my extended design team and with the client. These would later be mocked up into more high fidelity designs so we could validate with real GoTriangle riders. 

We held usability sessions at the GoTriangle headquarters in North Carolina where we had the chance to meet users that we had been in contact with for so long. We used Invision prototypes for both Desktop and Mobile to simulate the real site experience. We also gave users the option to test both sites on their personal devices and think aloud as they completed a set of tasks. As a result, we ended up with very useful feedback that we applied to the remaining design tweaks. 

One of the challenges working with a global design and development team and having clients in different states, was keeping everyone on track. In addition to Trello, Slack, and email, I made sure there was documentation to track the backlog of tasks and updates to the designs. An example of this deliverable below would be used between myself, the UI designers, both Front-end and Back-end Developers, and even our client.