Welcome!

We're a part of the Spring 2010 class of Human Factors and Interface Design (HFID), an advanced design course at Franklin W. Olin College of Engineering and we're using this website to document our project. Feel free to poke around!

14Nov

Final Report

and in the end...

Introduction

The MBTA's vending kiosks currently feature a touchscreen interface for purchasing public transportation fare. With the introduction of such kiosks and the CharlieCard reloadable RFID card system, the MBTA has made strides in improving its customers' payment interaction flow. However, many improvements remain to be realized. The processes of purchasing CharlieTickets, CharlieCards, and Commuter Rail passes require different transactions, and yet sometimes these transactions are very similar (e.g. adding money to a CharlieCard is akin to adding value to a CharlieTicket). With a multitude of fare options, it is difficult for kiosk users to determine how to obtain the correct fare medium with the correct amount. An improved interface would allow users to easily determine what tasks are necessary to accomplish their goal of reaching their destination.

The end goal of each MBTA customer is to get from point A to point B. However, what purpose the kiosk serves changes for different users. Infrequent users know what they want and require the kiosk to translate their desires into the necessary fare type and amount to get to their destination. Regular users, in contrast, already know what they need and require the kiosk to perform a financial transaction.

Our redesign of the MBTA kiosk interface improves interaction in four main ways. First, it increases the visibility of information. For example, Fare prices are now provided during the purchasing process rather than externally taped to the kiosk. Second, we simply the navigation by flattening the hierarchy. Third, we provide for our disjoint users by customizing the interface. Finally, our redesigned interface assumes less knowledge. We provide access to all necessary information through the interface discretely so it is available to the inexperienced user but does not annoy the experienced user.

Personas and Scenarios

We created four personas after our initial user visits. Each embodies a usesr with different needs. Although we originally focused on Ted the Tourist as our primary persona, we realized after our paper prototype testing that Chris's needs were completely different than Ted's. Thus, throughout our design process we focused on two primary personas Chris the Commuter and Ted the Tourist. Often we refer to the Chris and Frankie personas more generally as regular users and the Ted and Sally personas as infrequent users. Learn more about our personas here.

Chris the Commuter

Chris the Commuter embodies users who take the T to get to and from work on a regular basis, thus requiring convenience and low cost. He uses the CharlieCard and an occassional monthly pass; he's very familiar with the T and the ticketing kiosk.

Frankie the Freshman

Frankie uses a CharlieCard received from a friend, but occasionally forgets it at home and needs to purchase a CharlieTicket. He has used the MBTA kiosks before, but never without friends nearby to help him. Frankie's decisions when purchasing CharlieTickets are motivated by cost, and he is willing to take time to experiment with the kiosk.

Ted the Tourist

Ted is among the many visitors to Boston who is unfamiliar with the MBTA system. Ted also embodies the user who resents being publically outsmarted by technology. Never having used an MBTA kiosk before, Ted wants to easily and independently be able to determine what fare medium is most appropriate for his visit and how to purchase it through the kiosk.

Sally the Sporadic

Sally is a Boston area resident who uses the T less than once a month for trips into Boston. In the interest of convenience, Sally purchases CharlieTickets rather than having to keep track of a CharlieCard. She is familiar with the kiosks but not comfortable with them since she uses them so infrequently.

Scenarios

  1. You are a new user of the T. You are currently at Eliot Station and are trying to meet a friend at Park Street. Get directions to Park Street and purchase the fare necessary to get there.
  2. You are a regular commuter who uses the T to get to work every weekday. You have a CharlieCard that you add value to regularly. You have a low balance on your card. Use the kiosk to add value.
  3. You are an infrequent T rider and do not have a CharlieCard. Purchase fare to get yourself to a destination and back again.

The Current Kiosk Interface

The current kiosk interface is hugely complicated and non-intuitive for users. In fairness, the kiosk has to work within the constraints of a complicated system of fares that simply has many options. However, it makes some assumptions about the user that often aren't true as well as presents information in unclear ways. The four main categories of areas for improvement we found with the current kiosk are its current need for external information, that it assumes knowledge that the user doesn't necessarily have, its complexity, and its inconsistency.

  1. External Information
  2. The most obvious example of the need for information from outside the kiosk is the fare rate that is often taped to the top of the machine. We saw no reason to need to display this information outside the kiosk rather than having it display as the user is using the machine. Additionally, maps are only external to the kiosk, so users have to determine their route either before they leave home or at the maps posted in the stations.

  3. Assumes Knowledge
  4. The system assumes that every user knows the same things. It assumes that tourists know the difference between CharlieCards and CharlieTickets and that they will be able to find out how to get from one station to another. Additionally, it assumes knowledge of Commuter Rail zones, the difference between Inner and Outer Express Buses, and transfers. If a user has a question about any of those things, they cannot get the answer from the kiosk.

  5. Complex
  6. The current system is incredibly complex. Not only does the user have to know all the things mentioned above, they have to be able to navigate through many screens and make choices based on that information—information that they may not actually have. The user is expected to do math in their head, rather than having the system take care of it for them. Also, in all of its complexity, the system limits the number of fares and passes that can be purchased at once. Therefore, a family of four that wants Commuter Rail passes must go through the process twice, due to a 2-fare limit. Finally, there are the separate validation machines, which seemed to confuse every user we talked to. They are a huge source of confusion for users of the system, but were enough outside of the scope of our project that we chose not to change them.

  7. Inconsistent
  8. The current system is confusing in its consistencies. Passes are not clearly grouped. For example, in order to purchase a monthly Commuter Rail pass, one must go to Purchase Pass, then Passes, then Monthly, then select the Commuter Rail. There is no way to purchase a monthly Commuter Rail pass by going from Purchase Pass to Commuter Rail. There are similar problems with Linkpasses.

Final Interface Design

Main Improvements

The main improvements we made to the kiosk fit into four categories: a flattened hierarchy, improved visibility, assuming less knowledge from the user, and customization to the needs of the user.

  1. Flattened Hierarchy
  2. The current kiosk interface has a multitude of options that are organized into very specific, non-intuitive groups. In our design, the options are laid out in a way that we believe most people will understand without effort. There are fewer steps for most interactions, but the many tasks available on the current interface are all still able to be done.

  3. Visibility
  4. One of the ways in which we improved on the current kiosk was by increasing the visibility of the status. When a user taps their CharlieCard or inserts their CharlieTicket, the remaining value on their Card or Ticket is displayed on the main options screen. It is also displayed on the screens they go through to add value to their card or ticket so that they can know how much is left. Rather than interrupting the task of adding value with the task of determining the value left, they can simply see that information while they add value.

    Another area in which we increased visibility was in prices. We displayed fare prices on the kiosk screen itself and gave users the opportunity to compare fares by tapping on the "More Fare Info" buttons.

  5. Assume Less Knowledge
  6. One of the biggest areas of possible improvement of the current system that we saw was in the dichotomy between what users know and what the kiosk expects them to know. As mentioned earlier, the kiosk has options often fairly hidden in places that many users wouldn't think to look; we made the options more clear so that the user would not need to know how all the fares are related to each other in order to get the one they wanted. We also added functionality like the "Get Directions" option. This allows a user who knows where they want to go, but not how to get there or the appropriate fare, to get the information and ticket they need based on the information they have.

  7. Customization
  8. The user group who uses the MBTA system is huge and diverse. Even when we narrowed our focus to just two of our four personas, we found that what worked very well for one of them did not work well for the other. Thus, we added customization for the experienced user. A user who taps a CharlieCard will be presented with the option to quickly add value to their CharlieCard in the same amount and with the same method of payment as their last transaction. Then, what was a multi-screen interaction becomes, for them, a one-screen interaction.

Interaction Flow

Our interaction flow, as seen above, is fairly minimalistic. The main options carousel screen allows the user to get to every other option. From there, they choose options like the amount of fare, the zone for their pass, the length of their pass, or their destination. Every path eventually leads to the payment screen (unless the user cancels).

Implementation

  1. Touch Screen or Tap CharlieCard (implemented)
  2. On this first screen, the user has the option of tapping their CharlieCard or touching the screen to begin a transaction. If they tap their CharlieCard the main options are presented in a different order prioritizing the ones that relate to CharlieCard owners. There is also an additional "fast cash" customized option based on the user's previous transaction. Since our prototype could not actually read CharlieCards, we simulated this functionality.

  3. Main Options Carousel (implemented)
  4. The main options carousel is a horizontal scrollable carousel that contains options for any available transaction and is customized to the user based on their CharlieCard

  5. CharlieCard Options Screen (implemented)
  6. This screen allows the user to choose between three standard dollar amounts to add to their card ($5, $10, or $20). There is an additional other amount option where the user is taken to another screen and can specify a custom amount.

  7. CharlieTicket Options Screen (implemented)
  8. This screen allows the user to add value to their CharlieTicket in increments of fares for the bus and subway. The user simply specifies how many subway rides and how many bus rides they would like and the total cost is automatically calculated. This screen also includes an other amount option to give the user the flexibility to specify another amount.

  9. Commuter Rail Options Screen (not implemented)
  10. We paper prototyped this screen but it did not make it into the high fidelity prototype. This screen allows the user to purchase commuter rail tickets. In the previous interface, monthly commuter rail passes are separate from other commuter rail passes. We simplify this by adding a single checkbox that changes the pass from a single-ride pass to a monthly pass. Our interface also includes a zone map that shows which stops are included in which zones.

  11. LinkPass Options Screen (implemented)
  12. The linkpass screen allows the user to choose between a one-day and a seven-day linkpass. A brief description of the linkpass is included in the corner due to the relative obscurity of this fare type and its liklihood of appeal to new users.

  13. Directions Search Screen (implemented)
  14. The directions search screen is very similiar to the Google Maps search bar. Users can input an address, a station, or a landmark and received directions to that location.

  15. Boat Options Screen (not implemented)
  16. The user would be able to purchase various types of boat passes.

  17. Monthly Bus Pass Options Screen (not implemented)
  18. The user would be able to purchase various types of monthly bus passes.

  19. Monthly LinkPass Options Screen (not implemented)
  20. This screen would be extremely similar to the single or seven day linkpass screen. The user would be able to purchase a monthly linkpass.

  21. Other Amount Screen (implemented)
  22. This screen consists of a keypad and not much else. It allows the user to add a customized value to their CharlieTicket or CharlieCard.

  23. Directions Screen (implemented)
  24. The directions screen displays directions from the user's current location to their destination inclduing stops and transfers.

  25. Fare Summary Screen (implemented)
  26. The fare summary screen displays a list of all the types and cost of fares necessary to get to the previously specified destination. Users can remove fares if they wish and choose to purchase round trip.

Future Improvements

There are plenty of things that we would do to continue to improve our kiosk redesign if we had the time to do them. The most obvious is to continue the options for things like Bus, Boat, and Commuter Rail. We originally had plans for the Commuter Rail, but later determined that we needed to focus on the CharlieCard/ CharlieTicket distinction before working on the Commuter Rail.

There are a few key functions that are missing, such as the option to erase a number on the "Other Amount" keypad, or the ability to actually deselect a section of fare on the "Fare Summary" page.

We went through several iterations of our "Get Directions" screen, and if we had time, we would like to take parts from each of them. The first prototype was lacking in that we had no database from which to get real directions; additionally, we did not display a map for the user to see. Our second iteration, on the other hand, had a map, but incorrect directions due to the limitations of the available API. If we had time, we would have the system guess locations as the user was typing and display those guesses on the screen (as in our first prototype), but then include a map with their route highlighted in addition to written directions (as in our second prototype).

One functionality of the current system that we talked about early on but never implemented was the ability to tap a Senior, Student, or Disability card and receive the appropriate lower fare. We chose not to implement it because it was not crucial to the understanding of our design. However, it would be nice to include eventually.

Finally, there are many look-and-feel things that could be changed. We had talked of making the "Next" button on the "Directions" page an arrow that said "Fare Summary" instead of "Next". We also would want to fix a few inconsistencies with placement of buttons—for example, ensuring that all buttons that would take the user to the next screen are placed in the lower right. Things like icons, colors, and formatting are infinite wells of opportunity that we might choose to explore more, given the time.

Implementation Tools

Our team chose to use a combination of web tools including HTML, CSS, JavaScript, and PHP to create our high fidelty prototype. These web languages offered us a significant amount of flexibility and control for implementing both the interface design and functionality.

Using CSS made it easy to maintain a consistent look and feel throughout our prototype. We were able to alter the color or style of an element appearing on multiple screens by changing the specified style in one place—the CSS file. Layout was one of the more difficult tasks to complete using CSS. Whereas in PowerPoint you can easily manipulate the spacial location of each item, CSS requires a bit more finesse to obtain the desired layout.

Javascript and PHP gave us the ability to make our prototype interactive and dynamic. Much of our prototype's more complex functionality was not implemented. However, using these tools gives us the opportunity to easily build on what we have already created.

One limitation of our tool choice is our inability to simulate the hardware interface of kiosk including the "tapping" of the CharlieCard. Also, since our interface is meant to be a touch screen, it would have been advantageous to test the prototype on an iPad or othe touch screen. It is difficult to test certain aspects of our prototype when the user is using a keyboard and mouse.

In addition to being flexible and powerful, our toolset proved to be fairly easy to learn. One of the challenges we faced with our choice of tools was the lack of overall team web development experience. We were worried that a high learning curve would set back progress on our prototype. However, even though learning these new tools was challenging, working as a team we were able to efficiently learn enough of each web language to implement our prototype.

Design Evolution

Paper Prototyping

Our initial paper prototype was designed to meet the needs of Ted the Tourist, our persona who has no experience using the MBTA. We hypothesized that if our prototype was simple enough for Ted to use, then it could easily be used by all our other personas.

During usability testing with our paper prototype, we discovered that our design was not meeting the needs of Chris the Commuter. Because Ted and Chris have completely disjoint needs when it comes to their interactions with the MBTA kiosk, we realized we had to change our design to accommodate the unique needs of regular users.

This insight led us to design a new paper prototype which incorporates a customized main menu. We drew upon our user research to determine what menu options each user group will see. The new prototype was not a replacement for our initial prototype; rather, it built on top of it by adding the main menu and ways to purchase fare without searching for directions first.

Heuristic Evaluation

After creating our first software prototype, we received a heuristic evaluation of our design by a group of four classmates. We received insightful, ranked feedback which allowed us to identify priorities in refining our design.

One feature we implemented after receiving heuristic evaluation feedback was a Cancel button on each main menu screen. After designing our customized, user group-specific main menus during paper prototyping, we wrongly assumed users would be able to get to the right menu based on their initial interaction with the kiosk. We had designed the interface so that new users would touch the screen to start while regular users would start by tapping their CharlieCards. This is how we were able to offer a customized menu for each type of user. Through the heuristic evaluation, we realized there was not a clear way to switch menus. This posed a problem for regular users who may have accidently tapped the screen to start but realized they should have tapped their CharlieCard.

By adding a Cancel button to each customized menu screen, we resolved this problem by enabling users to easily return to the kiosk start page. Without the heuristic evaluation, we would have not thought to include this feature because we never included tasks to switch between the customized menus in our usability testing.

Another change we made based on the heuristic evaluation was modifying the main menu option images. While this was a change that we had already discussed making, the fact that it was included in the heuristic evaluation helped us confirm it was necessary to change the images so that each button looked more distinct. This would enable users to find the option they are looking for quicker.

For a full list of the heuristic evaluation feedback that we received, please see our Heuristic Evaluation Response. This PDF includes the feedback we received as well as our response to the feedback.

Usability Experiments

We conducted two usability experiments to help us decide whether to implement specific changes to our prototype. Please view our Experiment Design and our Experiment Results for a complete description of our usability experiments.

Designing for Impact within Limits

We chose this project because it was an interesting design challenge and because the MBTA kiosks impact a lot of people. Over 1 million people use the MBTA system daily. However, by choosing to redesign an existing system, we had to operate within several design limitations.

Disjoint User Groups: Having a large user base means that making one person happy makes another unhappy. It took our paper prototype testing to realize we were designing for two very different user groups. It was challenging to design for disjoint user groups, but we ultimzately solved the problem through customization.

Established Standards: The current MBTA system has already in use for several years. People have established conceptual models for how things are supposed to work and users have become accustomed to both the awesome and terrible aspects of the current kiosk interface. For major changes, our design would not only need to be user friendly, but it would need to change the perceptions created by the existing system.

Finite Scope: We chose to focus on the kiosk software interface, but the whole MBTA system has room for improvement. No one knows what a validation machine is and how to use it. There may be no reason to have both a CharlieTicket and CharlieCard if they are practically the same thing. We could not attempt solutions to all of these issues in one semester so we chose to limit ourselves to the software interface, but several aspects of our interface could be simplified by small changes in the system. For example, just making bus and subway prices the same and simplifying the cost structure would eliminated the need for several screens in our interface.

Final Presentation

.