back to work

Brief

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).

[+] 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 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.

— 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

Survey 
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.

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.

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.

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:

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:

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. 

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

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.

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.

Scenario
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:

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

We wanted to better integrate the functions reporting a delay with finding alternate routes more seamlessly to be more cohesive.

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.