This chapter is from the book
This chapter is from the book
This chapter is from the book
Current State of the Art
The MBTA already has a mobile app for buying tickets. The T made a great fuss over its introduction in late 2012, as the first such app in the nation. When we start examining it, we see that it doesn’t help our users solve their own problems anywhere near as well as it could and should.
The home screen (Figure 8.1) is terrible. Most of its area is wasted. The top third shows what some graphic designer probably considered a pretty picture. The designers probably think of it as “our branding.” The bottom third is completely blank.
)
Figure 8.1 MBTA mobile app home screen with wasted space and no functionality at all.
We can’t do anything at all on the home screen. We have to leave it to accomplish anything—view a schedule, buy a ticket, see alerts that might affect our commute. They’re squandering the most precious resource in any mobile app, a resource that could have helped us accomplish something that we actually cared about. Instead, they’ve given us a picture, a blank space that sort of balances it visually, and no functionality whatsoever. I suspect it’s the art major’s revenge for all those jokes ending, “Would you like fries with that?”
The purchasing and displaying of a ticket works not too badly, once you navigate to it from the home screen. Figure 8.2 shows the process. We select the stations by typing in the first few letters, and auto-complete (good) narrows the list. The app retains our most recent selection at the top of the list (also good), because almost everyone on commuter rail uses the same stations repeatedly (Figure 8.2a). We type in our credit card number, which it also remembers for the next time (also good), and the transaction is consummated (Figure 8.2b). When we’re ready to ride, we tap a button to activate the ticket. It then flashes the color code of the day so the conductor knows it’s valid. It also has a button that shows a bar code for readers that conductors might someday start carrying (Figure 8.2c).
)
Figure 8.2 MBTA mobile app ticket purchase—not too bad.
Because it works not too badly once you get to it, we won’t discuss the ticket purchase portion of this app very much. However, even with all the data it remembers, we still have to type in our credit card CVV number every time. This app is most commonly used by occasional riders, who will not have that memorized—monthly pass buyers with auto-renewal don’t need it. Occasional users now have to juggle their phones and wallets and credit cards in a crowded public place, which is uncomfortable, or think ahead, which no human in the universe ever does about anything. Adding an Instant Purchase button for each recent trip at the top of Figure 8.2a, similar to Amazon’s 1-Click purchase, would smooth this out even more, especially since commuters almost always travel the same route.
The app fails miserably at the greater need of commuter rail riders: accurate and timely schedule information. Again, the home screen contains no information whatsoever about schedules. If we want to see a schedule, we have to go through three steps: tapping Schedules on the home page, which then takes us to a screen where we are offered the choice between Schedules and Alerts (Figure 8.3a). The app is saying, “I know you selected Schedules, but did you really want Schedules?” After tapping Schedules again, we have to choose the line for which we want the schedule (Figure 8.3b). Only then will it show us a schedule in an ugly format that is very hard to read (Figure 8.3c).
)
Figure 8.3 Schedules are difficult to find, then difficult to read once we’ve found them.
Alerts, whatever they might be, do not appear as an option on the home page. We have to somehow intuit their existence and go digging—tap Schedules, then tap Alerts (Figure 8.3a), then look at our line to see if it has any (Figure 8.4a). The green check mark would seem to indicate that everything is OK, but despite this indicator, the Lowell line has one Upcoming alert and one Ongoing alert. (What the hell is the difference between Upcoming and Ongoing? I can’t tell, and when I look at the contents of each, they appear to be identical.)
)
Figure 8.4 We have to select the alert for our line.
If something is important enough to be called an alert (“an alarm or other signal of danger”), it surely shouldn’t be buried four screens deep, should it? And isn’t an “ongoing alert” a contradiction in terms? Once we look at the alert, we can see that it often impacts the schedule; note the two canceled trains (Figure 8.4b). Burying this information four levels deep ensures that no one will ever see it—exactly the opposite of what alerts are for.
The developers of the schedule portion of this app did not apply the skills that they (sort of) demonstrated in the ticket purchase portion. They didn’t work from the users’ perspective. They just took their paper schedules and tossed them into an app, with the awful results you would expect from such an unthinking approach.
The user has to do far more work than she should have to. The app doesn’t make use of the knowledge it has about the user, or about the repetitive nature of the commuter rail relationship. The developers are saying, “Hey, it’s your job to do all this work.” Maybe that attitude was acceptable a decade ago, but it sure isn’t today. If a student of mine turned in something like this, I’d flunk him so fast he’d switch his major to English.
We can do a whole lot better by following the Platt UX Protocol, putting ourselves in the users’ shoes. Once we think about who the users really are and what these users actually need, we can select the items of information most relevant to them, here and now, and present them clearly and easily. That will turn this commuter rail app from a brick into an indispensable everyday aid.