Problem Statement:

Due to expansion, numerous bus routes have been recently added. Many of those routes stop at the same bus stop. Riders want to know when the next bus will arrive at each stop. They also want to know how much time they have to get to the bus stop. Before the new routes were added, riders could simply rush to the stop when they saw a bus coming—but that doesn't work anymore because it might not be the bus that they're expecting. The city has developed a way to know how far away each bus is from a stop, but they aren't sure how to share that information with riders. Riders are currently complaining the most about the bus stop at Washington and State, which is served by seven bus lines.

Users & Audience:

After sending out surveys for research, it turned out our users consisted of working young professionals primarily within the ages of 24-39. These are people who either are choosing to take the bus for environmental reasons, or enjoy curbing the burden of responsibility that comes with car ownership.

Roles & Responsibilities:

I was a one man team for this project. I worked on everything from user research, to user stories, user-flows, sight-mapping and wireframing, all the way to the high fidelity and clickable mockups that were handed over to the developer team for implementation.

Outcomes & Results:

In the end, I managed to make an app that was both simple and effectively met the needs of both the client and the user. The goals we set: have a simple app that gave the information users call "most useful" quickly. Some lessons I learned were: There is always room to simplify and lighten the cognitive load and putting the time in now as the designer is what saves the user time later.

• Survey and Interviews

I started by conducting a survey to understand user needs and desires as well as their past experiences with other transit applications. I then followed up with some of the surveyed users to conduct interviews and ask more in-depth questions.

• Competitive Analysis

Using the survey as a guide, I looked into potential SimpleStop competitors. Using the SWOT method, I was able to identify the Strengths, Weaknesses, and Opportunities for improvement within those competitors. With that information, I had a better idea of the direction I wanted to take SimpleStop.

• Persona

Based on the demographic info from the survey as well as the interview information, I was able to create a persona that encapsulated our potential users.

• User Stories

Using the survey as a base, I formulated three user stories around what these potential users wanted to accomplish by using SimpleStop. I was able to prioritize them based on the survey data while keeping the business requirements from the city in mind.

• User Flows

With the top 3 User Stories defined and prioritized, I was able to make User flows in an effort to be able to articulate and construct how the product would function.

• Wireframe Sketches

With the flows created, I was able to start sketching out the visual elements of the design. Taking the flows from a mental abstraction, to something you can see and touch.

• Digital Wireframes

The next and final step in designing the information architecture of SimpleStop. Through multiple iterations I was able to take the simple sketches and turn them into a robust blueprint.

• Color Palette

With the mood board in mind, I decided on a color palette. Keeping accessibility in mind, I went with dark backgrounds and white text with a call-to-action color of blue, and an accent color of green. (All can be seen in the adjoining photo grid). Blue was intentionally chosen as the call-to-action color because it is known as a relaxing color and transit can be an anxiety ridden experience. Using a light blue meant it was bright enough to be noticeable as a call-to-action but familiar and calming at the same time.

• Typography

Helvetica was the final font choice because of its reputation for being all business. Because this product is a service with a purpose of clarity and simplicity, having bold and readable text was of the utmost importance.

• First Prototype Iteration/Usability Testing

After all of the UI elements were in place it was time to implement them. With the first iteration of a fully fleshed out mock up designed, I engaged in some usability testing and was able to gather helpful data that influenced the final High Fidelity Prototype. Uniformity and spacing were the most commented on components during testing. Those were top priority for the next round.

• Final Prototype

With all of the testing complete and changed implemented I had a final design to recommend to the city as a solution for their problem. Below are the still of the final mock-ups with the user feedback addressed. If you click on the stills you can experience the full clickable prototype.

1. Lessons Learned

• Never Underestimate Padding

One of the things I learned in between iterations of the final mock-up was to never take padding for granted. Having enough space within a clickable area for fingers to properly click is very important. I also found that padding was an answer to uniformity issues from page to page of the product.

• Less clear information is better than more unclear information on a page

One of the problems I faced during usability testing was a seeming jumble of information confusing my testers. The answer ended up being to spread the information and sacrifice having it ~above the fold~. It was a great lesson in some of the subtle priorities we have to think of as UX designers.

2. Recommendations

• Make sure the arrivals page conveys the amount of time until the bus arrives.

In its current state, it could be construed that the arrivals page is telling the user what time the bus is arriving instead of how long it's going to be until it arrives. It would only require a subtle change in the design, but it would be impactful to address before launch.