I observed how people use and interact with technology at a Capital Bikeshare Station in the Washington Metropolitan area. I defined two broad tasks for my observation — check out a bike and return a bike.
- Understand how users perform a well-defined task using technology via in-site observation
- Reflect on what makes a technology easy or hard to use
Silver Spring, Maryland — a city just north of Washington, D.C. The station observed was located just outside of downtown Silver Spring in a residential neighborhood, adjacent to an apartment complex. I observed the station on a Saturday morning in February at about 9 a.m.
Task 1: Check out a bike
- At the station kiosk, press “Rent a bike” on the touchscreen interface.
- Make a payment by swiping your credit card.
- Enter the phone number associated with your card, then enter your zip code.
- Accept the usage fees and select a membership, then continue following the directions on the screen to pick the number of bikes you would like to rent. Enter a gift certificate if you have one, review your rental information and confirm your age.
- Optional: print receipt and access code. Grab the receipts that print from the kiosk.
- Walk to one of the station docks with an available bike. Type in the access code on the interface appearing on the left side of the dock.
- When the green light turns on, grab the bike by the handles and pull it out of the dock.
Task 2: Return a bike
- Walk your bike up to any of the open station docks.
- Push the front wheel firmly into the dock and wait for the green light to turn on.
- Pull on the bike to ensure it’s locked into the dock.
In 30 minutes, I observed two women in their early 20s and one man in his 30s. The man had a Bikeshare key, so he skipped through all of the interface screen interactions I’d hoped to see. But the two women had to use their credit cards to purchase their membership.
A bench just a few feet from the station was perfectly located for observing user interactions without interference. The three users checked out their bikes and left, and after waiting around for another few minutes, I decided to try the process myself. I was also curious to know how easy it was to return the bike — did it lock in as easily as it looked?
The kiosk was organized so that information about the cost was at the top. Information about taking a trip for the first time and returning the bike surrounded a touch screen interface. The kiosk also labeled parts of the interface with numbers so users could work their way down the box as they selected their membership type, inserted their credit card and received a receipt and access code. Yellow text and highlighting helped guide a user’s eyes down the kiosk, and notes such as “No Place to Park?” anticipated potential user questions. Such organization and consideration for the user helps to achieve task goals.
However, in both cases where users had to purchase a membership, it often took several attempts for the user to correctly push the buttons on screen to advance the system. They tended to push a button once, wait a second to receive a response from the screen, then press it again. When I tried it, I noticed that the screen was slow to respond to touch. It took me 49 seconds to enter my phone number because the screen kept failing to register my click. Sometimes, it registered the click twice. The numbers also felt too close together, and as a result, I pushed an incorrect number several times. I ranked this barrier as a medium- to high-level of severity. This was just one of nearly a dozen screens, and I felt slowed down by the poor touch screen reactions. Frankly, it was frustrating. This issue could be resolved by using tactile buttons (Aside: this does, of course, present other concerns — the benefit of using a completely touch screen interface is that one could update the software at a later date and change the look of the interface. A tactile interface is more limited, and fixing that layout would be more costly).
A second barrier of medium severity was the receipt. I hit print and received a membership receipt. I spent at least a minute scanning the paper for an access code. It wasn’t there. I looked at the kiosk again to see if the screen listed the access code, but it had already cleared out my information. Finally, I noticed a second receipt in the kiosk. That one had the code. When I was writing up my field notes later at the bench, I noticed another user run into the same issue. While the double receipt didn’t prevent me from entirely checking out a bike, it was rather inconvenient. This issue could be resolved by adding a note on the screen that states the machine is printing two receipts or by printing everything on one receipt.
No users seemed to run into any issues with inputting the access code and pulling out a bike. For returning the bike, the directions were simple — push the bike into the dock and wait for it to click. The actual the action took longer than expected. I rolled the front wheel into an open dock, then looked for a green light to turn on. Nothing happened. After wiggling the front wheel around inside the dock and pulling the bike back, I tried again and pushed harder. The green light went on. To double-check that the task had been completed, I pulled the bike backward, and it stayed secure in the dock. While returning the bike took longer than anticipated, I don’t believe this task would prevent anyone from using the service again. It just takes more of a forceful push than a gentle roll to lock the bike into the dock.
Three colored lights explained the system interactions of the dock. One blinked yellow when the user typed in his or her code, and then it lit up green when the bike was ready to be checked out or firmly secure in its dock. The system also considered the needs of color blind people who might not be able to tell apart the colors because it had icons above the lights: a “no” symbol above the red light, a clock above the yellow light and a check mark above the green light.
Outside of the two main tasks, I found a minor issue with station layout: The station had a large map, which would have been useful if a bike dock didn’t block the bottom half of the poster. When a bike was docked in that spot, it was impossible to view the map up close. I rated this issue as low, since it was more of a nuisance than an error that would totally prevent users from checking out bikes. Still, it’s an issue that could be addressed by moving the sign just a foot or two farther away from the dock.
Use tactile buttons with audio and visual feedback instead of a touch screen. Tactile buttons give users a quicker sense of whether or not the button was correctly pushed, and an audio signal like a beep would enhance further enhance that. The downside, as I mentioned earlier, is that interface updates are more limited if you’re constrained by the number, location and functionality of such buttons.
Alternatively, Capital Bikeshare could retain some aspects of the touch screen interface for larger buttons like the initial “Rent a bike” screen and add a row of tactile buttons so the user could more quickly enter information like a phone number and zip code.
The first idea above shows a traditional number pad similar to one you would find on a telephone, and the second option shows the numbers listed in a row in increasing order. Other tactile buttons would include “ok” and “cancel” buttons, as well as left/right arrows to advance or return to a previous page. These buttons would prevent errors caused by a touch screen incorrectly reading a user’s finger placement. In both of these interfaces,the “ok” button would need to be quickly distinguishable from the “cancel” button to prevent errors — an issue that could be solved by making the button shapes, sizes or colors different. The “ok” button could be green and include a checkmark icon, while the “cancel” button could be red and have a no symbol (the circle-backslash symbol) on it. These icons would match the look of the icons above the dock lights and would benefit users with color blindness.
While observing the Silver Spring station, I didn’t see any users start the rental process and walk away without taking a bike. Clearly, the interface issues I noticed weren’t too major because no one was unsuccessful. But inconveniences such as a poorly responsive touch screen interface significantly slow down the time it takes to click “rent a bike” and receive a code to access the bike. Further studies could help determine if physical buttons next to the screen would improve the speed of this process.