USABILITY TESTING UUM BUS TRACKING APP
Introduction
For our human-computer interaction project, our group designed the UUM Bus Tracking App. If you study at Universiti Utara Malaysia, you probably know the daily struggle of standing at the bus stop in the heat, having absolutely no idea when the shuttle is arriving, and then watching it drive past you because it is already completely full. We built a clickable Figma prototype to try and solve this problem by giving students a centralized place to see live tracking, route schedules, and crowd levels. But an interface design is only successful if exhausted students can actually use it without getting frustrated. That is exactly why we ran usability testing. Usability testing is basically just putting the app in front of real people and watching them try to navigate it without us helping them. We primarily wanted to measure task success, which simply means whether they could finish what we asked them to do without giving up, and time on task, which is how many seconds they spent looking around the screen before figuring out the right buttons to press.
Methods and Procedures
We tested our prototype with three different students to get a realistic, unbiased look at our design. Participant 1 was Imran, a semester 6 student from the School of Education. He is a senior, so he knows the campus bus routes very well. Participant 2 was Yusuf, an IT student, so he is pretty tech-savvy and familiar with app navigation. Participant 3 was Aisyah, a second-year multimedia student who told us she mostly stays around her residential hall and sometimes gets confused by the campus layout.
We met with the participants face-to-face in the campus library discussion rooms. We loaded the Figma prototype on a laptop simulating a mobile screen and used a screen recording tool to capture their clicks, while also recording their voices on a phone. Before starting, I read them a briefing script explaining the scenario. I made sure to emphasize that we were testing the app, not them, because people tend to get nervous and apologize if they click the wrong thing. We asked them to use the think-aloud method. This meant they had to constantly talk about what they were looking at, what they expected to happen, and where they were confused. We gave them four main tasks based on everyday student scenarios: find out if a bus is full from the home screen, check the map path for Route A, find the exact stops on the trip details page, and use the follow route feature to start a live trip.
Results
Watching people use the app was really eye-opening because users rarely look exactly where you expect them to. Here is a summary of the raw data we tracked during the sessions.
Task 1: Find nearest bus and crowd level Imran: 30 seconds, success Yusuf: 20 seconds, success Illeya: 25 seconds, success
Task 2: Check route map for Bus A Imran: 25 seconds, success Yusuf: 30 seconds, success Illeya: 35 seconds, success
Task 3: Open trip details for stops Imran: 28 seconds, success Yusuf: 40 seconds, success Illeya: 55 seconds, partial success
Task 4: Follow the route and check driver info Imran: 14 seconds, success Yusuf: 35 seconds, success Illeya: 45 seconds, success
Almost everyone breezed through the first task. The home screen layout was clear enough that Yusuf immediately noticed Bus A was two minutes away and explicitly noted that the tag said crowded. Imran was incredibly fast and literally read off the statuses for buses A, B, and D in under thirty seconds. It showed us that our color-coded crowd density tags were working exactly as intended.
Task two was also pretty smooth. They all figured out they needed to go to the Ride and Schedule tab. Yusuf actually narrated his thought process out loud really well, saying he was choosing Bus A and could clearly see the map showing the way from Bank Islam to Maybank.
Task three is where we started seeing some friction. Imran clicked the trip details button right away and read out the departure time and driver name, Muhammad Iskandar. Yusuf took a bit longer but eventually found the two stop points at PKU and Dewan MAS. However, Illeya struggled a bit. She wanted to see the stops, so her first instinct was to try and tap directly on the visual map lines instead of looking down at the bottom interface where the details button actually was. She spent about fifteen seconds tapping the screen before realizing she needed to pull up the details card.
For task four, finding the follow this route button, Imran spotted it at the top almost instantly and clicked it in 14 seconds. He even went into the notifications on his own and canceled the trip, though he mentioned he had to press the right button to make it disappear, which he felt was a bit hidden. Yusuf was really happy with the follow feature, noting that it showed the kilometers and time left just like Google Maps, which was exactly the familiar vibe we were aiming for. Illeya eventually found the follow button, but she completely missed the driver safety profile because she did not scroll down the page.
Improvements and Actions Taken
Based on what we saw during testing, we definitely had to make a few tweaks before calling this prototype finished. Here are the main changes we implemented based on the feedback.
First issue: The trip details button was not obvious enough. BEFORE: The button to expand the stop timeline was sitting completely flat at the bottom of the map view. Users like Illeya ignored it and tried clicking the map graphics itself. AFTER: We added a subtle drop shadow and a pull-up chevron icon to the details tab. This makes it look like a physical drawer that needs to be dragged or tapped, drawing the user's eye away from the static map graphic and indicating that it is interactive.
Second issue: Canceling a tracked route was a guessing game. BEFORE: To cancel a live trip from the notification page, the user had to intuitively know to swipe right or press a small unlabeled icon. Imran figured it out, but it required some trial and error. AFTER: We added a small text prompt below the active notification that literally says swipe to cancel. It takes away the guesswork completely and makes the app much more idiot-proof for users who might be rushing.
Third issue: Driver profiles were getting ignored. BEFORE: The driver rating, age, and name were placed at the very bottom of the trip details page, requiring a scroll that some users just did not do. AFTER: We moved the driver profile card up so it sits right under the departure time. Since student safety and comfort is a big selling point of our app, we wanted to make sure they see who is driving them without needing to hunt for the information.
Conclusion
Running this usability test taught us a lot about how differently people interact with mobile interfaces. When you design an app yourself, everything feels completely obvious to you because you spent hours building it. But seeing a user try to tap on a non-interactive map line really proved that users rely heavily on visual cues like shadows and arrows to know what they can actually click. I feel much more confident in our final design now because our core feature, checking bus times and crowd levels, had a 100 percent success rate and took everyone less than half a minute to figure out. The think-aloud method felt a bit awkward in the first few minutes, but it gave us the specific, honest feedback we needed to fix our layout. If we were to continue this project next semester, the next logical step would definitely be taking the prototype outside to an actual campus bus stop to test it in bright sunlight, just to make sure our blue and yellow color scheme is still readable when there is screen glare.\
Figma Link
Comments
Post a Comment