Designing the upcoming TCAT bus app

Route Options Screen

Introduction

CUAppDev is a project team funded by Cornell’s CS department that makes mobile apps.

My team is currently designing the UX for an app that will help Cornell students navigate routes and plan journeys on the TCAT bus system that runs through Cornell and the greater Ithaca area.

My role on the team is to design the UX for the Route Options screen, which shows users all the possible routes for getting from their desired point A to point B.

People Problem

When I want to go somewhere in Ithaca or on campus, I’d like to use the TCAT bus so that I can get there more quickly and easily. But, I can’t do that because:

1. I do not fully understand the complex bus system.
2. Current bus route searching systems such as the Ride14850 app and the TCAT website are too complicated and unreliable to use.

Goals

1. Simplify information on how to get from Point A to Point B via the TCAT for a wide audience.
2. For Route Options, provide users with information about different routes to help them make the best choice.

Target Users

• Cornell community (primary)
• Ithaca College community (secondary)
• Ithaca residents (secondary)

Overview of High-Level Architecture

After a semester of research, preliminary designs and prototypes, my team settled with the following information architecture —

1. Search for the desired destination
2. Select a route from 1+ options that get to the destination
3. View more details for the selection (steps, timeline, transfer details, map)

Exploring the problem through User and Market Research

Overview of research user protocol

We interviewed and surveyed a broad spectrum of Cornell students and staff as a part of our research. The general interview protocol involved questions that would hep us understand where people most often travel to, their thought process when planning a route there, and their current interactions with bus apps and systems.

Findings

We identified the following pain points from the Cornell Community—

• People feel uncertain about whether they are in the right place while waiting at the stops since they are not clearly marked and buses are often late.
• People often are unaware that there are multiple routes from the same or nearby stops that will get them to their destination
• People most often search for bus routes when they need them immediately, rather than for the future

Based on our research findings, we thought it would be best to design for a primary persona based off of a Cornell first-semester student, who is unfamiliar with the area and the bus system. We also looked at Ride 14850 and other routing apps for insights.

Market Research

1. Ride 14850

Strengths

• The app has useful features such as searching from current location, future trip planning and favorites.

Problems

• Users are disoriented and confused by haphazard UI.
• There are often multiple pages of Route Results, but this is very unapparent. For Route Results, Ride 14850 presents all the steps involved in a route on 1 page. If alternate route options are available, they are on separate screens that can be swiped between. The main problem with this is that it is difficult to compare different options (users state that they often overlook the bar and small arrow that indicates there are other options at all).

2. Google Maps

Strengths

• Route results are presented in cards on a single screen with at most 6 key pieces of information.
• The icon route summary is a digestible way to condense a large amount of information.

3. Apple Maps

Strengths

• It summarizes a route result with just 5 pieces of information and a map.
• Journey time and details about the distance and roads taken are prioritized.
• The map, a great tool for visual cues and feedback, is at the center of the experience.

Designing the Architecture for Route Selection Page

At this point in the user flow (Route Selection), the user has identified where they want to go and perhaps where they want to leave from and when. The goal of the Route Selection screen is to present users with options for how to reach their destination.

Focus Areas —

1. Search parameters — These involve letting users choose their starting point, destination and time of travel for a route.
2. Route Options — After searching, an important consideration is the kind information to surface about each route option so that users can make the optimal choice.

1. Search Parameters

Exploration: Visibility of Time Options

Exploration 1: Always Visible, Exploration 2: Collapsed as dropdown, Exploration 3: Collapsed B

Exploration 1

Pros — Easily accessible, Caters to users who want to quickly check different times

Cons — Users search for immediate buses more often (researched), Module takes up screen space, Takes emphasis away from results, Visual clutter

Exploration 2

Pros — Caters to majority of use cases, Allows for more results to be shown on screen, easier scanning

Cons — Takes up screen space, user’s hands will cover results while editing time options, de-emphasizes route results

Exploration 3

Pros — Caters to majority of use cases, Allows for more results to be shown on screen, easier scanning, Lets user focus on single task

Cons — Cannot view results while editing time options

Search Defaults for Primary Use Cases

Most use cases involve searching for buses immediately from their current destination instead of planning ahead. To cater the experience to this behavior, the search’s ‘From’ field defaults to the user’s current location until edited, and ‘Time Options’ defaults to Leaving Now.

Exploration: Catering to Planning Ahead

Primary Use: Default to Leave Now from Current Location. Edge Case: Leave at/Arrive By a certain time

Strengths

• Caters to students, who have to be punctual to classes, meetings etc on their schedules by helping them plan

2. Route Results: High-Level Architecture

The main focuses for the route results are condensing and simplifying bus information as well as allowing users to scan through results so they can compare them efficiently to make the best choice.

All Route Data
-Destination arrival time/ time to arrival
-Origin departure time/ time to departure
-Total journey time
-Bus route number
-Bus route name
-Walking time/distance (all parts of journey)
-Transfer yes/no
-Intermediate stop names
-Location of/Distance to boarding stop
-Location of/Distance to debarking stop
-Frequency of bus
-Time of last bus
-Map of route

Exploration 1— Maximizing information + map

Pros — Everything the user needs to know in 1 place, Map caters to primary persona who is unfamiliar with area

Cons — Overwhelming, Map is unnecessary because primary users will gain familiarity with the area over time (more suitable for route detail page), Not scannable, Lack of white space, Cluttered

Exploration 2— “Where is the stop and when do I get there?”

Pros — Answers immediate where and when questions, scannable

Cons — Does not scale well for routes with transfers, does not cater to users who want to know their final stop

Exploration 3 — Vertical Timeline**

Pros — Scannable, Essential information caters to almost every user, Scales well for transfers and final destinations that aren’t stops

**I chose to move forward with this general architecture as it is the most easily scannable and can be adapted to a variety of route cases

Exploration 4— Icon Summary

Pros — Condenses info well

Cons — More suitable for many different forms of transport, majority of cases will require 3 icons max

Refining the Design Details

The main focus areas at this stage are:

• Improving clarity
• Developing a logical information hierarchy
• Establishing a consistent visual language

Exploration — Improving Mental Model for Routes

Surface exploration

In-depth exploration

Obstacles

• In many use cases, the final destination is a bus stop, the icon is repeated and unnecessary (see Result Style 2A in surface exploration above)
• The icon column is confusing as there are 2 different types of iconography — 1 for actions (walk/take a bus), and 1 for location types (see Route Style 2)
• Condensing into 1 column of icons breaks the mental model, as the starting point icon is now replaced with a bus. Iconography is confusing again (see Route Style 1)

Final Design

After collaborating closely with developers to determine how routes would be ranked and what would be feasible for an MVP, final decisions were made:

1. Logical 3 column model for route cards — The primary information is divided into actions, route line, stop names to maximize clarity and scan-ability in the card architecture and.
2. Route time is emphasized since it is more important. The departure time was given an alternate (blue) treatment since it is dynamic.
3. To/From can be swapped, which adds value for users who want to plan roundtrips.

Prototypes:

Time Options

Swapping To/From

Future plans

• Bus reliability is still a big problem, and TCAT buses are not equipped with GPSs — the next challenge is to improve trust without tracking.