UX/UI DESIGN & SYSTEMS THINKING
A mobile app that simplifies trip planning by learning a user's travel preferences and using that information to recommend routes.
Team project with Isabel Dec, Santosh Basapur
My role: Ethnographic research
Defining system logic
My team started by exploring how people plan trips to get around town to get things done. As we analyzed our data gathered from our interviews, one insightful theme rose to the top: people make trade-offs when planning trips due to differing priorities.
From that point onward, our research shifted to understand what people make trade-offs between and how we could create something that could account for different priorities to accommodate different situations.
This led us to create Sway, a trip planning app that learns a person's travel preferences and only displays trip options that a person would consider taking. Furthermore, it's smart enough to to adjust for context, like weather or day of the week. The more a person uses Sway, the deeper the system's understanding of the person's preferences become and the more Sway is able to simplify trip-planning into a handful of meaningful options.
Simple questions to teach Sway what modes of transportation the user would even consider utilizing.
Hub for all functions and displays relevant info.
Grey band displays shortcut to see routes for events in the user's Google calendar.
Sway has multiple ways of learning a user's preferences.
1. Setup questions
A few questions at setup give the system a general idea of what options a user wouldn't even consider taking, allowing Sway to begin simplifying which route options are displayed.
2. Logging user selections
Each time a user commits to taking a trip option (activating turn-by-turn directions), the system logs the choices and the weights assigned to each priority are adjusted.
3. Logging the circumstances
Sway also logs the circumstances in which a user committed to a trip option. Some of the recorded criteria are time of day, weather, nearby traffic patterns, nearby special events, and events in the user's calendar. Under similar circumstances, Sway will most highly recommend the selection the user chose the previous time.
We synthesized trip priorities into six categories: speed, cost, convenience, comfort, safety, and health. For any given trip, the system will use an algorithm to analyze every mode of transportation and route to identify the top options for each priority. Based on the system's understanding of the user's trip preferences, it will then recommend the appropriate options and throw out options it understands the user wouldn't even consider.
Each of the 3 displayed routes is the optimal route for a given priority.
Business setting prioritizes speed and convenience.
Leisure prioritizes cost, comfort, safety, and health.
Each route is the optimal route for a subset of priorities.
Health and fitness are very important to Samantha. Sway knows this because of how Samantha filled out the setup questions. She works 2 miles away, so Sway's top recommended top option is for her to bike to work.
Samantha chooses to ride to work.
Samantha accidentally sleeps in! Sway knows she's in a hurry because it knows her general work schedule. It makes speed/shortest time the top priority and displays the fastest routes.
Samantha considers driving, but opts to call a Lyft/Uber.
Samantha has a lunch meeting and is running late. Since the restaurant isn't too far, Sway recommends she bikes there.
Because she's short on time, she elects to go with the second option, hailing a Lyft/Uber. Sway logs this choice.
It starts raining and Sway knows that Samantha wouldn't even consider riding her bicycle in the rain, so it strikes that option right off the bat. Knowing that she has a bike, it recommends riding the bus or train home or, as a last resort, calling an Lyft/Uber and leaving her bicycle at work.
Knowing that the buses have bicycle racks, Samantha chooses the first option and gets home via bus.
Having another lunch meeting at the same restaurant, Sway remembers her selection from the day before and makes that the top priority, since the circumstances are basically the same.
Samantha chooses to ride Lyft/Uber.
Samantha's project ends earlier than expected and she'll be able to leave work early. With the extra time, she toggles from "business" to "leisure" and Sway recommends the most healthy and comfortable routes since she's not in a hurry.
Samantha chooses to go on a nice, relaxing walk home.
User Flow Diagram
This diagram shows the logic of the system and the journey a user would have interacting with Sway.
Interviews to Understand
We started by conducting 16 interviews with people of various ages and occupations to understand their day-to-day relationship with transportation. Next, we highlighted meaningful observations for each interviewee. Finally, we looked at our findings as a whole and drew overarching insights or themes. These insights were aggregated into a report.
We believed "Competing trip priorities" to be the most interesting insight and chose to create something that would solve for them. We dove back into our interviews to understand what priorities were key and arrived at the 6 defined above. Then we considered what sort of information would be needed to account for these priorities in a more quantitative way.
Sway is Born
Once our logic scaffolding began to take shape, we began developing a prototype. Multiple iterations of the prototype helped to refine both the logic and the aesthetic.
As our concept was developing, we had to make a number of assumptions along the way. To ground our concept again, we built a prototype with enough fidelity for a user to explore and poke around it on their own. We shared our prototype with 8 people, recording their usage and asking questions throughout. We reviewed the footage, discussing our thoughts and observations, which led to some interesting findings, such as the dichotomy between a person's trip priorities for business and leisure.
Because our concept had a novel foundation, we were encouraged to turn our project into a short paper for submission to a design conference. We chose the CHI Conference on Human Factors in Computing Systems because our concept related to human-computer interaction. We prepared the paper and submitted it. Our paper was not accepted for the conference, but the reviewers agreed with the problem we had identified and found value in the concept we had created.
Here is the short paper we submitted: