Reading Time: 12 minutes

When I was a small child, my mother volunteered at a used bookstore. There she would buy me reams upon reams of back issues of Highlights. 

Every issue of the children’s magazine contained a strip of Goofus and Gallant, a comic that compared a well-mannered child named Gallant with a rude one named Goofus. Here are three examples of the Goofus and Gallant comics.

The definition of “good manners” is subjective. So is the definition of “good UX design.”  That said, most would agree that the example set by Gallant embodies “good manners” better than the example set by Goofus.

Today we’ll look at two different apps—the Uber app for passengers and the Wodify app for Crossfit athletes—and examine the choices that users are expected to make as they use those apps.

Collectively, these choices make one of the apps decidedly easier to use than the other. As we explore the choices made by the UX designers of these two apps, we’ll see examples of how to make those same choices for your apps.

Let’s do Uber first:

When I open the Uber app, this is the very first screen that I see. The screen tells me where I am, and it also tells me how long I can expect to wait for a car to come get me. That second piece of information is the main piece of information I need to decide whether to call an Uber.

The first piece of information I only need to confirm an assumption that the app is making: I want to be picked up where I am located. The vast majority of the time, this assumption is correct, which is fantastic: that’s one thing I don’t have to tell the app before I can use it. On the rare occasion that that assumption is wrong (say I want to call a car to pick up my friend at his house), I can easily change the pickup location by clicking on the address bar at the top and typing in the new address (for which the app will give me options for autocompletion).

If I want to call a car, I tap the black button that says “set pickup location.” It sets my pickup location to the location shown on the map underneath it.

This is fantastic. The Uber app experience has been whittled down to a single page that provides only the information I care about to make a decision and gives only the options for action that I’m most likely to want to make at this point.

The only exception to the single page experience is this pop-up, which appears when rates are elevated due to high demand for cars:

If I tap “notify me when surge drops,” the app will text me if the fares decrease in the next 30 minutes. If I tap “I accept higher fare,” then my car gets called anyway.

Here’s the confirmation page. I press “request,” and I’m done. All I have to do is wait for the car—and once a driver accepts the ride, the app will show me exactly where the driver is and how long I can expect to wait for that specific car to arrive.

The designers of this app used choices judiciously. They figured out which choices a user cared about most of the time, and they hid all the other choices (like changing my payment method) in a menu. So I get a streamlined workflow: nothing gets between me and the task I want to accomplish of calling a car.

Now, let’s look at Wodify:

Here we see the results page of the Wodify app. This is where I would go if I wanted to see how my performance stacked up against the performance of other people at my gym on a particular workout. the workout shown here gives the women’s results for the workout on June 19, 2015.

See how the header says “Granite Games 15.1?” If there is a “Granite Games 15.2,” I can’t see the results of both on the same screen. I have to click on a second header labeled “Granite Games 15.2,” which, based on the wait time, I’m going to guess makes another call to fetch results for the second part of the workout.

So what if I want to see the workout itself? I click on the “WOD” button at the top of the screen (“WOD” stands for “workout of the day”).

Another call gets made. (All the calls take 5+ seconds. This might be why the developers split the app into so many screens—so one screen doesn’t wait for three separate slow calls to load before the user sees anything. We can ameliorate those situations more gracefully with asynchronous calls, “Loading” labels, and placeholder shapes).

Let’s see the WOD:

Here we are on the WOD page. The “Results” button at the top has disappeared. If I want to go back and see the results, I have to click the hamburger menu.

Yes, the menu opens on the right instead of on the left, and it pushes the main screen aside as opposed to opening over it. This breaks iPhone UI conventions, but we’re not going to beat that to death. Let’s focus only on the choices a user has to make to get what they want inside this app.

To get back to the results, I have to click on “Whiteboard.”

1. I would have recommended that the button be called “Results” since a) that’s more obvious where a user is going and b) that’s the label on the other button that takes a user to results. As an alternative, maybe both buttons could have been labeled “Whiteboard.” The fact that they’re labeled differently is confusing.

2. I have never tapped on “Add Results,” “Performance History,” “Nutrition Journal,” or “WodiFind” because I do not use these features. I have tapped on”Settings” one time (to change my payment method), and I have tapped on “Class Schedule” once when I was first starting out to find out when I could go to class. I have never tapped on “Today’s WOD” because that option is always available without going to the menu. So here I would prefer if:

• “Today’s WOD” were removed from the menu
• “Whiteboard” were removed from the menu and made always available without going to the menu. “Today’s WOD” is already like this. “Today’s WOD” is one of the two things I go to regularly. The whiteboard is the other one. If I am representative of most users, then those two things should be reachable without the menu—and therefore not on the menu.
• “Add Results,” “Performance History,” “Nutrition Journal,” and “WodiFind” were removed from the menu. That said, I could be an atypical user. Maybe everyone else uses that stuff. If they do use those things, keep them on the menu.

“Class Schedule,” “Settings,” and “Logout” can stay, too. The menu is a good place for these options: options a user wants every once in a while, but doesn’t need for most of the time that they use the app.

There’s another glitch in looking at workouts, though. The “Program” option adds a barrier:

I’m not exactly sure what the “Program” setting is supposed to represent, but I have learned the following during my time using the app: to see the workout, I have to set the “Program” to Crossfit on Monday-Friday. On Saturday, I have to set it to “S WOD” or “Team WOD.” To select this, I have to use a spinner:

This is unfortunate because the app can know which program to select: Crossfit during the week, and “S WOD” or “Team WOD” on the weekend (it’s usually just one of the two). On most days (all days with exactly one exception since I started using the app five months ago), only one program has a workout. That program could be automatically selected for a given day, so I don’t switch dates from June 19 (a Friday) to June 20 (a Saturday) and get a “NO WOD FOUND.” This message that makes me think there’s no workout for that day, when really I just have to change my Program settings to see it.

I have too many options here. I only care about one thing: I want to see my workout. I don’t care to select from multiple programs. Again, I could be atypical: maybe a larger gym has multiple workouts for multiple different programs. But for a gym with one program (which is most Crossfit gyms), this information can be figured out—the user does not need to be asked for it.

Wodify opted to ask the user to make almost all of the choices about which information to display. This gives the user lots of freedom, but it’s not freedom that I appreciate. I spoke to a couple of other Wodify users (not exhaustive user testing, I know), and they confirmed that they, too, mostly do two things in the app: look at the workout and look at the results. Sometimes they navigate to different days in the app, but most of the time:

1. If they are looking at the app before they have completed the workout for the day, they want to see the workout for that day.
2. If they are looking at the app after they have completed the workout for the day, they want to see the results for that day.

Because the user is logged in, the app knows whether they have completed the workout for that day or not. So a more streamlined design would show them, upon opening the app, the workout (if they have not done it) or the results (if they have done it).

Two buttons at the top for “WOD” and “Results,” plus a spinner for the date, would make the user experience click-free most of the time, and one or two clicks (to switch the date or the WOD/Results view) almost all of the rest of the time.

Maybe the results page would even let me scroll to see the results from each part of a multi-part workout. That way, the backend would still have that data separated so coaches can go in later and look at people’s performance on individual lifts, but I can see everything all in one place.

Perhaps the Wodify user base is not yet large enough for these UX choices to “matter” (with matter here defined as affect the revenue stream of Wodify). Maybe the app is still in an early iteration. I’m not making normative judgments on the app, the business, the designers, or the developers. The app at present, however, offers an excellent case study demonstrating what happens when an app’s design passes all the choices to the user, instead of making smart choices on the user’s behalf.

When UX designers make choices on a user’s behalf that are correct most of the time—and easy to adjust when they’re not correct—the app becomes easier to use. An easier-to-use app makes users happier.

This is precisely the reason that the Uber app is so easy to use: it makes assumptions about what I want to do that are, with a very rare exception, correct. In those exceptional cases, I can change my request from the assumed request to a customized one in just a couple of taps. The Wodify app, on the other hand, has yet to determine what its users want to do. So instead of optimizing for that want, it app forces me to navigate through all of the possibilities.

The Uber app also gives me easy access to all the information that I need in order to use it. When I open the app, I have to wait a few seconds for the first page to load. However, that page shows me my location, my wait time, and the clickables that I need to change my pickup location or call the car. I don’t have to click around to get to the car-calling option, which is what I want most of the time when I open the app. The Wodify app instead puts each individual call on a separate screen. So I have to tap, tap, wait…not just when the app loads, but each time I want to switch between WOD and results, or between different sections of the results. So Uber’s UI enables me to quickly make the decisions I want to make, and Wodify’s UI gets in my way as I try to make the decisions I want to make.

Uber’s app provides a streamlined user experience and Wodify’s does not because Uber has done three things:

1. It has figured out exactly what most people use the app to do.

2. It has minimized the amount of time and effort that it takes a user to do that thing.

3. It has hidden away all the other things a user might use the app to do.

Starting the UX design process with those three steps allows a designer to curate the choices a user will be asked to make. Those choices, more than the visual details of the app, determine the quality of the overall user experience.