Heartland Midwest Transit Co. is an application designed for a midwest city public transit entity. This application allows users to check, when and where their buses were & provides feedback to users when buses were delayed or unavailable.
I was responsible for this project's discovery & research, information architecture, branding, and usability testing.
This application was deemed necessary after a midwest city public bus system expanded its services. With 7 bus lines now serving their Washington and State stop riders started to :
These issues were compounded by an antiquated scheduling system that used posted paper schedules at stops and posting them online.
I found two audiences for this product:
For the purposes of this project two proto-personas were created based on assumptions about the audience. A final persona was later created after analyzing results from the user surveys.
I created a mobile application and bus brand that would reignite confidence in the public bus system and allow for a more consistent and reliable experience for bus riders. The app allows users to see when their bus is coming, how long they have to get there, and whether there are delays or schedule changes.
Google forms were utilized to collect data from potential users.
Survey results showed that our potential users:
Overall these results confirmed user pain points
As part of our research:
Based on the target audience, I came up with one persona, Christina Wilcox.
- She uses a transit application to keep track of the buses in her area
- She typically uses bus transit to get to and from work on a daily basis
- She typically arrives about 10 minutes before she expects the bus to arrive
- She occasionally finds it difficult to tell different buses apart when are multiple buses at the stop
- She would use an application from city instead of an outside party if the option were available to her
- Be on time for work
- Reduce her environmental impact
- Avoid traffic headaches
- Avoid parking dilemmas - such as difficulties finding parking/spending money on overpriced parking
- To manage all of her bussing needs in one application
- She’s frustrated because bus timing isn’t always accurate & the application she currently uses doesn’t have real time updates
- She may hesistate to switch to a new transit app from the city if that app doesn’t receive great reviews
- Its occasionally hard to tell buses apart - but not usually
- Taking a late bus can impact her job
- Right now she can’t really track the bus in real time OR get alerts if traffic or other factors have impacted the bus
The following user stories are based off of the problem statements and how it might affect users like Christina.
As a young business professional, I want to check the bus schedule in real-time so I won't be late for work.
As a busy professional, I want to know when the bus will arrive, so I know how much time I need to walk to my stop.
As a bus rider, I want to know which bus is coming next, so I know which bus to get on.
These two user flows were my first iterations. After careful consideration of necessary features and flow - I determined that these flows were too complicated.
I updated my user flows to streamline the amount of clicks a user would need in order to achieve tasks and reduced features to stay within the scope of the project.
All members of our team contributed sketches based on our sitemap. We then discussed sketches as a team and voted on concepts and designs we wanted to move forward.
All members of our team contributed sketches based on our sitemap. We then discussed sketches as a team and voted on concepts and designs we wanted to move forward.
For our moderated testing, I created a research plan for interviewing users
During our usability testing I asked testers to complete the following tasks:
There are multiple ways to find what you are looking for and that's good because different people think in different ways but can still find what they're looking for. - Participant
This project didn't call for brand development or any UI.
For the purposes of consistency and accessibility, we did select a palette for presentations along with accessible typography.
All members of our team contributed sketches based on our sitemap. We then discussed sketches as a team and voted on concepts and designs we wanted to move forward.
We made a paper prototype to experiment with new ideas, which allowed us to try out several iterations quickly before committing to a prototype.
All members of our team contributed sketches based on our sitemap. We then discussed sketches as a team and voted on concepts and designs we wanted to move forward.
For this application, I realized that keeping it simple was the best. This was my first design project and I had a lot to learn about how to keep things simple but also still user friendly.
I learned that I needed to do more research into aesthetics and trends before committing to a design. I also learned that I needed to not overthink elements and ideas. Developing a logo and name for the application was really difficult for me but I learned that I had to come up with a process for that that worked for me. I learned to not over think names and if I could go back I would probably really shorten the name down. I also probably not would redo this logo and make it simpler.
For this project, it could go on to be made, but I personally would like to redo the aesthetic and branding. I would then like to do more usability testing to make it into something even better!
Return to Top
