Ithaca Transit Application Design — Part 2
Designing a Consistent Visual Language
The next step in this project was to rework the high fidelity work and design a proper style guide. The main goal in this step was to come up with a consistent pattern that could be utilized throughout the entire application and convey our intentions for the application.
Design Process
Inspiration: Designing Around User Emotions
When we first started ideating for this application, we focused on designing around the concept of trust and familiarity. Since bus schedules are not always correct and users voiced explicit frustration with the inconsistency of busses, our intention was to build an interface that was transparent and familiar.
Creating a Transparent Brand
Here, the main focus was to build around efficiency of planning a route. There was no need to design for marketability or build brand loyalty.
In creating a brand that did this and was transparent and familiar, I looked at how to make the interface look as ‘light’ as possible. By maintaining a mostly white theme, the experience did not feel like a completely different application and was focused more on the process of finding a bus rather than the content of each step. In a way, we emulated a ‘vanilla’/stock iOS theme to make the experience feel transparent.
Examples like Facebook and Snapchat look to build a brand through a ‘Facebook blue’ or ‘Snapchat yellow’, but my main focus was efficiency rather than brand loyalty.
Designing a Consistent Page Structure
In coming up with a page structure, I wanted to remain consistent with the rest of the application. Specifically, the route detail view was different from the rest of the application as it centered on a map view rather than cell view. (Screen C below)
Originally, we utilized a full view with the idea that user research indicated a tendency to look at the map view in order to gauge their distance from the location.
However, In generating more feedback, users expressed that knowing how many stops remaining there were was more important than where they were exactly on that route. Screen A was able to solve this as the attention was shifted to the list view rather than the map.
Additionally, in sticking with the idea of familiarity, the focus shifted to the cell content and looked like the rest of the application rather than a different ‘navigation mode’.
For example, Google Maps emphasizes a ‘navigation mode’ as different from the rest of the app. This makes sense if the user is driving and unfamiliar with the area. Because the TCAT bus is a standardized route, and users do not frequently look back at the information there was no reason to build out a completely different mode or experience.
Rather, in our user research, we found that users thought a map might be useful as to verify their location and status on the route rather than deal with location confusion. An example would be: David will frequently check Google Maps while on the bus in order to determine that he is going in the right direction and how far away he is from his stop.
This relates back to the concept of trust and users not trusting that they get on the right bus or are too reluctant to ask/verify
Using Color to Differentiate Content Type
Our use of color was mainly used to differentiate types of content. Specifically, the blue was used to indicate TCAT affiliated stops in relationship to Google Places or recent searches. As shown in the figure below, the color blue is used to differentiate location type in the bus stop glyph and in the route progress line.
Designing a Consistent Language to Visualize Trip Progress
The next step was finding a way to visualize journey progress/summary that could be used in the Route Selection and Route Detail view.
In going with the concept of color depicting content type, I also worked to design a language for journey progress that could be used across Route Summary (Screen A), the Full Map View (Screen B), and Route Selection (Screen C). The line with dots in between stay consistent throughout all these examples with each dot representing a stop.
Designing the Information Hierarchy for Route Option Cells
For this part of the application, I allocated the creative direction to a new member of the team, Mihir Chauhan. In managing this part of project, I wanted to emphasize the important of information hierarchy as well as improving visual design on the team. I felt this feature helped do this and was a great way to learn more about interaction and visual design.
You can read Mihir’s full case study on the cell portion of the Route Option page here.
Final High Fidelity Prototype
The prototype below was created using Framer Studio
Post-Mortem
Team Communication
Our team has since shipped these high fidelity mockups and prototypes to the developers and we are working to ship the final product by mid April. A large part of my role as design manager on this project is to maintain communication between the iOS developers and backend team.
This process involved created accurate style guides, red lining documents, and creating Zeplin files for the iOS developers.
Future Plans
Moving forward, we want to continue to develop on the idea of trust. As it stands, there is no way to track the buses, so the design challenge is to find a way to indicate bus status without this data from TCAT. This may involve designing a method to crowd source or location tracking and poses an interesting non-visual challenge.
