PROJECT TYPE: Designing for usability
PROJECT GOAL: Redesign the software interface of the BART ticket kiosks, working with the constraint of the existing hardware.
TIME FRAME: 3 weeks
COLLABORATOR: Lili Ishida
Although there are several different versions of the BART kiosks, some that take only debit, some that take only cash, some that only purchase new Clipper cards, we based all our designs off of a ‘universal’ version, one that takes cash, credit, debit, and can be used to buy a new Clipper card as well as standard BART tickets.
Problem: The existing BART ticketing kiosks are confusing to many riders, particularly new users. There are many pain-points of the entire BART transit system, not all of which can be alleviated through a software update to the ticket kiosks. However, providing a more straight-forward and informative ticket-purchasing journey would go a long way to helping people navigate the BART stations.
Research and discovery: Lili and I observed and interacted with BART riders and ticket-buyers to understand their pain-points and understand the good and bad aspects of the machines.
Frequent riders familiar with the kiosks told us they didn’t have a problem with the machine, but when we inquired about specific tasks, they often reflected and said things like, “oh yeah, doing that is difficult” and “it is pretty slow”. New riders were particularly confused by the difference between Clipper cards and tickets, and even when they completed their goal of purchasing a ticket, were often not confident at the end of the interaction.
Some riders walked away from the machine after inserting cash or credit card, not realizing their Clipper card had not been updated. One woman I observed had her cash taken by the next man in line, because she hadn’t completed the process by properly tapping her Clipper to the scanner.
We developed several personas from this research, sketched out a map of the whole system, and drew key task flows (including buying a new ticket, adding value to a ticket, adding value to a Clipper card, and adding value to a Clipper without enough fare to exit the station). You can read more details on this process in my first blog post on the topic.
The biggest usability issues we discovered from observing and interacting with ticket-buyers were these:
- language—too technical, e.g. “upgrade,” “e-purse” etc, not consistent
- add/subtract value—very slow, $1, 5¢ at a time
- feedback to confirm Clipper refill—none
- screen hierarchy—not consistent, doesn’t highlight most important pieces of info
Design: We used three primary user personas, and their pain-points and needs, to inform how we tackled each of these issues. You can read in more detail about these steps in my earlier blog post.
In developing new task flows, we struggled with the order of the payment and value-setting steps. We wanted the order to be consistent across all tasks, although paying with cash or with a credit card have different pain-points that can be addressed by have a different moment of payment. Initially we settled on having payment at the beginning of the process, as you can read in our last blog post. However, we were not confident in this decision when refining our flows, so we decided to go find out what people’s mental model of a ticket-purchasing experience looked like.
We set up a card-sort of the different basic steps of the ticket purchasing process, and asked a total of eight people (approached randomly on campus late one evening) to order them in a way that made sense to them, using as many or as few of the cards as they liked. We then asked them for feedback—how familiar were they with the BART kiosks, why did they choose this order, were there any cards missing from their options.
Overall, our test subjects were extraordinarily consistent, all but one putting payment at the end of the of the process. These results encouraged us to put the payment step after selecting the value, and we adjusted our flows accordingly.
We made several iterations of our flows and versions of our wireframes, to understand how best to display content and directions, and to find an efficient number of steps without overloading the screens with information. One major difficulty of using the current kiosks is that there is too much information posted on the outside of the kiosk, making it nearly impossible to find and process the relevant pieces. We wanted to eliminate this busyness from our screens, and funnel people into the appropriate flows early on.
We drew low-fidelity versions of our screens, built a paper prototype of the machine, and went off to do usability tests! Our tests were primarily focused on validating our task flows as well as the language and content on each screen, rather than validating the nitty-gritty of our UI. We did get feedback on the basic layout and the hierarchy of information, but chose to do paper prototypes to avoid focusing on visual design (as well as because of time and technology constrains of putting together a digital prototype).
Usability testing: Because many BART riders are in a hurry, and because out prototype needed a flat surface to sit on, we went to Dolores Park near the 16th St Mission BART station to find out usability test subjects. We also chose this park because we knew there would be a mixture of both locals and out-of-towners, who would have various levels of experience using the current BART kiosks.
We tested our three primary flows at least four times each, on a mix of new and frequent BART riders:
- Adding $10 to a Clipper card with a credit card
- Buying a new ticket for $8.75 with cash
- Choosing to quick-load $20 onto a Clipper card
We also tested an additional ‘expert user’ level flow on one expert-rider, which consists of approaching the machine and immediately inserting a credit card. This flow restricts the ability to change the value of a ticket or Clipper, and only provides options to pay $20. The point of this additional flow is extreme speed and efficiency for certain frequent users, meeting the needs of one of our personas.
We received some excellent feedback from these tests. We learned that brand-new or very infrequent Clipper users don’t always know to tap their Clipper card on the sensor (which is not centrally located on the current machines). Although we cannot change the location of this sensor, this gave us the idea to include a graphic or icon on our home screen indicating where/how to scan the Clipper card.
On the second screen that prompts users to either quick-add $20 or to set their value, many users thought the ‘set value’ text was a button, although it was originally not. Testers recommended that although this is an extra step, it’s less confusing for users to be able to push that button. We decided to make this a button that proceeds to the ‘set value’ screen, although beginning to type on the keypad will also bring up this screen, as before. To account for this change, we added directions to our ‘set value’ screen to use the keypad to enter value, as those users who pressed the button usually had read the directions less carefully and didn’t always know how to complete the next step.
We received feedback that the line displaying current ticket/Clipper value was not prominent enough. We decided to make this line more obvious on the first screen that the current value appears. Based on some slowness in scanning the home screen, we also decided to make the directions “tap Clipper or insert ticket to add value” more prominent.
We did not receive any feedback or observe any behavior that indicated we needed to revise the order of our screens. Overwhelmingly, people were pleased with the process and felt positively at the end of their task (based on verbal as well as physical responses). Several of those familiar with the current kiosks commented that using our prototype was much better, and overall they felt each step was very clear, and were not confused by the choices available to them at any point.
One woman who tested our prototype told us that she was very interested in this topic, and has used and studied different transit machines around the world. At the beginning of her task, she told us her experience with transit passes in many places made her want to tap her Clipper as the first step, to narrow down the options available for her. This was good validation of our flows, which aim to funnel people as early as possible, and to reduce the possibilities available at each step.
One thing we noticed in our testing was that despite being instructed to add specific amounts to their ticket or Clipper ($10 or $8.75), almost every user wanted to quick-add $20 when they saw this option available. We began to emphasize the value they were meant to pay, and some repeated the instructions back to us, but this did not seem to affect behavior. However, those paying with cash were only given two five-dollar-bills, and did not have more cash. This actually allowed us to test variations of our primary flows, with the ‘back’ and ‘edit value’ screens in play. We found we were missing a version of one screen to account for these backtracks, and drew it up on the spot.
One visit from Britain who tested our screens for us provided his own feedback sounds from the keypad and ticket dispenser! After this we provided some feedback sounds ourselves for these functions. One aspect of our redesign not obvious in the paper prototype is audio feedback from the Clipper sensor when you update your card, as well as a flashing of the screen for visual feedback. These would help prevent users from walking away from the machines without completing transactions. One person who tested for us noted that she would want to credit card slot and the other pieces of hardware like the Clipper sensor to flash lights when it was time to use them, to guide her to exactly the right spot without having to hunt for it. This was excellent feedback that we would definitely incorporate if we were including kiosk hardware update in our redesign.
Further steps: Our next steps on this project would be to flesh out our style and language guide. We would like to test both a more developed visual UI and specific questions we had about language, such using both ‘balance’ and ‘value’ (value being the amount of payment to add, balance being the amount already on the card).
Foundations of Interaction Design 