Create a digital product able to identify slowdowns and problems, help riders find alternate routes, and through transparency and flexibility help increase customer satisfaction in the Chicago Transit Authority (CTA).

I. Research

Competitive analysis
The Chicago Transit Authority (CTA) is the second biggest public transportation system in the United States. In a city of 2.7 million people, 1.6 million take rides on an average weekday. We wanted to know what resources riders used when problems occurred, so we looked at the competitive landscape. The top three competitors were Transit, Waze, and Google Maps, all which offered navigation services for many forms of transportation and suggested alternate routes.


[+] Transit provides real-time predictions and route navigation for public transit and ride services.

[-] There is no filter for transit and ride options.


[+] Waze gives clear alternate routes, turn-by-turn navigation, real-time alerts on nearby drivers, and traffic updates through user info sharing.

[-] This app only exists for driving.

Google Maps

[+] Google Maps displays comprehensive map views, real-time traffic conditions, and route planning for traveling by foot, car, and public transit.

[-] There is limited accuracy and real-time info on unusual weather or construction issues.

We learned competitors had the most thorough real-time transit information. But, a tool that provided real-time navigation, information on delays, and alternate routes did not exist on one platform. Our team then sought CTA riders, stakeholders, and subject matter experts for interviews. Our objectives were to discover the goals, needs, motivations, and frustrations of CTA riders during their daily commutes specific to the problems they face, such as slowdowns, delays, and cancellations.

We spoke with ten Chicagoland natives and transplants, all whom used the CTA several times a week, and we learned the following:

1. The experience of being late is very uncomfortable and unpleasant. Traveling during peak hours creates stress.
“It can be a harrowing experience if you feel late. It can really build stress.”
— Nathan, Software developer

“I don’t like reneging on my commitments; being late sucks. It’s very annoying because it really should only take a certain amount of time.”
— Ji, Events coordinator
2. There is no clear, immediate, or detailed  communication between the CTA and riders. There isn’t a way for people to share information with each other. Often, the speakers on the trains are muffled and announcements are difficult to hear, so riders don’t know what’s happening with the train. Some users go to CTA’s twitter feed for more information, but oftentimes, by the time an alert is posted, it is too late.
“People don’t like standing somewhere not knowing where something is taking you.”
— Raymond, Project manager in CTA analytics

3. There’s a fragmentation in the use of apps. Instead of using one app for all travel needs, users will often use many tools and apps to be able to use all the features that they need.
“I use the CTA app to see when my ride will come and Google Maps to find directions.”
— Allie, Graphic designer
4. We saw two types of response to delays: wait it out or be proactive. Some people will wait and stay on the train or bus if there’s a delay; they let the problem resolve itself. Others will find alternative options to transportation.
“It depends on time. If I’m late, I’m more likely to try to get a Divvy or Lyft. Otherwise, I just deal with it because I have to get to where I’m going.”
— Ellen, Transit planner
5. Users have an effect on transit just by using it. Rider culture affects ride experiences. For example, when people don’t move to the back of the bus or train, this causes bottle-necking which makes others late.
“People won’t squeeze to the back when we can pack on more people. I wait for the bus driver, and if they don’t say anything I’ll say something, in the nicest way.”
— Helen, Actress and teacher

We distributed a survey on Facebook and the Chicago Transit Forum
to learn more about the behaviors of CTA riders. We had a total of 77 respondents. Of our respondents, 60% lived and worked in Chicago, and 89% of them had been taking the CTA for more than one year. A little over half of our respondents said they were satisfied with the CTA, which told us there was room for improvement. We also found that nearly 70% of users turned to Uber or Lyft when there were delays or cancellations.


of respondents were satisfied with the CTA


of our riders take Uber or Lyft when there are delays or cancellations

II. Understanding the problem

Through an affinity diagram, we found that train-crowding and delays were the biggest sources of frustration for our users.

We saw two types of attitudes behind the frustration. One user group consisted of people who followed rigid schedules, and their frustration stemmed from needing to be somewhere and not being able to meet work-related responsibilities. The other bucket included people with flexible schedules who used the CTA to explore. They didn’t necessarily have to be at a location at a certain time, but their frustration came from not being able to make informed decisions because they were not made aware of CTA issues.

At the root of these frustrations was the most important issue—communication. There was a need for the immediate and transparent communication of information that users were not getting with their app or tool used for transportation. The two buckets of users led naturally into our personas, which helped us better empathize with users.

the time-conscious planner

Our first persona was Derek, the busy Chicago commuter. He has a car but finds it more convenient to take the CTA. When his train runs late and he doesn’t know how long he’ll have to wait, he often uses Uber to get to work. He likes knowing all viable options before making important decisions. He wants a reliable method for getting to and from work and gets frustrated when he’s late because of service issues.

the exploring urbanist

Our second persona was Autumn who is a freelance artist. Her schedule is flexible, and in her free time, she likes to explore and seek new experiences in the city. She uses the CTA because it’s convenient and accessible. She gets frustrated when she isn’t alerted of route changes or delays.

When our team considered Derek and Autumn, we confirmed that a lack of reliable communication was the major problem. If they knew about the service issues and problems and how they might be affected, they would be able to make decisions to get to their destination on time and mitigate frustrations.

The problem
We found the CTA took a long time to update their platforms—website and Twitter—with service information. The lack of immediacy and transparency from the CTA during delays hindered riders from making informed decisions about continued transit. Users were worried they could jeopardize commitments with an employer, a friend, or with themselves. We pinpointed the problem we needed to address with our project:

The experienced Chicago transit commuter needs a way to share and access live
community-sourced information about service delays and view alternate transit options.

Users lacked a tool that provided live, trustworthy, and detailed information. Competitors provided one or two but not all three for public transportation. Waze offered all three through user-sharing features, but it was only for driving. We realized for our product to be immediate, credible, and detailed, we needed crowdsourcing so users would be able to share and have access to real-time information with a higher level of credibility.

To make sure our solutions aligned with what users vocalized, we came up with the following design principles:

Provide users with information before they have to look for it.

Due to the fragmentation in the use of apps, users expended extra energy, time, and effort to search for the information they needed from different apps. To lessen the load on the user, it was important for our design to be proactive.

Adapt to the individual rider’s travel routes.

We wanted to reduce the number of steps users took to find a route and get to their destination. This meant our design had to be personalized so that it could better provide relevant information to the individual.

Use sensitive language to help ease feelings of frustration.

Because it’s stressful being late and experience unexpected events, we wanted our app to have an understanding tone while being straightforward in providing solutions.

III. Concepts and testing

To solve for the problem, we generated many app feature ideas through structured brainwriting. Our main ideas showed us we wanted to focus on two features—report a delay and find an alternate route—which would make our app live, trustworthy, and detailed. We began to do rounds of sketching with these concepts.

We explored different approaches for implementing live notifications and finding alternate routes and tested these concepts with users. These converged feature concepts were focused and pre-determined so we could meet our main goals. 

Report a delay
My wires

My design let users report an alert in steps through text and photos, but users found this to be a lot of work. Users wanted to see only relevant alers in the travel feed. They liked the bottom navigation.
Report a delay
Teammate’s wires

Users liked having a dropdown list of reasons to choose from and the option to enter or not enter a comment. Users preferred less steps in the process.
Find an alternate route
Teammates’ wires
Users liked receiving alerts that let them know about delays. They also preferred visual graphs over text.

From testing, we learned we still needed to: 

1. Emphasize time
- Reduce the number of clicks.
- Include a live feed.

2. Prioritize information
- Condense the amount of information on each screen. Simple is better.

3. Reduce information load
- Personalize push notifications.

4. Organize actions
- Keep bottom navigation.

Report a delay iterations
1. Paper prototype

My early sketch required users to type in a reason for the delay, and go through many steps to finish reporting. Users liked being able to see delay information from other riders immediately, but they weren’t sure if enough people would take part. When we asked testers to report a delay, we saw users had to do a lot of work. This was a problem because it didn’t align with our design principle of the app being proactive.

2. Concept prototype

To avoid manually inputting each detail, I designed the app to use GPS tracking to locate the users on their transit route. This idea was validated during testing, but I realized this still required users to open the app and go through two steps to complete the process. This was a barrier; because the app was based on crowdsourcing, if the process took too much time or effort, no one would participate.
3. Final wireframe

We wanted to lessen the burden on the user and make sure the app actively helped the user. After iterations, our team came up with push notifications sent by the app when it detected a delay. Users were informed, and they didn’t have to open up their app. Users had freedom in how much they interacted with the app; they had the choice to take part in information-sharing or get rid of the notification.

IV. Final product and future recommendations

There were disconnects between official sources of information and the reality of delays because CTA riders didn’t have access to live, trustworthy, and detailed information. Our final concept was a mobile application called nxt—a navigation app that allowed users to access and share real-time information about CTA delays and offered the best alternate routes through crowdsourcing. To validate our final design, we thought about how Derek would use our product in our final prototype.

Derek was getting ready for his workday downtown. He planned to take his usual route to work riding the L-train. He wanted to get to the office early to finalize his presentation that he was giving to his boss in the morning.

1. As he was getting ready, he received a notification about a delay on his route. He clicked “Yes” to see an alternate route.

2. When presented with various options, he chose the route that would get to work the earliest.

3. He then saw a map and detailed directions to get to his destination.

Because he was alerted by nxt, he was able to make an informed decision about how to get to work on time.

If there was more time, we would have continued to explore and iterate on other areas of nxt:

1. Provide clarity in language and icons.

We wanted to further test the bottom navigation icons and text to make sure they made the most sense to users.

2. Bridge alerts and alternate routes.

We wanted to better integrate the functions reporting a delay with finding alternate routes more seamlessly to be more cohesive.
3. Explore gamification to motivate users.

We wanted to explore how to incentivize riders to keep them active on the app.

V. Learning opportunities

I loved seeing constant iterations and refinements on our design. When our team began to sketch and develop concepts, we thought we made our product increasingly proactive. However, with each user test and iteration, we constantly had to revise what proactive meant. This process showed me that the scope of our ideas can change and designs needed to constantly be redefined and refined.

Through this project, I also saw my growth as a new designer. There was a moment when I realized my mid-fidelity prototype design was bad; there were elements that did not work or make sense in my prototype that I hadn’t thought about. This realization was a good thing because it showed me I was able to discern between successful and unsuccessful design. I loved learning this, and I hope to continue to refine my design taste. See how my designs and processes improved in the Clickx and eXpoReality case studies.