Case Study: Route Detail View for Upcoming TCAT Bus App
Introduction
For my first semester as a member of CUAppDev, I worked on the design team for our upcoming TCAT app. Our mission was to help students, especially clueless freshman, get around Cornell and Ithaca as quickly and easily as possible using the TCAT bus system. The current transit solution is less than ideal, to say the least, and we knew such a great problem like this deserved a great solution.
After conducting user research and analyzing other transit applications (more on that later), we decided on the basic flow of the app, pictured below.
I explored several aspects of all of these views, as did the other designers. Eventually, the four of us each took on one of these three key views to really iterate and work on, the detail view being my focus.
The problem to solve for this view was displaying all of the relevant information about a route and guide users on their journey. Because our target audience were freshman college students, this view had to be especially clear and descriptive to aid navigation in an unfamiliar place.
Research
We conducted user research primarily on Cornell students, from freshman to graduates, to best identify what they wanted in a bus app. I’ve included the most relevant questions that shed light on the problems the detail view needed to solve.
What do you know about the bus stops you use? What do you want to know about unfamiliar ones?
Nearly every user cited location as the most known and sought after feature about a stop, followed by its name and a picture of it. One of the most imtimidating parts of using an unfamiliar transit system is making sure you get to the right stop for the right bus at the right time. We wanted to assure and help users know exactly where they need to be.
When, in the entire travel process, is a map most important, if at all?
The majority of users said they would like a map when getting to the bus stop, as well as throughout the bus ride to see the route. This was not the best worded question, being a bit prescriptive in assuming a map was needed in the solution. From the start of the semester, we wrestled with the idea of whether a map was truly necessary, and if so, where to put one. Ride14850, an existing TCAT app, did not include a map inside the application. While the app has sloppy UI and is difficult to use, the product thinking behind the flow of the app was strong, and proved that a map may not be needed.
That brings us to the competition. We turned towards many other map and transit applications to analyze how they displayed information and guided users to their destination.
Ride14850
Behind all of the poorly sized cells, confusing imagery, and general feeling of sloppiness, the app had a solid workflow to take in important information and provide instructions to get from point A to point B. Looking at the detail page, the app very clearly demonstrates there are two bus routes to take, and I know at which stops to embark and debark. Tapping an (i) provides an image of the bus stop, and tapping the whole cell links to a PDF of the route schedule. While the execution is rough, important data is given priority and is someone coherent. The lack of a map in this view is especially noteworthy.
However, the view is painfully vague for new users, specifically for bus stops. This essential bit of information is watered down to unknown names without a concrete location, requiring more work and research by the user.
Google Maps
Perhaps the go-to mobile application for navigation and transit, Google lives up to its reputation as an intuitive mapping solution. The entire journey of the user is displayed on both a map and a timeline grouped by the location at hand. Time is one of the most important factors when riding the bus, and every important time is grouped to the left for easy scanability. The bold, color coded connectors matching embarking and debarking on a route clearly link bus actions. Details like walking and bus stops are minimized but present.
Google’s highlights their map view from the start, which upon interaction minimizes the timeline. With their use of icons in the map and the summary, the user knows exactly what to do at each step of the process.
Apple Maps (iOS 10)
Utilizing a clever, flexible card overlay, Apple’s redesigned interface is centered around the map. Their detail page in the rightmost image, however, does not include the map at all, relying on icons and text to convey the details of the route. Apple prioritizes locations over times, mainly because tapping the GO button guides the user step-by-step like a car navigation app. In other words, Apple isn’t anticipating users living in this view. However, the content of each cell is largely the same as Google’s, using connectors and icons to identify each point of the journey and hiding additional information.
The Process
One of the early concerns was how to include a map in our design, if at all. Some mockups of the route selection included a map, which led to creating a detail page without one, as going from a map view to map view would be excessive.
The result was a very text heavy screen with a multitude of tappable options. The Live Overview section attempted to cull the best data a map could provide and succinctly display the data. Additionally, I spent too much time thinking about opacity and boldness, when I hadn’t even validated if each cell should include all the information of each bus route.
Taking greater inspiration from Google’s detail view, I moved to a timeline-oriented view, with relevant journey milestones at each step. I continued iterating on the Live Overview concept, but ultimately, it became clear a map would provide the most clarity and data for users, especially freshman unfamiliar with the area. Realizing this, we removed the map from the selection screen, and focused on displaying the details of one route on the map.
Next, I wanted to indicate the action and importance for the data. We planned to give users an option to get walking directions outside of the app, so that action of leaving the app had to be specially noted. Additionally, I wanted each location to be tied to the map, so I added a small indicator next to each location that was also present on the map. I also explored different colors for the timeline connectors, to differentiate walking with driving.
For the first map iteration, I envisioned a mechanism to step through each instruction, with a contextual message overlaying the screen. This idea sounded much better than it actually was: having horizontal and vertical interactions, along with mostly duplicate information, would more likely hinder than help users in finding their way.
At this round of iteration, I once again found myself pushing the envelope on high fidelity work. I spent too much time iterating hard on one particular solution before considering other possibilities. This was brought to my attention most directly with my proposed map design, so I started exploring that interaction more.
I was fixed on linking each step (a location or bus route) with a special icon or color. I imagined each instruction having an icon that would match the corresponding icon on the map, tying these views together symbolically. Yet, as I tried to force my existing designs into this one paradigm, crit sessions confirmed that all the possible confusion from this haphazrd iconographic tagging wasn’t bringing any clarity.
By now, I had iterated the detail cells to rely on these circular icons. Each cell would have an action linked to a detail. Since I had committed to an icon per cell, I was exploring how to convey route relationships via connectors.
Another point made was that the detail labels sometimes didn’t cleanly fit with their respective action. I had made walking, which really is an action, a detail to debarking from one stop. But that walking action is between two locations. In addition, treating riding and walking with the same large icon put each action with the same level of importance, and the contents of the cell didn’t necessarily match the icon. With my hierarchy jumbled, I needed to restructure.
First, I promoted walking from a detail to its own cell with a title. While removing these details, I realized the label was really only needed for steps with a lot of detail, like a bus route. Free from matching icons to a map, I also saved icons for route numbers only. I believe this was one of the best iterations I made for the view, and set the tone for the detail view I ended up with.
I very much wanted to display bus routes in a significant way, to best visualize steps connected to one bus route. I explored deviating from the established cell pattern, everywhere from indentation to special highlighted text. The results weren’t promising, as you can see some of them above. Early on, I had explored incorporating connectors between routes, and it seemed fitting to bring them back with less icons.
At last, bringing color to link items could be utilized in an simple, fitting manner. Each route would have it’s own color to easily distinguish the number of buses one would take, and maintain the cell’s design pattern. I had mocked up the expanded bus stop view before, but I returned to this view with these connectors in mind. Pictured below, I worked with bullets, indentation, and changing the timeline to show stops.
Before I show the final cell designs on the main page, I wanted to showcase my explorations on designing how the map and detail page interacted with one another. Google’s split screen overview made the most sense, displaying the best of both world’s and allowing the user to decide which view they preferred.
The summary on the right made sense for a full screen map view, but I felt like the summary, shown in the center, didn’t work well with the data below it. This could be because of the icon choice at the time. I knew Google must be keeping the summary in the app for some good reasons, so I explored a few variations of the summary below. Ultimately, I thought the information was largely redundant, with the same data repeated below, as well as not quite fitting in with the detail cells below.
I considered splitting the map and detail cells in two seperate modes as well, with a toggle switching the views. However, with a low average number of direction steps and a confusing transtion between pages, the split screen was more functional. After that, all it took was adding a puller tab and adding transparency to the clunky navigation bar. I did retry placing a summary bar on top of the detail view in case the improved details cells helped the visual look, but I came to the same conclusion about duplicate, redundant data.
Following Apple and Google’s map treatment, I made every map stop a blank pin, with special indication for current location and destination. I also added more circles to better define a path for the walking portions. Additionally, I color-coded the navigation path based on what has already been traveled, and what was left to go in the journey. One other small change is regarding the bus detail text, changing from “3 stops” to “Inbound / outbound”. The TCAT stop schedule is more or less a suggestion for drivers; they often make more stops for passengers, and sometimes skip stops if no one is there. Because of this variability, we put less emphasis on the data as concrete by hiding the number of stops and indicating that the stops are “scheduled” instead of absolute. Small gestures at best, but something is better than nothing.
The Result
In the design, the map is always visible, with the detail list only as large as needed for simple journeys and becoming a scroll view for longer trips. By either interacting with the map or dragging down on the cells, the map will appear full screen with a summary view and a recenter map button if needed. Tapping on a cell will make the map full screen and zoom in on the particular step of interest, dismissing the detail view and bringing up the summary. A tap on the summary card will return the screen to the split screen view. The map route color is a new addition. The blue route somewhat conflicts with the current location’s blue color, but I predict we will choose a different first primary color.
While these are my final mockups of the screen, the design may change ever so slightly to accomodate the color palette, iconography, and other UX decisions we make for the app as a whole. For exmaple, when one of the other designers mocked up the design with colors for map routes, I added the visual touch later that night. However, after stretching the limits of my infinite Sketch canvas with over a hundred artboards, I’m proud of my solution, and a bit better of a designer than before.
