This chapter is from the book
This chapter is from the book
This chapter is from the book
Step 7: Make It Just Work
Now that we’ve worked out our designs for this project, let’s go back and review them against the commandments that I gave you in Chapter 7. We’re trying make this app just work. How are we doing?
Start with Good Defaults
This is probably the biggest improvement that we’ve made from the original app. Instead of throwing all the documentation for the entire commuter rail network at the user, and forcing her to strain out the pieces she cares about, our app automatically deduces the pieces that she cares about. We generate her default stations from her ticket purchases, and her current location from cell-level positioning. We show them to her front and center.
Remember Everything That You Should
We do this very well in this app. The most important item that we remember is the user’s usual commuting route—the stations that he goes to and from. We use that information to determine the schedules to show him, and the time to the next train.
Speak Your Users’ Language
We are careful to speak our users’ language at all times. Probably the biggest decision I made in relation to this was omitting the train number from the schedule grid view. Certainly the T uses train numbers internally, as airlines do. But riders, according to their interviews, never, ever think in terms of those. They always think in terms of the time: “Damn, missed the 6:20 and they canceled the 6:50; the next one goes at 7:14.”
Don’t Make Users Do Your Work
The original app made our users do a lot of work to find and then read the information they needed. This app automatically figures out what the user wants and then shows it to her. She’s doing a whole lot less work than she used to do, as close as we can get to no work at all. Even the tabs that we show are carefully selected—the outbound trains if she’s in town, the inbound trains if not. We’ve done this well.
Don’t Let Edge Cases Dictate the Mainstream
The main case of the rail commuter is making the same trip over and over, day after day. This app is highly optimized for that case. If he wants something else, like “Hey, if I take the train in for the Bruins game on Saturday, when are the trains?” there’s a link for it, but he’ll have to do some work. A rail fan whose hobby is riding every line to every station will have to do much more work. We have carefully optimized for the main case.
Don’t Make the User Think
This app’s biggest de-thinker is the countdown timer. It shows the time until the next train, so you don’t have to look at the schedule, look at the clock, and do math. It shows you the track number so you can go directly there. This app requires as little thinking as I could possibly make it.
Don’t Confirm
We don’t have any confirmation in this app. This app doesn’t do anything that would require it.
Do Undo
The scheduling portion of the app doesn’t have anything that we could undo. In the ticket purchase portion, perhaps we could allow return of purchased tickets. But the T doesn’t refund paper tickets, so electronic tickets won’t get refunded either.
Have the Correct Configurability
This app automatically detects the stations that the user travels to and from. If for some reason our automatic detection is wrong, or the user changes her pattern, we provide a link by which she can make changes. We also provide a link if she wants to look at other times. Nothing else is configurable. That’s a good place to start for this app. We may gain a little more configurability in the future, such as the choice of putting the tabs at the top or bottom of the screen.
Lead the Witness
This app leads the witness in everything—automatically detecting which stations we use, which trains we ride, automatically showing us when the next one leaves. Compare it to the original app where the user has to dig for every last scrap. This is a damn good app, if I do say so myself. Which I do, because it is.