Is Your UX Cargo Cult?
One of the most helpful analogies in my everyday coping with the UX world, is that of the Cargo Cult.
To those unfamiliar with the term, the Cargo Cult is a phenomenon observed in the islands of the Pacific after some more advanced civilizations had turned them into a kind of Airbnb during WWII. From the islanders’ point of view, one statistically sunny day a fleet of enormous alien-looking ships pulled up to the islands, carrying strange people and stranger machines. Both proceeded to set up airstrips, which seemed to attract huge metal birds, introducing the islanders to the joys of booze, modern tools, canned foods, and booze. Also wholesale death, doom and destruction, but why focus on the negative. A few action-packed years later the war was over, the westerners scampered back west, and the booze, as is often the case, ran out. That last part did not go well with the locals, because peace is all well and good, but a beer is a beer. So they put two and two together, apparently coming up with “many”, and set out to construct new airstrips based on available materials and technology, i.e. literally straw in most cases. So pretty soon after the end of the war the islands became littered with life-size straw replicas of aircraft and airstrips, complete with antennas, control towers and people with straw headphones on their heads. This really happened and it is rather well documented.
While the Cargo Cult did not eventually help the natives get sloshed, it does offer a very helpful prism for examining UX decisions. Here’s how it works: every time you hear someone else saying, or you feel the urge to say, “Let’s use the same solution as in those guys’s product”, you need to consider the possibility that you might be just gathering straw for your cargo cult interface. Make sure you understand exactly how this solution works for those other guys, and is there really reason to believe it will work for you equally well. Things tend to not be as simple as they seem.
Suppose, and this is a purely hypothetical situation which absolutely did not happen a few years ago, that you’re working on a complex, table-ridden system, and your users often wish to filter a table column by a specific value. For instance, it could be a table of smartphone models, and your user wishes to limit it to Samsung models only. So they’d press a small, standard “filter” icon at the column header and they’d get a little dropdown list of all the different vendors you support, and they’d click Samsung, which would close the list and filter the table to include only Samsung phones. So far so good.
The plot thickens, however, once users wish to be able to filter by several values at once — e.g. Samsung, LG and HTC. So now we must support multiple selection in the filter — for instance, by adding little checkboxes next to each value. So the selection part is rather straightforward. The closing the filter part — not so much. We don’t know how many values the user intends to select and when they’re done. With single selection we closed the filter as soon as they selected a value. At what point do we close it now?
Basically a new step is being added to the process — the user must let us know that they’ve finished selecting. Which poses a dilemma — do we actually make the user say it, or do we wing it and try to infer their intention based on behavior?
The “I gotta hear you say it” approach means that we add some kind of a new control to the selection interface. Like an “OK” button. The “I thought you wanted it” approach, on the other hand, means that we don’t add any explicit buttons but wait for the user to start trying to get rid of the open menu, and then apply the filtering. A common behavior in such cases is clicking outside the area of the obstructing control, by way of saying to the machine “You see where I’m clicking? That’s what I want to see, you’re blocking my view”.
These are our options, roughly speaking. Either making the user click “OK” to close the filter menu, or closing it on a click outside. How do we pick the right one? Well, we could try analyzing the situation, but why bother when you can just quickly build something out of straw and go do the rain dance. Let’s see if we can’t find a successful product with a multiple selection filter, who is bound to have gotten it right.
Hey! Eureka! You know who is super successful and wrote the book on multiple selection filters? Old Microsoft Excel! Granted, there are some people who cringe at hearing the word “Microsoft” in a positive statement, and in the context of User Experience no less, but even they tend to admit that at least the Excel guys seem to know what they’re doing. And the Excel approach is very clear — give them OK/Cancel buttons all the way. So we’ve got our solution, all that’s left is to gather the straw. Here’s the Excel filter:
Fantastic. However… listen.. you know how in real planes they’ve got that noisy bit… wossname... begins with an “N”... wait, don’t tell me… um… ah, got it, “the engine”, right? The lack of said engine being one of the, um, hidden flaws, shall we say, of the otherwise surefire straw endeavor? Well, the Excel solution is also a bit more complex than it seems to be. For one thing, it’s got much more content that just a list of values with some checkboxes and an OK button at the bottom. For instance, it’s got this menu
each of whose items open a popup that looks more or less like this
and maintains a clearly “it’s complicated” relationship with the main value selection list. So the OK and Cancel buttons control this whole thing, with its three kinds of sorting, eight kinds of filtering, and the searchable value list itself. As filter controls go, that’s a pretty complex one. And this complexity is precisely what forced Microsoft to require their users to explicitly state “I’m done”. What makes me so sure of this is the fact that if you squint the right way, you can just see the hoops that they had to jump through in order to minimize user friction. Let me show you too.
Take another glance at the filter window. See anything odd? Anything that sets it apart from your typical window with an OK and Cancel at the bottom? Usually when we force the user to drop everything and confirm a screen, we demand all their attention — so we create a very clear distinction between the window in question and the rest of the screen. We bring it front and center, we emphasize its borders, and we block everything else. On the web it’s also customary to gray out the rest of the screen, but in desktop applications it’s not as common.
We see none of that here. This is an extremely rare example of a window that behaves as a dialog (meaning, that it must be submitted or canceled) and that is modal (that is, doesn’t let you interact with the rest of the screen as long as it’s active), but that does not take over the entire screen. I consider it a testament to Microsoft’s commitment to keep this interaction as smooth as possible, minimizing the interruption to the user’s workflow.
Still, the question remains — how do we pick the best approach. True, the Excel dialog is much more complex than ours, but is that reason enough to decide that their solution is unsuitable to our needs? Well, I think that there’s a really simple way of answering that question. We are not developing a new system here, and we aren’t designing the filter from scratch. Our users have been working with the single-selection filter for a while now, and we’re merely expanding its functionality. This change needs to be as smooth as possible, and to require a minimum of new actions added to a familiar process — ideally none. An explicit “OK” button is a much more significant addition — both visually and cognitively — than just using the outside click. The former requires the user to make a decision. To think, maybe to take another glance at the settings, and then to confirm. The latter doesn’t even ask any questions — but uses a natural user behavior to interpret their intentions. Possibly with some risk of false positives. We should go down the path of least astonishment. Don’t make it any more complicated than it needs to be, just because big name did so in a use case that bears some superficial resemblance to your own.
Keep it simple, stupid.
