Next Muni

The Problem

Competitive Products Analysis

I initiated this app based on my personal needs. As a student who lives in San Francisco and commutes by taking Muni buses every day, I have tried several different arrival time prediction apps. However, none of these apps was smart and had enough customized information for individuals. Therefore, people need to spend tons of time to interact with the app to find the right information they need.

The following table shows how many interactions were needed for a same task in two mainstream Muni apps and Google Maps.

Design Goal

The goal of the app is to show people the correct information right after they open it in the follow-up same task usages. By grouping and saving the data of where and when people used the app and which Muni route they searched, we can save people's time and efforts by guessing their needs base on their search history and current location.

By doing this project, I would like to simplify the connection between people and the right information they need. So, they could live a more efficient life.

Design Process

User Journey User Flow Paper Sketch Mood Board

The target users of bus arrival time prediction apps are those who have a relatively fixed daily routine — go back and forth between home and school or company — and take public transit every weekday. They know which bus they should take and where the station is, or they can get this information from other prepositive apps like Google Maps. However, they don't want to open Google Maps and input destination whenever they need the time information again and over again.

It's also important to go through the whole process in the shoes of users new to the app, and try to understand where, when, why and how they use this kind of apps. After having a clear idea of what the interaction logic should be, then I started to sketch some rough ideas on the paper. A mood board with all the themes I wanted to communicate is also necessary to bring the whole idea to life. I even customized the style of maps based on the color palette that generated from the mood board.

Iterative Design

Test Early and Often Self-critique Ask for Feedback

The first version of the design could finish the major job successfully — all the time data are updated automatically and listed on the home screen. What people need to do is just open the app.

However, after I tested it with my classmates, it turned out that some people doubted about the app — what does the time mean? Others curious about what the app looks like when there was no route saved yet. So, I started to tweak the app and then the second version came out.

I made multiple improvements in version 2:

1. An onboarding screen was added for new users. Showing some nearby routes may help them get started and keep efficient since they haven't searched for any routes yet. A brief description of how this app works can also assist them to build mental model and make the onboarding process more smooth and friendly.

2. Inspired by the concept of "nearby routes," I added it to the search page right below the search bar. It can save tons of time if the user could find the targeted routes in the list because the cost of typing is much higher than choosing.

3. The contextual user guide also appears when users finished their first "search" or "save" operation, so they know how to edit the item in the list.

4. Redesigned the clock down icon. So, now people can tell the meaning of the time correctly.

The third iteration was started with the visual — the original red color (#F45550) was replaced by a new one (#FB8883), which looks more elegant and works better with maps. To make everything more clean and organized, a series of templates were also introduced. Lots of Sketch Symbols were created and nested within each other. I also created Symbols for hidden parts, such as paddings for placeholder texts and tapping targets underneath go back buttons.

I got some inspiration after reading Scott Hurff's blog about the Thumb Zone, and redesigned the Home page for one-handed use in version 3.

Another change I made was how people choose previous stop and next stop on the Detail Page. Comparing with tapping on two buttons, swiping left and right within a larger area is easier for people to navigate. I also simplified the flow by not showing the map-only screen. Instead of asking people to choose a stop on the map, now the app will show the nearest stop automatically.

At the end of the iterations, an interactive design specification website was genereated automatically within Sketch for implementation. Engineers can even copy the codes that generated based on the UI.

Motion Design & Prototyping

Motion Design High-fidelity Prototype

The static screens in Sketch only define layout and flow, now it's time to use motion and prototyping to bring them to life.

Low-fidelity prototypes are great to test flows quickly, but when it comes to motion only video editing software (like After Effects) and codes could give us the most precise control. Now that transition and animation are all about feelings; there's no reason not to design them as real as possible.

I tested multiple solutions for each transition between two screens to make sure each motion not only feels delightful but also has a logic or reason to back it. Such exploration also allows me to have a better understanding about the navigation of the app and make improvements constantly.

Bonus: Another Side

System Thinking

As Google Glass apps, good Apple Watch apps also require small pieces of information that tight to time and location, as well as light and simple interactions. So, I designed following user experience for Apple Watch at the end of this project.

If I have more time for this side project, I would like to explore Apple Watch app a little bit more. Compared to iPhone apps, Apple Watch apps have their unique interaction, usage, and criteria that can tell the great from the good. How these two apps should coordinate with each other is another question I'd like to answer.