The goal of this project was to investigate the CityBus service, a public transportation service catering to the towns of Lafayette and West Lafayette, including Purdue University. We wanted to discover how ridership as a whole could be increased, and how riders’ experiences could be improved.
Role: UX researcher, Project lead
Timeline: Jan-May 2024
Class: Experience Studio 3
In experience studios students work on one semester long project with a corporate sponsor in teams of UX students from every year of the program. Students in experience studio 3 tend to be Sophomores.
The goal of this project was to investigate the CityBus service, a public transportation service catering to the towns of Lafayette and West Lafayette, including Purdue University. We wanted to discover how ridership as a whole could be increased, and how riders’ experiences could be improved.
After Preliminary research, it was clear that we had two possible design spaces to work in.
- Designing for physical experiences
- Designing for the App
We conducted Guerrilla testing, a User Survey, and held a discussion with the CEO of Citybus to discover which of these spaces would be the most beneficial and feasible to design for.
Users found the Citybus app confusing and hard to navigate
Users found it hard to reliably plan their bus trips
Users felt tied to their phones throughout their journey, especially new users
These findings led us to focus on the app as it would have the biggest impact on user needs and would be the easiest to act on.
We created two new versions of the Citybus app. One version was an entire app overhaul while the other implemented more feasible changes to the existing experience by doing a redesign. Both designs implemented features like notifications or widgets to address the issue that users felt tied to their phones and to combat the reality that busses run early and late which causes users to miss their busses frequently.
This prototype was created to address many issues we found throughout our research such as issues locating the correct route on the app, and awareness of which stop a user is at. Entirely redesigning the app allowed us to design a more visually appealing service that fits with other travel app conventions
This design also included an IOS widget that would provide the user a visual of how close the bus was to a pickup or drop off stop without the user having to open the app.
This prototype was created to address the most pressing issues we found in our research. Feature understandability and a reduced reliance on looking at the app was our focus for this design.
Instead of the widget used in the overhaul to alert the user of where a bus was in relation to pickup or drop off, this design uses the much more easily implemented technology of notification banners.
I took a leadership role in this project, coordinating our large team of 9 through our many activities. I took an active role bringing our team together, and promoting clarity and unity of project goals. With so many people on the team, it was essential that we were all on the same page about the project’s status and had common goals to drive our project forward.
This project was also a great opportunity for me to learn more about creating hi-fidelity mockups in figma. I contributed to the app overhaul and got the chance to create assets from scratch as well as creating interactions in figma for our final Wizard of Oz testing.
I appreciate all the new research methods I got to try out in this project like guerrilla testing, Wizard of Oz User Testing, and Using an iterated journey map throughout the project. Continuing to learn and practice new skills prepares me for future projects and situations and equips me to be a better designer.
To guide our project, my team created 3 goals with guiding questions that would help us create a successful end product. These goals would be used to split up our activities and achievements to keep our project on the right path.
1. Identify Citybus Channels and Touch points
a. How is the CityBus service currently used?
b. What channels and touch points are users interacting with?
2. Locate the CityBus Touchpoint/Channel that has the Most Opportunity for Design
a. What touchpoint(s) and/or channel(s) need the most improvement in the system experience?
b. What opportunities can we feasibly design for within the identified limitations of the CityBus service?
3. Design for Identified Opportunities
a. How can we reduce user frustration, confusion, and reliance on the MyCityBus app to use the service?
b. How can we design realistic, practical changes to improve the MyCityBus app?
To gain preliminary knowledge of how the bus service works, our team split into 3 groups to ride different kind of bus lines. We rode one campus loop, one off campus route, and a route that ended at the Citybus center.
Through this activity we were able to identify 7 steps in the bus riding process that would be used as the basis of our journey maps for the rest of the project.
1. Planning
2. Arrive at Bus Stop
3. Boarding the Bus
4. Riding the Bus
5. Prepare to Exit
6. Exit
7. Post-Ride
To discover what users like and dislike about the citybus app, we looked through online reviews, posts, and comments, and collected user opinions which were affinity diagrammed into the following insights.
Positive reviews praise the live bus tracking features, automatic display or previously selected bus routes, and LED signs detailing bus times at select stops.
Pain Points include app glitches, inaccurate bus times, and safety concerns due to bus service stopping earlier than many classes and activities.
Well-designed passenger information systems provide additional resources through the mobile application as well as physical maps of their services.
To learn more about the pain points of the app that may not have been mentioned in online reviews, we conducted user testing with Purdue students.
Inconsistent information throughout the app
Multiple sources of time information on different screens
Overcrowded Information
the amount of information displayed is overwhelming and confusing for users to find relevant information
Lack of backtracking
Participants needed to return to the hamburger menu whenever they wanted to use another feature
To analyze the information we collected in our first milestone, we created a journey map.
We organized our findings by tasks, channels/touch points, highlights, goals, pain points, and opportunities for all the steps identified in our observations.
Each team member accompanied a Purdue student on a bus ride on one of the CityBus routes, prompting them to think aloud through the experience. We also asked additional questions to further understand students’ mental models of the bus system and what workarounds they were using when faced with an issue.
We identified a few essential pain points:
1. Lack of information on signage
2. Cramped Shelters
3. Over-Reliance on the app
4. Troubles with LCD displays
5. Un-noticeability of Stop Request Cord
6. Low volume and inconsistent presence of PA system
Our previous activities gave us lots of pain points to look into, but we didn't know how severe or important each pain point was so we conducted some prioritization activities, including Guerrilla testing , a User Survey, and an interview about feasibility with the Citybus CEO.
Guerrilla testing is a quick and informal method of gathering user feedback on a product or design by approaching people in public spaces. For our guerrilla testing we narrowed down our known pain points through affinity grouping and a pilot study to rule out those least important to Purdue students. This left us with 12 pain points distributed across journey stages that we had users vote on.
We stood outside of a busy building on campus and had students put tally marks on the three pain points they felt most affected by.
Tallies were color coded by rider experience, and participants were asked to give a short verbal explanation of their selections which was recorded.
Our survey asked many of the same questions the guerrilla testing did, and it was conducted as a way to reach more people and gather information quantitatively.
To put together the data we collected, we quantitatively analyzed the tally marks and survey responses, and qualitatively coded the verbal responses.
Quantitative Data
- frequent users had the most agreement on pain points, indicating that app navigation and manual bus doors were their biggest pain points.
- app navigation, need to constantly check app, manual doors, and the bus running early or late were the most popular answers.
Qualitative Data
- Confusion navigating the app is a big cause of the issues people have while trying to plan a trip
- People get frustrated when their plans don't work because of inaccurate times
- Bus times being inaccurate makes planning harder and less effective, leading to frustration and people choosing to walk instead
- App times are inaccurate because busses run late, as a result, riders feel that they have to constantly check the app
With all of our research on user needs, it was time to investigate stakeholder needs. Talking to the CEO of Citybus would allow us to learn which pain points could be easily addressed, and which initiatives Citybus would be most likely to put into action.
Key Insight:
The Citybus app would be the easiest change to take action on as it is run by another company so change requests could be easily submitted.
We learned from our CEO interview that the app would be the most actionable change we could propose so we knew going forward we wouldn't be looking at any physical modifications to the existing journey.
As for the pain points we would be addressing, reducing users’ over-reliance on the MyCityBus app, poor time communication, bad in-app navigation, bus time inaccuracies were the key problems we identified in our guerrilla testing and user survey so we would be designing for them going forward.
As my team was starting to sketch for these opportunities, we couldn't come to a decision whether we should do a more limited re-design that would be more likely to be used but wouldn't address every concern, or a complete overhaul that would be much less likely to be accepted but would address all of our concerns.
Due to the size of the team, we decided to split up and create high fidelity mockups of both versions.
This project is defined in my body of work by my team’s ability to with many voices, a trait that allowed us to engage in discussion and compromise. Our final deliverables are one of the parts of this project most indicative of this team dynamic. Our team was divided between creating a full overhaul of the current app to satisfy all user needs, and focusing on a more realistically implemented redesign that could only satisfy our biggest user need while ignoring others.
We aren’t always able to design for the best of both worlds, but because of the size of my team and our individual commitments to putting in the extra effort, we were able to address all facets of the needs of this project.