False Dichotomies

Here’s something I’m noticing quite a lot during design meetings. We’re talking about a specific design detail, and somebody takes a stance. «I think we should hide this button in the header of the table, and only show it when the mouse hovers over the header. Otherwise, we have to add this button to every single column, and it’s going to look cluttered.»

Somebody else disagrees: «I would just show it. Otherwise, people won’t figure out that they can access these sort options, because they won’t hover the mouse over the header.»

Now the other people in the meeting are starting to take sides.

«We should show the button, hiding it is not discoverable.»

«I disagree, I think it’s better to hide it, showing it looks ridiculous.»

Pretty soon, you have two groups of people. At this point, the people inside each group are no longer really listening to the people in the other group. Each group is only reinforcing its own position, and coming up with better and better reasons for why their approach is correct, and the other group’s approach is flawed. Trenches are being dug. The situation slowly escalates.

You’re witnessing the human tendency towards tribalism.

Once you have two groups of people, each advocating for its own position and reinforcing its own beliefs, people seem to start turning off parts of their brains. Things get emotional. Assumptions turn into unquestioned facts. At this point, people are no longer looking for solutions, or for common ground. They’re fighting an adversary.

Tribalism based on superficial, insignificant criteria — the computers or phones we use, the sports teams we like, the clothes we wear, the car brands we drive — is pretty common human behavior, and we fall into it easily.

But if you take a step back, you’ll notice that the whole discussion between these two groups is now based on a fallacious assumption. People have replaced the actual question they’re trying to answer — «how should this UI look and work?» — with a different, misguided question: «which of these two options should we pick?1

This is a false dichotomy.

A few years ago, there was an argument going on in the Apple community about the iPhone’s mute switch. The mute switch only turns off some alerts, not all of them, which sometimes causes the iPhone to sound an alarm even though it is muted. Very quickly, people took sides, some arguing that the iPhone should not make any sounds when it is muted, others pointing out that this would inevitably cause people to accidentally miss important alarms. Eventually, as always happens, people started arguing that, since this dilemma could not be resolved, it should just be a setting, so everybody could make a personal decision as to which failure — accidentally sleeping in, or accidentally interrupting Mahler’s Symphony No. 9 — would be preferable to them.

But again, if you take a step back, you’ll notice that the options presented — mute mutes everything, mute doesn’t mute alarms at all — are not the only two options. For example, if the phone is muted and an alarm is triggered, it could start out by turning on the screen, then, if the user doesn’t react after a few seconds, start buzzing, then slowly increase the volume of the alarm. This would give the phone’s owner time to notice the problem before the New York Philharmonic’s conductor has to stop the performance, but it would still wake up a sleeping person — maybe half a minute later than scheduled, but that’s well within an acceptable range in almost every situation.

In creative endeavors,2 tribal, black and white thinking can be problematic, because it prevents you from noticing all possible options. Whenever the discussion veers from «how can we solve this problem» to «should we pick option A or option B», you need to take a step back, and ask yourself — and your team — if these are really the only two options.

Is there any kind of middle ground?

Are there entirely different approaches we didn’t consider?

Are there valid concerns the other group is raising, and can we take these concerns into account without completely dismissing our own concerns?

Most often, the answer to all of these questions is «yes.» Unfortunately, in the heat of the moment, figuring out that there actually is middle ground is often difficult. If you find yourself in the midst of one of these tribal moments, your best option is often to just table the topic, and pick it back up once people have had time to turn their brains back on, and reconsider their own positions under a more rational light.

And by the way, there are multiple solutions to the «button problem» I mentioned at the top of this piece. Coming up with a few is left as an exercise for the reader.

  1. In the end, you could aways create some prototypes and do a few usability tests to see if hiding the buttons really works, but the argument for hiding them isn’t really a usability argument, it’s an aesthetic argument. If we don’t hide them, the UI looks bad. back

  2. And elsewhere. back

If you require a short url to link to this article, please use http://ignco.de/591

designed for use cover

But wait, there's more!

Want to read more like this? Buy my book's second edition! Designed for Use: Create Usable Interfaces for Applications and the Web is now available DRM-free directly from The Pragmatic Programmers. Or you can get it on Amazon, where it's also available in Chinese and Japanese.