workresumeI compared Google Maps, Moovit, and a city app, noting Moovit's extensive navigation options, Google's user-friendly interface, and the city app's design flaws.
View ResearchFollowing interviews with a user relying on multiple apps due to inadequate functionalities, I refined personas to daily riders, encompassing commuters and infrequent users, addressing their reliance on buses and concerns like lateness and personal goals in journey mapping.
The user flow begins at the home screen, and the next step depends on whether the user knows the route or bus number they need to take. This was a critical factor in maintaining the route search and route map capabilities, as they would be necessary unless the user were close to the stop needed and had all routes memorized.
.png)
Click image for larger view
I organized all screens as secondary after the home page, including nearby, route map, route search, tickets, and favorites. Wireframes further developed, defaulting to the nearby screen once the user had entered through the welcome screen, with the remainder of the screens accessible through the menu icon at the top left. The second wireframing iteration changed the navigation from a hamburger menu to a bottom navigation, as there were few enough sections, and bottom navigation is easier to access with one-handed mobile usage.
.png)
Click image for larger view
Throughout the prototyping phase, the ability to access ticketing was removed as part of scope creep due to the extensive requirements of either tying into the city ticketing system or purchasing tickets natively through the app. The first would require a significant time budget for cross-referencing the city site programming, and the second would face payment verification, information storage security, and ticket authentication challenges.
Click image for larger view
Click image for larger view
.png)
Click image for larger view
Click image for larger view
There were two considerations for accessibility in this case, the first for the app itself using WCAG 2.2 and the second for the physical aspect of traversing the world in the analog. There is a filter when looking for the closest bus stop to limit the amount of walking required.
I did run into an issue with the visibility of the yellow badge with white lettering, and to solve this I added a border around all lettering on the badges instead of changing the text to white on just the yellow badges.
The logo and name is a play on words of bug catcher, chosen because it’s the first thing that made me laugh. The logo is a visual of that, a person trying to catch a very small bus with a net.
.png)
The color palette was taken from reference imagery that showcases colors typically found in a city commuting environment. I arrange them most often in a gradient or ombre to prove some whimsy and playfulness to what was otherwise a very white and gray view.
The typography is a combination of Montserrat and PT Sans, both were chosen because they're visible even in very small fonts, which were required for the mobile only design of the app.
.png)
Click image for larger view
I added color and images to my wireframe, finalized the exact dimensions, and added the randomized feature. Instead of the emotions graph I sketched very early in the project, I added an emotion toggle on the month view, allowing the user to switch between the photos and emojis. This way, the information is easily tracked in a way that is intuitive and available to the user.
%20(Mockuuups%20Studio)%20(10).png)
Prototype
I revised spacing for scrollability, redesigned route search graphically, stressed testing or clear prototype explanation, emphasized component organization, process respect, and standards implementation.
View Usability FindingsThis is a product that meets what we set out to do!
Recommendations:
Additional Features
Ticket purchasing through the app
Integration with ride shares
%20(Mockuuups%20Studio)%20(3).png)
