The Problem

At the inception of the project we were given an ill-fitting name and presented with two guiding questions:

1. How can we provide timely congestion information and routing recommendations to all road users to better inform their transportation choices when major incidents occur?
2. How can we support roadway users (especially drivers) who may need to shift transportation modes during unanticipated major congestion scenarios?

We were to be called the Mobile Ticketing Enhancements for General Population Incident Avoidance team, of which I was the Project Manager. The six of us students spanned the departments of HCDE, CSE, CEE, and Communications.

The Problem with the Problem

Despite our name being Mobile Ticketing Enhancements, we didn’t actually need to enhance mobile ticketing — the real problem was with availability of incident information to the public. But, we didn’t know this at first. The questions listed above were actually shown to us quite late in the process. Before coming to our eventual solution, we trudged through a trying period of research, surveys, interviews, presentations, and getting our ideas rejected again and again. Confusion turned to frustration. How could we be getting it wrong this many times in a row? We had to rethink our approach, confront our propensity to jump to solutions, and redefine the problem space.

Redefining the Problematic Problem

Being given the name of Mobile Ticketing Enhancements for General Population Incident Avoidance had biased us to believe that we were going to make a new mobile ticketing application for Seattle. Through a frustratingly stagnant 10 weeks, we learned that what our mentors really wanted from this capstone was a way to get single occupancy vehicles off the road during a major traffic incident–and this should be achieved in any way we found plausible. This realization drove the next 10 weeks of our work.

We researched Seattle’s existing mobile ticketing and transit systems, held a focus group, surveyed nearly 100 Puget Sound commuters, and interviewed experts from Google Maps, CBS News, Sound Transit, Bytemark, and more. We found the root of the problem to be the following three considerations.

1. Information reaching the public is inconsistent because interagency communication is fragmented.*
2. The current transit solutions are only partial solutions to the needs of Seattle drivers and transit users (see table below).
3. People want to be empowered to make their own decisions rather than be prescribed one.

* Halfway through our 20 week capstone, we learned of an in-progress project which would solve the issues with fragmented interagency communication: the Virtual Command Center (VCC). The VCC is an application to be used for communication between all Seattle transit agencies, emergency services, and media outlets involved in a major incident.

The Solution

We began our project with a broad idea of what our solution would accomplish — it could be any one or combination of physical information displays on roadways, a website, an application, or something more novel. Through surveys, interviews, and our focus group, we found that a web platform would be the most apt solution and meet our users where they are. We chose to not create an application because it would be infrequently used (and thus difficult to market), expensive and time-consuming to implement, and inaccessible for users without smartphones. A website was the simplest common denominator that would reach as many users as possible and allow for the greatest integration of accessible design practices. We found that the best way to convince people to do what we want (use mass transit) is to provide information that empowers their decision, rather than making a decision for them. Our final design can be broken down into three distinct sections: Information, Map, and Plan your route, which encompass the four systems shown in the chart below. As with nearly all major US cities, Seattle hopes to reduce the amount of personal vehicles on the road to reduce traffic. Though our solution aims to handle a specific scenario in traffic reduction, this framework could be applied in everyday scenarios that may contribute to the greater goal of reducing daily traffic.

If you’d rather see how this website works on your own time, feel free to try it out. Please use a smartphone for full functionality.

Information

The Information tab is where all of the incident information lives. The top of the page includes a summary of the incident with glanceable notices about road closures and cautionary messages. If a user wants to learn more, they can scroll down to see live updates about the incident and they can also input their phone number to sign up for text alerts of the incident. If a user decides to opt-in, it displays a modal that asks them if they would like to opt-in for all future major incidents in the area. This ensures that commuters receive instant information without having to consult multiple sources during an incident.

Map

The Map tab allows users to visually explore the incident which is marked by a yellow warning icon and a red circle that indicates the distribution of traffic around the incident area. If a user decides to zoom in to the map, either by using the +/- sign or pinch/zoom, they can also see heavily affected roads denoted by orange or red lines. Both Street View and the Google Maps search function are enabled in the map view. In contrast to the Information tab, the live map provides a visual understanding of how the city has been affected by an incident.

Plan Your Route

The Plan your route tab is a key functionality that aims to provide users with options for their unique transit needs. Within the route options, users can see a variety of transportation methods that include public transit, car-sharing, bike-sharing, walking, and departure time shifting. Results are displayed on a linear time scale to make comparing arrival times across different options effortless. Once a user taps on one of the options, the map shows the route and gives step-by-step guidance to the user’s destination.

Currently, mapping applications are not able to update incident information quickly, which often results in users being routed through paths that are blocked or otherwise inaccessible. The VCC will provide General Transit Feed Specification-formatted data which will quickly and accurately update Google Maps, effectively solving the problem of inaccurate mapping applications. For parking, SpotHero for will be used to reserve a parking space, and if the user chooses to use transit, Transit GO will be used to purchase a mobile ticket.

Future Work

To complete the implementation of this website, multiple steps will need to occur following the implementation of the VCC.

1. Build out accessibility features such as multi-language support, screen-reader compatibility, and a text-to-speech call-in number
2. Consult with Seattle Area Congestion Management Joint Operations Group (SAJOG) to determine necessary changes prior to development
3. Coordinate with KCM for web-based mobile ticketing solution prior to the launch of Orca Next Gen
4. Plug GTFS-Realtime information into Google Maps
5. Coordinate with City of Seattle to negotiate parking incentives

Lessons Learned

Always question the question.

Often the problem you are presented with isn’t the problem that needs to be solved — it may just be a symptom of the root issue. Ask questions, seek expert advice, talk to users, present your findings to your stakeholders, and solicit feedback and you won’t waste time creating a band-aid solution.

Find the wrong answer, and find it fast.

Sometimes the only way to the correct solution is to pursue the wrong solution. In pursuing the wrong solution many, many times, we found that the frame of reference it provided was enough to get us thinking about what would make this wrong solution into the right solution. The contentiously-attributed Edison quote about finding a thousand ways to not make a lightbulb would be apt here, but I’ll save you the misery of reading that for the umpteenth time. You get the idea.

Communication must be based in trust and empathy.

Early in our process I saw distrust brewing between our student team and the faculty mentors. We felt that our work and opinions weren’t being valued and we became resistant to their feedback because we didn’t understand what qualified them to give it. At that point we were a quarter of the way through the project, and I asked to postpone our progress presentation, instead suggesting that we take some time to get to know each other. Our mentors explained their passions and history and why they started this capstone, and we found that after taking this time to understand each other, both parties were more able to trust each other. We had faith in their feedback and they could count on us to be honest with them and communicate our needs.

Stress is often a sign of passion.

As the Project Manager, I had a bird’s-eye view of the project and was able to see the intricacies of each team member’s role in the scope of the bigger picture. In our final 1:1, my mentor and I reflected on the project, where we failed, and where we succeeded. She reminded me that people who are stressed are often the ones who care. She saw the standards I held myself to–and thus held the group to–and noted that had we not had such passionate individuals on the team, we would not come up with a solution to a problem one industry mentor had thought “impossible” at the inception of the project.