Let’s say you’re going to a bus stop, you see a bus approaching. If you start sprinting you could definitely make it. But is it the one you need? Is the sprinting worth it? That’s where BusyBus, the mobile application, begins.
MY ROLE
TOOLS USED
UX Strategy, User Research, UI Design
Figma, Google Forms, HTML, CSS
PROBLEM
SOLUTION
Due to expansion, numerous bus routes have been added and many of those routes stop at the same bus stop. Riders want to know what the next arriving bus is and how much time they have to get to the bus stop. Riders are currently complaining the most about the bus stop at Washington and State in Chicago, because that stop has seven bus lines serving it.
My solution is a mobile application called BusyBus. More specifically, it’s a schedule screen that makes it clear when and what bus is arriving next.
___
USER RESEARCH
I began my user research with a survey. I sent the survey to people that I know, but I made sure that the people were a variety of ages and genders. Those people made up most of the responses, but I also posted it on social media and in a slack channel with my fellow students. The very first question on the survey was if people had ever used a public bus system. Almost every single survey participant had. I think this is helpful to know because it gives more weight to these participants’ answers.
From my survey I learned that public transport users that currently use apps or websites really were missing ways to customize their app or website to their habits. You can see that in this chart, the inability to customize the app or website was overwhelmingly the most disliked part of the experience.
This chart shows the other side of things. Once again overwhelmingly people like the apps and websites they’ve used because they could use it to easily plan their route and easily figure out when their bus will arrive.
COMPETITIVE ANALYSIS
So from my survey, I had a pretty good idea of people’s bus riding behavior, wants, and needs. Next I did a competitive analysis of two existing apps in the space, Transit Stop and Citymapper. Transit Stop is your bare bones app that works but isn’t very fancy. Users like it, but it isn’t the most aesthetic or intuitive experience. On the other hand Citymapper is a really strong app in almost all areas. It’s a very solid award winning design. I really liked how they show frequency by letting you know the time the next three buses are coming instead of saying they come every 15 minutes.
User stories
My focus for this project was on user stories for new users, since this is a new app. I came up with four main stories. I know from the problem itself users need to know what bus will be at the stop, and when it will be there. From the survey I also know that users want to easily find when a bus will be at a stop, and additionally the survey told me that they want to be able to plan a route and customize the app to their behavior.
___
___
Wireframes
I stated with a paper prototype that covered all four user stories. Users can plan a route on the first screen below. They can save a stop on the middle screen using the save stop button. They can use the map on the middle screen and the schedule on the right screen to see which bus will be at a stop. And finally, the schedule on the right screen lets users see when a bus will be at a stop.
USABILITY TESTING
I did a task based test that was made up of 1 task with 3 different people with my paper prototype. They were asked to figure out when a particular bus would be at a given stop. All 3 completed the task without much trouble so no major design flaws. The main takeaway was that the first screen confused almost everyone. It was not clear to them that you could start with a starting point and destination OR a specific bus stop. I made a note of this for my final prototype.
___
Interations
Specifically I focused on the most complicated screen, the schedule. V. 1 looks fairly similar to what I had in my paper prototype. For V. 2, I got feedback that a map would improve the experience for visual users so I added one. I added the route destinations to make the bus lines more identifiable for users. However, I made sure the information on the schedule that pertains to those user stories dealing with which bus and when it will be at the stop was emphasized the most. That’s why they are a larger font.
Just like in any project you might get thrown some more information after the design process has been started. I was given some more information about the BusyBus route data that led to Version 3. One of the main things was the direction toggle. I now had to account for 3 directions. To address this, I got rid of the toggle and color coded the directions instead. Another thing was route frequency. Including frequency and scheduled time seemed confusing so I replaced scheduled with frequency. The new data also mentioned Out of service buses. I didn’t want to clutter up the screen with those since by definition you can’t get on them so I decided to include those on another screen.
I got more feedback on V3 that using colors to show bus direction wasn’t the most intuitive and that generally the bus icons add cognitive load to the screen. I think that feedback makes sense. Colorblind users or the brightness of a screen could affect the user’s ability to extract meaning from the colors. And without the color, the bus icons don’t really tell you anything. So for V4 I got rid of the color coded bus icons and used the arrow icon to show direction instead. These icons are more subtle, but I think that’s ok because bus direction isn’t the most important info when you also have the route destination. I did use the color red for the rerouted bus line, but there’s also text to back it up.
FINAL ITERATION
I was able to get my HTML prototype to look very similar to my mockup. I had to use a different refresh icon because that’s what I had access to in Font Awesome. I coded some of the screens in the paper prototype as well, although the focus of this project is the schedule screen.
For my HTML, I used section tags. The map is its own section and the list is its own. Within the section for the bus list, I used an unordered list for each bus line.
For my CSS styling I mainly used the box model, but I struggled to get the time where I wanted it, so I ended up using the float property it instead of using the inline-block display.