Survey
To kick off this project, I created an 18-questions survey focused on the need of the riders. I wanted to find out their pain points either in case they already use a transit app or not.
Some of the results were as follows:
Project Summary
Summary
The Challenge
Due to expansion, numerous bus routes of a mid-size city have been recently 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. Simply rushing to the stop when a bus is coming no longer works because it might not be the bus the rider is expecting.
The Solution
This app solves the problem by providing 2 key pieces of information to the users, arrived at by research and testing: 1) What is the next arriving bus, and 2) How much time the user has to get to the bus stop.
The Process
Discovery
- Project brief
- Technical specifications
Analysis
- Research
- Competitive analysis
Info. Architecture
Information Architecture
- User stories
- Wireframes
- Mockups
- Usability test
Visual Design
- Hi-fi mockups
Product definition
Project Brief
BusyBus is an application operated by the local city transit system that serves thousands of commuters in a large city, putting at their availability real-time bus arrival information.
Roles
- Researcher
- Content Producer
- Usability Tester
- Visual Designer
Deliverables
- Competitive Analysis
- User Stories
- Wireframes
- Branding
- User Testing
- Prototypes
Tools Used
- Pencil and paper
- Google Forms
- Google Docs
- Figma
- Adobe Photoshop
- Adobe Illustrator
- Atom
- GitHub
Research
85% Need their bus to be on time.
68% Of the participants take the bus.
62% Ride the bus as part of their commute to get to work.
70% Of the responders affirmed that they need to know when the next bus will arrive.
92% Live 5 minutes away from their bus stop.
77% Of participants expressed that they need to know if there are delays on the route.
Research
Competitive Analysis
To get to know what transit apps BusyBus would be competing against, I performed a competitive analysis of 2 apps: Moovit and Transit.
These are some key points I got from the research:
This app is well established in the market. It has a very effective message to identify itself from the competition. It offers a “next arriving bus” feature as well as an “estimate time for bus arrival” feature. As a threat to the app, I found out that there’s a lot of competition in the market, something that this app has to keep in mind even though is well established.
This app is also well-known by users. It presents itself very clear and easy to identify among the competition. Among the many features, it too offers “next arriving bus” and “estimate time for bus arrival”. During the time I downloaded it to try it out, I found it a little confusing by its many features.
Analysis
User Stories
To create user stories, I concentrated on the features that the app should have based on the main concerns and findings from the survey. I work mainly on all the stories that I deemed “high priority”, but I also included 2 “medium priority stories” to come out with a well-rounded MVP.
| Role | Tasks | Importance |
|---|---|---|
| As a user | I want to know what is the next arrving bus | High |
| As a user | I want to know how much time I have to get to the arriving bus | High |
| As a user | I want to know in how many minutes my bus is coming | High |
| As a user | I want to know if there are delays on my route | Medium |
| As a user | I want to edit my route | Medium |
| As a user | I want to get directions to go to a new place | Medium |
| As a user | I want to get alerts about my commute | Medium |
| As a user | I want to know what other routes are nearby | Low |
| As a user | I want to know the weather | Low |
| As a user | I want to log into my account | Low |
Design
Skeching and Wireframes
I set up to sketch 3 screens:
- Planning a trip.
- Incoming buses.
- On route.
I wanted to put into paper my first raw ideas and after some testing and iteration, change the design accordingly to the feedback that I would receive.
Initial sketches for the 3 main screens
Wireframes Testing
I took the rough sketches that I initially did and tried to refine them further in preparation for user testing. I planned to test directly the paper prototypes since this would give me the freedom and speed to make any changes based on the user feedback. I had to design the paper prototypes a couple of times because I wanted to make it look as presentable as possible so the sketch itself won't distract from the main actions that I wanted the user to take when testing it.
After this was done, I tested it with 3 participants. My main goal during testing was that the iterations were easy to use that the user could perform the task successfully. These were the pain points and changes I found after testing:
A tester interacting with a paper prototype
Change "Nearby Stops" to "Next Bus"
Before:
To inform the user of other route options, I added the feature "Nearby Stops" A . But upon further research and consultation with my mentor acting as a product manager, we came up with the conclusion that the user didn't need to move to another stop to catch a bus All the buses would stop at the same stop (that was part of the problem in the first place that the app was trying to solve).
After:
I changed it to read "Next Bus" B . Upon further iterations though, the better and more clear term "Next Routes" was decided on.
Add labels for icons
Before:
On the navigation menu, I was planning to use icons for the buttons A .
After:
After the user testing, I discovered that it would be more clear if I added labels to accompany the icons. B
