Overview

The client was the transportation agency for a midsize metropolitan area in the Midwest. The city has a network of public buses. They currently list the expected bus schedule on their website and post it at each bus stop. However, if you have ever used a public bus, you know that expected bus times are rarely accurate, as things like traffic, the need for longer stops to assist passengers using wheelchairs, or taking a bus out of service for maintenance can impact the schedule. We were tasked with helping to create a mobile application operated by a city transit system that serves thousands of commuters.

Click for Full Prototype

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.

Process

Discovery and Research
Information Architecture
Brand Development
High Fidelity Prototyping and User Testing

Discovery and Research

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.

Pivotal Survey Results

Google Maps SWOT Table

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.

Dave

Age: 32

Gender: Male

Tier: Professional

Role: Young Professional

Location: Cincinnati

Behaviors

- Relies on Google Maps for most transit needs

- Tech Savvy

- Self sufficient

- Sparingly Uses Transit Apps

Bio

Dave is a young adult with an office job in Cincinnati. He lives alone and commutes to work daily. He enjoys keeping up with tech and appreaictes integrating it into his life. He is as environmentally responsible as he can be and often looks for ways to improve and build upon his progress to become more green.

Motivations

Dave is ok with commuting by car, but for sustainability purposes he would love to take the bus more often. He would like to see a simpler way to interact with the city transit system that felt more perosnalized than Google Maps.

Goals

1. See and understand full bus schedule

2. Be able to easily navigate the app

3. Know where he needs to look for information

Frustrations

1. Has a hard time navigating complicated transit apps

2. Can’t find important information when he needs it.

3. When he finds the information there is too much at once.

Information Architecture

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.

Sketches 1

Sketches 2

Sketches 3

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.

Brand Development

Style Tile

Now that the bones of the product were in place. I needed to assess how it was going to look. I created a Style Tile with various colors/images/icon ideas/typography as a jumping off point.

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.

Logo

Simplicity was the running theme of the product (it's even in the name!) so having a minimal logo seemed like the best choice. Since it was a bus scheduling app, it seemed pertinent to use street signs as the backdrop with the name in the branded Helvetica font.

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.

High Fidelity Prototyping and User Testing

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.

Click for Clickable Prototype

Findings and Final Thoughts

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.

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.

Fire Hose App

You also might be interested in these other case studies.

PlugIn

Page updated

Google Sites

Report abuse