"Wait or walk": A transit notification Installation

This project was based on designing a transit notifier device in the environment, specifically in the Georgia Institute of Technology campus. The university campus runs multiple bus services for students between campus buildings to help students and faculty quickly move around campus. Most of the campus is also walkable, just in case you miss the bus, however, is much more inconvenient. Also, there might be one or more ways/combinations of buses to get to a certain destination. We currently have a mobile phone app and a website that returns live updates of bus positions and timings on campus, that is fed by the NextBus API. Our aim was to improve our rider's experience and fix problems they have while commuting with this current setup. The design described below was heavily user centered.

Team: 3 students, including me from HCI and Industrial Design background.

Role in project: Headed the research, brainstorming and design sessions. Also jointly contributed to the final design. A lot of heavy lifting prototyping was done by my team.

Duration: 1 month project

Keywords: User Centered Design, Interactive Environments, Installation, Transportation, Physical Prototype.

Our project aimed to solve a problem that we discovered from a user survey, about catching campus buses from Tech square to either Klaus or Clough. We determined, by means of a survey, that this was one of the most frequented routes on campus. Users were generally interested in knowing what was the quickest way to “reach” either of these two destinations (Klaus or Clough) from the point that they arrive at the bus stop. Also, the acceptable wait time for users, at the bus stop for a bus, was between 5-10 minutes, after which, they claimed to to walk the distance instead of waiting any more. Since users intended to take the bus, they were usually rushing to wherever they needed to go. Along with rushing, they were planning their commute very much in the moment as they walked towards the bus stop. Also, one of the main problems was that even if a bus arrived, as notified by the nextbus app, many a time the bus that arrived after a period of waiting was extremely crowded, preventing users to get into the bus. By this time, the user would have lost a lot of valuable time waiting for the bus, which could have been used in walking to the destination instead.

User research:

Our primary user research was done through interviews and surveys. We used a few interviews from fellow students to get some qualitative data about what questions would be interesting to use in a survey, and thus created this survey here.

We received 44 responses on our survey. Here are the survey results.

Key Findings from Research

  • Users don’t trust nextBus app
  • Users want to know if it is worth waiting for the next bus at all
  • Users are generally in a rush
  • Users are planning in the moment
  • Users wait 5-10 minutes for the bus
  • TSRB is the most frequented stop, followed by Clough and Klaus
  • Users generally wanted a way to get from Tech Square side of campus to the Main campus.
  • Users want to know how crowded the bus is before it arrives

Decoding the problem

Organizing our thoughts based off the survey and research.

Converting text from the previous whiteboard into actionable diagram use case sketches.

We organized our user requirements and concluded that these were the messages we needed to user:

  1. The route from TSRB to either Klaus or Clough. - This was the most common route and seemed to be a concerning problem. So although this is very specific to our problem space and might not be completely easily scalable to other stations/transit systems, it lays a foundation for a pretty solid user centered design.
  2. Should I wait for the bus or leave?
  3. If I wait, which route will GET ME THERE fastest?
  4. Is the bus I am waiting for crowded? Does it even make sense to wait for a bus I can't board?

We found that the choice a user makes on whether or not he needs to wait for a bus or go (start walking) depends on various factors:

How much time will I take to reach my destination, starting right now?

Reaching Time = Time for bus to arrive* + Time to travel to destination**

*Time for the bus to arrive is taken from the nextBus API. (bus current position -> rider position at bus stop)
**Time to reach destination is taken from Google maps, taking into consideration any traffic conditions (rider position at bus stop to final destination, inclduding time in bus, plus any walking needed).

Which route gives me the shortest reaching time?

For each destination, there are 3 possible ways to get there:

Tech square -> Clough

  1. Trolley till Klaus + walk to Clough
  2. T/S Express to Clough
  3. Walk all the way to Clough

Similarly, for Tech square -> Klaus

  1. Trolley till Klaus
  2. T/S Express to Clough + walk to Klaus
  3. Walk all the way to Klaus

Our job, is to convey to the user which one of these routes, for each destination, has the minimum reaching time.

Will I be able to get on the bus when it arrives? (Crowdedness)

Additionally, we also want to tell the user if the upcoming bus is crowded or not. No specification of the minimum reaching time is good enough if the user cannot mount the bus. So we also want to convey this information to the user. However, we only want to convey this and let the user make his decision on whether or not he wants to wait for a crowded bus, because this is a very subjective measure. We currently don’t have a sensor to measure crowdedness of the bus, but we anticipate, will in the future this is something that each driver would be able to set for their bus. 

Effectively, we have something that looks like this:

Choice = Function( min[Timearrive + Timetravel] , crowdFactor)

Ideally, we would like to make a choice for the users, but we found that crowdedness is a very subjective value, and how a rider perceives it may also differ. Hence, we leave some amount of decision making power with the user, when we suggest an action to take, by simplifying the above choice calculating everything except the crowd factor. Our final design below reflects this, by displaying simple suggestions based on reaching time, but allows the user to make his own choice about crowdedness.

Final design

The final design will be deployed at Tech square, near the bus stop.

Messages Displayed to user:

  1. Wait or go (what is fastest)? ——> Color of lights (Yellow or Blue. Yellow for wait and Blue for go). We tried to shy away from traditionally red-green because it doesn't support color blindness.
    • Trolley or T/S Express or Walk? ——-> Specific route highlight on the display, either one would glow yellow.
  2. How crowded the upcoming bus is
    Crowded or not crowded? ———-> Flashing vs. non flashing light, a metaphor for ‘bursting’ outside the bus.

We chose colors and flashing to make it appear as glanceable as possible.

For example,

  • if a route involves only walking, only the walk sign will glow.
  • If a route involves a direct bus, only the bus will glow
  • If a route involves a bus + some walking from the stop, then both, the bus and the walk sign will glow for that route.

Placement in the Environment:

In terms of placing in the environment, we experimented with different placements at Tech Square. One idea was to place the board on the ground in front of the bus stop. The drawbacks of this was that it would not be visible to people approaching the bus stop when there already are people standing around it. Also, it is easier to see something at closer to eye level.

  First attempt at planning the placement in the environment...

First attempt at planning the placement in the environment...

So finally, we propose mounting the display on a stand around 2 metres away from the stop, to prevent crowding around it. Also, we will have 3 same displays of our prototype arranged around in a circular fashion around the mounting stand, to allow multiple people to see it from all directions, and to allow more people to see it at once.

  Final decision for placement in the environment!

Final decision for placement in the environment!

Fabrication and Implementation

While this post focusses largely on the design of our system, feel free to find details on these, do visit our class blog post here.

We also have the code and KiCAD diagrams for our PCB and for the ESP-8266 up on github.

Final product in action!