This chapter is from the book
This chapter is from the book
This chapter is from the book
Step 3: How?
Now that we know who our users are and what they need to do, we’ll start addressing how they can do it. We’ll use Balsamiq to make some quick mockups based on our initial research, show them to users, and get feedback. We won’t spend any time at all making them pretty. As I’ve said throughout this book, the key point at this stage is to iterate quickly. Polishing the cannonball is counterproductive.
The operation that users do most often is to check schedules, both promised and actual. Four or five times per day is not unusual. The more the users perceive that the schedule is likely to change, the more frequently they’ll check it. So the more critical this piece is, the more critical it becomes. It’s important to get it right.
The next most common thing users do is to display a ticket to the conductor. Buying is less common. Claire sets it up once in her life and the pass continues forever. Charlie does it on days he takes the train in, usually buying a round-trip, which means he does this just once per day.
We want to minimize the number of touches that the user has to make. The original MBTA app does not do that, and it never seems to have occurred to its developers that they should try. Let’s take the app’s knowledge of the repetitive patterns of most commuter rail users and leverage it to the max.
I made my best initial guesses based on what my live users had told me, and on what Claire and Charlie said when they disturbed my dreams at night. Figure 8.9 shows my first mockups.
)
Figure 8.9 Two ideas for our first iteration of the MBTA mobile app.
I started by trying to fit everything onto just one page. In direct contrast to the MBTA app where the home page does nothing at all, this home page does everything. We don’t need any navigation because we never have to go anywhere else for schedules or alerts or ticket display. Purchasing a ticket or pass requires another screen, for which we provide a button, but as I said before, this is much less common.
The first thing we see at the top is a line of three radio buttons. Users check schedules at three main times during the day: in the morning before they head out from home to the station, in the afternoon before they head out from work to the station, and in the evening at home, to see what’s up for the next day. So perhaps two times out of three they want to see the current day’s schedule, but in the evening they want to see the next day’s schedule. The app automatically figures out which one to show, based on the time of day and the user’s cell-level location. (That’s precise enough for our needs and draws no extra power.) The selected radio button displays the current choice. If the user sees yesterday and needs today, or vice versa, she just taps the radio button that she wants. If she needs to see another day, perhaps on the weekend to go into town for a show, picking “Another Day” brings up a date picker to specify that date.
Next, we see the inbound and outbound trains. Here’s the key improvement over the original app: because the app knows the ticket that the user bought, it knows which trains and which times to show. Claire bought a pass originating in Salem. Charlie’s tickets originated in Ipswich. Both specified North Station as their destination. The app uses this knowledge to populate the labels above the list boxes and the train times within them, with the next available train at the top. Each station has a link to change it if needed. That feature likely will not get used much, but telemetry (next section) will tell us if we’re wrong.
I tried two different approaches to displaying the train times. Figure 8.9a uses list boxes, displaying the train times in a vertical arrangement that the user is probably familiar with. In Figure 8.9b, I saved space by putting train times in a horizontal line. The app automatically places the next available train as the first in the list. Either scroll bars or horizontal arrows indicate to the user that she can scroll them if she needs to see more trains than fit in that space.
The app doesn’t show the trains’ arrival times. I figured most commuters probably wouldn’t care. They know approximately how long their train ride takes and can therefore easily extrapolate. Plus, arrival time is often affected by factors beyond the rider’s control, so it doesn’t much matter what the schedule says. If needed, we could make train arrival information accessible with a tap on a particular train. I wonder how many users would say they need that.
Below the train displays is a text box. This carries a countdown clock, showing the time to the next train inbound (if the user is in the suburbs) or outbound (if the user is in the city). The users won’t have to do mental subtraction to see if they can make that train. This text box also shows any alerts pertaining to this line or their station. Users won’t have to tap down three levels to find out if there’s anything they care about.
Below all this is the monthly pass or ticket display. Claire’s automatically updates every day to show the correct color for validity. Charlie will have to explicitly activate one, using a button (not shown).
The main drawback with this layout is that it’s a little bit cramped. Ideally it won’t bother our user population much. In a reader app that they’d use for half an hour or more at a time, that would be a deal breaker, but they’ll look at this app for no more than ten or 20 seconds at a pop. The main criterion was for users to be able to pick out immediately the data that they need. I carefully selected everything users needed (or so I thought), and nothing that they didn’t (ditto).
The point is not that this layout is perfect, or even very good. This is my first draft. The point is that it didn’t take long to dummy up these layouts and try them on actual users, to see what they liked and what they didn’t like. To that trial we now turn our attention.