
Identifying CityBus Channels and Touchpoints
Methods
Secondary Research | Observations | Usability Testing
Output
Experience Map Matrix Template | Design Sketches
The Current Riding Process
The State of the App
Locating The CityBus Touchpoints/Channels that have the Most Opportunity for Design
Methods
Contextual Inquiry | Live Guerrilla Testing | User Survey | CEO Interview
Output
Finalized Experience Map Matrix | Top 10 User Painpoints | Narrowed Area of Focus
Joining Riders for a Trip
Lack of Information on Signage
Most bus stop signs only list the bus routes and the bus numbers. Some stops didn’t even have a sign, confusing newer riders. There was also no advertising or promotion for the CityBus app, leaving unfamiliar users lost as they were unaware of when the bus would be coming.
This prompted us to look into other similar campus bus systems and design for better communication of the routes and bus times.
Cramped Shelters
Only a few stops have a shelter at all, and those that do can only fit a few people. This is especially an issue in high-traffic stops like the one pictured left at the Electrical Engineering Building.
In addition, bad weather forces most riders to have to wait outside in the rain or snow as there isn’t enough room for more than 4 - 5 people.
From this, we identified an opportunity to improve the bus stop shelters and add more information at commonly used stops.
Over-reliance on the App
While students appreciate the live tracking features on the app, we noticed that many aspects create an over-reliance on the app without any physical indicators of when buses will be arriving at a stop.
This opportunity is two-fold since there are many opportunities to either A) improve the app experience or B) reduce reliance on the app.
Troubles with LCD Displays
Users appreciated the addition of an LCD display showing the stop requests and upcoming bus stops. However, many riders also simultaneously had issues seeing the display from the back of the bus.
This provided an opportunity to design new communication methods using haptic, visual, and auditory cues for riders, making comprehension of stops and bus times clear.
Stop Request Cord
New bus riders had trouble noticing and realizing that the stop request cord was meant to be pulled to request an upcoming stop.
This led us to look into opportunities for possible signage that the bus could be improved on, whether that be digital or physical.
Bus Public Address (PA) System
Some riders experienced problems with the bus PA system being too quiet or too difficult to understand. Other riders said they liked the PA system and found it helpful to determine the correct stop.
This indicated a possible disconnect between systems on different buses.
As a result, we decided to look into ways that the PA system could be more clear and more consistent for riders, especially on crowded bus routes.

Bringing the Info Together
Figure 2 - Final Experience Map Matrix
Prioritizing What's Important
We provided participants with colored markers based on how often they ride or how familiar they are with the bus system. Participants tally-marked the top three pain points they experienced and were also invited to explain the rational regarding their choices via a short interview.
We found the biggest issues were the bus arriving late or early, how difficult the manual doors were to open, and general dissatisfaction with using the app. Users were upset about constantly having to check their phones for when the bus will arrive, the app being difficult to navigate, and the times of the app being inaccurate.
Since the answers of others were public, it is possible that later on in the process participants were subject to groupthink. To help combat this, we also sent out a user survey to gather additional answers and data regarding our prioritization.
Our user survey received 166 responses from Purdue students.
Figure 3 - Our Guerilla Testing Board Post Test
Qualitative coding was used to analyze explanations of participants' decisions that were collected during guerilla testing. This analysis suggested the following connections between painpoints.
Confusion navigating the app is a really big part of the issues people have while planning 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 they have to constantly check the app.
App Focus or Physical Bus Service Design?
Our users are not the only CityBus's only stakeholders and we recognize that we needed to talk to CityBus officials to get the full picture of why the bus operates as it does and what modifications would be feasible. To do this, we conducted a virtual interview with the CityBus CEO.
Some noteable takeaways from our conversation included:
CityBus does not manage the app, they work with a company called TripSpark.
City Bus executives have already started efforts to fix some of the physical problems we identified like ensuring that every bus stop has a sign, and the amenities it needs depending on the popularity of usage.
Physical changes and physical infrastructure cost a lot of money to create and uphold.
Out of all the changes we could suggest, changes to the app would be the easiest for CityBus to take action on.
Design Recommendations for Identified Opportunities
Methods
Wireframing | MidFi Interface | A/B Concept Testing
Output
Final Design
Optimized Communication on Home Screen
Current App Home Screen
Redesigned App Homescreen
Bus Alert Feature
New Bus Alert Feature
Route Tab Visibility
Current Route Tab
Redesigned Route Tab
Notification System and Widgets
To help people reduce time within the actual CityBus app (untested hypothesis), we designed notifications and widgets that users can leverage to obtain bus route information. Currently the CityBus app does not have notifications or widgets within the app.
Notifications
Widgets

Figure 5 - Notification Button within the CityBus App.
Redesigned Plan a Trip Feature
Current "Plan a Trip" Feature
Redesigned "Plan a Trip" Feature
Step 1: Enter Trip Details
Step 2: Route Selection
Step 2: After the user enters their desired details, they will be able to view a selection of trips most suited for them. The user can also view a map of the route they will be taking on the trip.
Step 3: Navigate to Bus Stop
Step 3: The user begins a step by step journey to walk them through their bus trip. The first step on the journey is to assist the user in locating the bus stop.
Step 4: Enter Trip Details
Step 4: The next step of the journey is when the bus picks up the user. As the user is on the bus, they can easily see how many stops they have until their destination. This is to reduce user anxiety and give the user more awareness.
Step 5: Nearing Destination
Step 5: As the user approaches their destination they will be prompted with a message signaling the user to pull on the stop cord to alert the driver of their desired stop.
Step 6: Arrived at Destination
Step 6: As the user arrives at their desired destination and complete the trip.
The Hypothesized Value
Limitations
The main limitations of this project were subjected to time and resource constraints. While our constructed solution is based on our insights and data collected from previous research, we identified that three main limitations should be considered while using the outcome of this project to carry on further work in the future:
Small Sample Size and Bias
While we tried our best to collect data that are adequate in number (for quantitative studies) and varied in demographics (for qualitative studies) to serve a better understanding of the whole picture, we recognized that there a small sample that we’re able to collect from might be subjected to multiple types of bias. That being said, we believe that the insights that we synthesized through research and the designs we recommended are supported by our research and carefully considered.
Lack of Adequate Real Context-Embedded Testing
Within the time and resource constraints, we did a lot of in-lab usability testing and concept testing, which provided us with a lot of useful feedback to improve on our final solution. However, we did not manage to get to do fleshed-out testing that incorporates real-life context, such as having a functional prototype for the app and having users use the newly designed app actually to go on a bus trip. The in-lab testing and concept testing we did mostly served to determine whether our users see our designs as more helpful than the old app.
Lack of Technical Feasibility Evaluation
Through the interview with the CEO and upon examining similar apps made by TripSpark, we are aware that some technical constraints might made our designs harder to implement. While we included a more realistic revision for the app and did consider technical constraints while coming up with the solution, none of these suggestions have fully gone through any technical consultancy to make sure that it is feasible to carry out on the current app.
Next Steps
My Reflection