I’ll readily admit don’t ride the bus much. I much prefer point-to-point transportation, such as riding my bicycle. But occasionally I need to go to Denver for an event, and rather jump in my car and add to that single occupancy vehicle traffic jam known as the Boulder-Denver turnpike, a few months ago I thought I’d take try to take the bus.
There’s a nifty new web service called NextBus.com that offers realtime estimates of when the next bus will arrive for my local bus service provider, RTD. You just point your browser to the appropriate web page for your route and direction of travel, and bingo, an estimate of what time a bus will be at your stop. It’s even accessible from a cell phone browser. Great idea, right? But poorly designed.
You can see from this screenshot that the NextBus service lists “Broadway at Ash Avenue” as a bus stop for the BX route (the Boulder-Denver express). But when I went to that bus “stop”, I watched a BX bus pass me by despite my attempts to flag it down. If a bus rider can’t figure out where to catch the bus, what good is a web service that tells you when it arrives there?
After an annoyed set of emails to RTD and NextBus about the matter, I discovered that “Broadway and Ash Ave” is not actually a bus stop for the BX or even the BL (Boulder-Denver Local) route, but only for other routes such as the Skip or AB. Apparently NextBus’s service only lists the time when the BX or BL bus passes a particular GPS location–not whether it is actually a bus stop for that particular route. So why is it listed as a bus stop on the BX/BL routes on NextBus?
The answer is poor design, particularly with respect to the interaction between the underlying information architecture and the user experience. One component of good user interface design is making sure that the information architecture of the system is accurate, and NextBus failed that test. Inaccurate information leads to a miserable user experience-such as having the bus you want to take pass you by and leave you stranded. That makes NextBus and RTD co-winners of the second Darwin Design Award for an interaction design that drives end-users nuts. I might have pulled back from giving them the award, but four months and several rounds of emails later they still haven’t bothered to fix the problem.
In fact, several more of the locations listed on the NextBus website “stop” selector are not actually located where the bus stops. So, for example, the stop at Broadway and 27th Way is probably the closest actual bus stop to the “Broadway at Baseline Rd” NextBus “stop”. However even that deduction remains uncertain, because the “Broadway at Service Rd” stop doesn’t even exist. Try googling such a location–or ask a native Boulderite like myself–there is no such intersection. Given that it is between “Broadway and Baseline Rd” and “Broadway at Ash Ave”, perhaps it refers to the old NIST (National Institute of Standards and Technology) entry across from Broadway and 27th Way, but the user is left twisting in the wind wondering how to interpret this nonsense.
There is an important lesson to be learned here, however. Mislabeling the GPS locator stations as “stops” is a great example of the mistake of conflating the user’s point of view and the back-end point of view. NextBus GPS location points are not ontologically equivalent to actual bus stops; they are are approximations which must be mapped. It illustrates how an ontological mistake in the underlying information architecture leads to a poor design that is useless for the end user.
A good interaction designer would pay attention to where the bus actually stops and how the stops are named in the real world of bus riders. Pushing real-time bus arrival information across the web to a browser or cell phone is a great idea. But unfortunately a great idea poorly designed risks dying early, earning the RTD NextBus system a Darwin Design Award.