Over the course of four weeks my team was challenged with creating a product that increased transparency for the CTA. Designation tasked to create a tool that identified slowdowns and increased customer satisfaction. Read on to see how we created an app with customized notifications, a widget and live reporting on train congestion levels.
CTA commuters face numerous issues when using the public transit system. Riders often encounter delays, interruptions, and closures due to lack of transparency and sharing of this information. Designation challenged us to improve riders' experience with a digital product that addressed these issues. Specifically, we were tasked with creating a product that achieved the following goals:
The project also required leveraging the Google Maps API to provide data on current traffic conditions. My team used this information to outline a research plan.
My teammates and I were new to Chicago which helped us to approach the project unbiased. Using the information provided in the brief, we outlined four main goals of our research.
We planned to reach these goals through domain research, interviews and competitive analysis.
I started researching ridership statistics reported on the CTA website. I found that as of March 2017, over 1.5 million people used the rail and bus system daily, which represented a 4.6 percent decrease in ridership compared to March of 2016. This is representative of a larger year-over-year trend of decreased use of the public transit system.
According to the CTA’s 2016 Annual Report, this is due to historically low gas prices, heavy downtown road construction causing delays, and competition from ride share services such as Uber and Lyft.
With a better understanding of what causes delays and how many people use the CTA, my team and I collaborated on an interview script for commuters and stakeholders.
We began by interviewing commuters to understand how they navigate the CTA. We initially interviewed four commuters in their twenties and quickly realized our interview pool was too narrow. We began using guerilla interview tactics to find a broader range of interviewees. By approaching individuals at CTA stops we interviewed three more commuters ranging in age from 44-56.
We also interviewed two stakeholders to gain insights into CTA's infrastructure. We interviewed the Communications Manager for the Regional Transportation Authority (RTA) and a train service representative. The RTA is the governmental body that oversees the CTA.
After we diagrammed the information collected from our commuter and stakeholder interviews, we identified key insights into how commuters behave when there is an interruption on their commute.
Commuters don’t check ahead for delays. It is not a part of their daily routine to look up CTA information. Instead, they risk delays and do their best to predict busy times based off their experience with the CTA.
“I don’t check before I leave for work to see if there’s going to be a delay. I just get on the train and hope for the best.”
“Trains get pretty crowded. They’re definitely faster but it’s uncomfortable. It’s just from experience that I know around this time the train will be crowded.”
Commuters want information about delays on their route. They feel the CTA changes things without any warning, which leaves them unable to find alternative routes.
“When a line is shut down because of a mechanical issue or whatever reason, it’d be nice to be notified of that before instead of you waiting on the platform to hear what happened.”
Commuters behave differently when they are delayed. We discovered two main ways they respond: waiting it out or quickly finding an alternative.
“If there is a delay, I’ll just wait it out at the train station. I don’t really mind and there’s rarely a delay long enough that I’m forced to find another way.”
“If I wait 10 to 15 minutes for a train then I assume it's not coming and get on my phone to find the best plan B. Plan B is usually Uber."
Commuters rely on Google Maps to find out about delays. We had one interviewee say she used Twitter to find out about delays sometimes. From our stakeholder interview we learned that the RTA expects riders to learn about delays via Twitter.
“The best way for riders to find out about delays is to follow the CTA or RTA on Twitter...I think riders are satisfied with receiving updates via Twitter.”
Tim Nazanin, Communications Manager for the RTA
Since only one of our interviewees used Twitter for delay information there seemed to be a disconnect. Most riders didn’t know where to find information about specific delays on their route. They only knew there was a delay if they waited longer than 10 minutes for a train or bus.
In between interviewing riders and stakeholders we looked at competitors. We grouped competitors according to two types: competitors that provide route information and sources for learning about delays.
From this analysis we learned that nearly every major competitor provides information on current delays and interruptions but there was no service providing this information proactively, only reactively. Users had to go into the app to find the information.
From analyzing these competitors, we learned the problem with sources for delay information like Twitter was the lack of personalized information. Commuters have to sift through information to find what is relevant to them.
To better define our users, we created two personas and specified their goals and frustrations. We found two main types differentiated by how they respond to delays.
Zach became our primary persona because delays largely impact his commute behavior. If something gets in his way he looks for multiple solutions and weighs the pros and cons of each before selecting the most efficient solution.
To get a promotion at work within the next year
To avoid being late for work
To open and own his own restaurant some day
Being late for meetings or other appointments because of train delays
The rising cost of living in Chicago
Feeling too tired after a long workday to pursue other interests outside of work
Anne became our secondary persona because she was less likely to adapt new technologies and was less bothered by delays. Anne has lived and commuted in the city for a long time. If there is any interruption in service she doesn't get annoyed and will simply wait it out.
A quick commute home so she can spend time with her family
Spending quality time with her children
To take her family on vacation before the end of the year
Having to adapt to new technologies
Being expected to work on evenings and weekends
Increases in property taxes
Now that we understood our users, we needed to narrow in on where our app could add the most value for them. To do so, we illustrated the journey of their commute. It immediately became obvious our app would have to be proactive in informing commuters about delays relevant to their commute.
Based on the insights we had from our research, personas and customer journey map, we identified the main problem commuters face with the CTA.
Rather than check ahead, CTA commuters rely on personal experience and risk encountering a delay. As a result, they learn of interruptions after it is too late to alter their route. Commuters need an effortless way to learn about relevant delays as early as possible so they can find alternative solutions before those delays impede their daily goals.
To guide our design decisions, we created three principles to help us say no to any features or design elements that did not address the problem.
The design should fit seamlessly into the commuter's routine. They should not have to go looking for the information. Instead, it should be available when they need it.
The design should use relevant data to assist the commuter in navigating their route by giving them information about interruptions as early as possible.
The design should draw attention itself so commuters realize there is an alteration to their daily routine.
As we ideated and tested, these design principles helped us drop features that fell outside of these guidelines.
We began to outline various scenarios and how the app could address the main problem. We considered scheduled and unscheduled delays. We also thought about scenarios when the commuter wouldn't be able to adjust their schedule versus when they had more flexibility. After defining the potential scenarios, we brainstormed features through 6-8-5 sketching.
We initially built out paper prototypes for 3 concepts and tested with 7 users. I focused on a widget concept, Andy focused on a customized notification concept and Grace worked on a crowdsourcing concept. Below is a definition of each concept with initial feedback we heard from testing paper prototypes.
A widget-based app that shows users the status of their commute and favorite lines on their home screen so they can see if there is an interruption on their route without having to enter the app.
“I'm not an Android user anymore but if I were, I would definitely have the widget on my homepage. ”
A mobile service that lets riders receive relevant push notifications about delays/interruptions and provides actionable options to alter their route, change their departure time, or adjust their schedule, if necessary.
“I really like that I can set when I am going to be notified. I get too many notifications from a lot of apps but I would like to be in control of when I get them.”
A mobile app that provides the latest delay updates and transit statuses based on real-time, community shared information.
“The live information is really great for anyone; especially in the instance of a Cubs game, it’s nice to know how busy the train is.”
After testing with paper prototypes, feedback showed that users saw value in each concept. We noticed an interesting difference between Android and iOS users. Android users liked the widget concept while iOS preferred notifications. All users felt the crowdsourcing concept would be a great way to get real-time status updates of train and bus congestion levels. We wanted to further refine and test these concepts by building out mid-fidelity prototypes.
After further testing with 5 users we had insights into what worked and what needed fixed from each concept.
Since there wasn’t one clear path, we converged pieces from each concept that users liked but iterated based on the insights we gained from testing. We built this out in Android instead of iOS because we felt all three concepts worked best for Android users. We named our final product CTA Commuter, which included three main components.
Users input information about their home and work locations to pick a preferred route to receive notifications about. They also set the days and times they wanted to receive notifications.
We included both the notifications and widget concept in the final design to appeal to iPhone and Android users. The widget was most useful to the Android users while iPhone users preferred notifications.
The notifications and widget prompted the user to enter the app where they could explore alternative routes through the CTA, Uber, or Lyft. This is also where users could report on and view congestion levels.
We did one more round of usability testing to further improve the product. This allowed us to further iterate on any issues that occurred when converging our three concepts. Below are the main takeaways we had from this testing.
If the CTA were to develop this project, there are a few recommendations I would make as next steps:
By implementing these future recommendations, the CTA would better understand how to improve the commuting experience and increase ridership.
This was the first UX project I worked on with Designation. While this project was a lot of fun, it was not without challenges. These became unique learning opportunities that helped to shape my design skills.