UX Profit-and-Loss analysis

Vitaly Mijiritsky
Oct 5, 2016 · 6 min read
Cicero Denounces Catiline (Cesare Maccari, 1998, public domain)

Wikipedia defines “Cui Bono” as “a Latin phrase (literally “for whose benefit”), which is still in use as a key forensic question in legal and police investigation: finding out who has a motive for a crime”. From a broader perspective it is highly useful in any kind of critical thinking, e.g. when examining messages you encounter in the media.

Its siamese twin, the question of “who is penalized”, apparently was not a staple of Roman rhetoric, as it hadn’t spawned an idiom that is still in common use today. It is, however, a staple of UX analysis. The juxtaposition of these two questions makes it easier for us to examine various UX tradeoffs and dilemmas — which tend to be more frequent and more complex than it might seem to the layman (including those who believe that adding the letters “UX” to their LinkedIn profile magically elevates them above that class).

The majority of these dilemmas stem from the fact that nearly any UX decision will have both advantages and disadvantages, and we need to weigh the former against the latter (the other way around is also fine). A textbook example is Hick’s law, as an answer to the equally textbook question “There’s still room on that screen, why dontcha place my button there?”. In response, Hick’s Law states that as the number of available options grow, the amount of time it takes to reach a decision also grows. At some point it actually leaves Hick’s Law’s domain and reaches the wonderfully named state of Analysis Paralysis — the number of options is simply too high to make a decision at all.

So in the case of the last-minute button we’d be comparing the advantages of having the button (such as exposing functionality to the user, perhaps a call-to-action, perhaps higher conversion rates, perhaps supporting another use case), with its disadvantages (increased cognitive load, difficulties in deciding on the right action, competing with existing calls-to-action, perhaps actually reduced conversion rates). But how do we in fact compare them? How does “exposing functionality” measure vs “increased cognitive load”? Well, this is where our “Winners vs. Losers” paradigm becomes extremely useful, because it lets us compare people with people — which is also not a trivial task, but at least we get to use the same units of measure on both sides of the scales.

Let’s take a real-world example. I’m writing this using Google Docs (sorry, Medium). It has the useful option of inserting images into the document. To do that, you press the “Insert” menu and choose the “Image” option in the menu. Once you do that, this modal comes up:

The modal offers six ways of inserting images into the document: upload a file, take a snapshot, provide a URL, select from your albums, select from your Google Drive, or search Google Images. Each option is represented by a tab, and each tab contains a different User Interface inside. Basically the only thing shared by all six options is that you finish your workflow by pressing “Select” at the bottom of the modal.

Just by looking at this screen, anyone who’s been in the UX game for any length of time, can vividly hear a question that’s been raised when this design has first been presented. It went “Why would we hide these six options in a dialog as opposed to listing them in the menu? They don’t even share any of the UI!” And an excellent question it is. Let’s examine who benefits and who gets penalized by that suggestion.

The benefits of listing all six options in the menu are clear. You eliminate an extra click from the process, and you expose all six options directly in the menu. Let’s say that we have a user who needs to add an image from an album that they have in the Google cloud. It may not be self-evident to them that they need to press “Insert Image” in order to reach the option to browse their albums. They might look for the “insert from album” option in the menu, not see it there, conclude that it’s not a supported feature, go to their album in another browser tab, manually download the image to their desktop, and then try to upload it using the current solution. At that final stage they’d see that the album option has been waiting for them in hiding all along — and they’d be pissed. And rightly so!

And as to the clicks argument — while the number of clicks is an extremely poor and hugely overrated measure of UX quality, it still goes without saying that unnecessary clicks ought to be eliminated — just like any other unnecessary UI element. So let’s throw that in the mix too, as an additional benefit.

So far, we’ve been working with the Cui Bono principle. We’ve identified the users who benefit from taking the six options out of our modal and displaying them directly in the menu. Namely, these are the users who wish to provide an image through a means other than upload, but don’t expect the Image dialog to provide the means that they’re looking for. And then there are also the click-curmudgeons.

Comparing apples and oranges — not the soundest UX method

Now let’s examine the second part of our paradigm — “Who is penalized”. Well, it’s actually everyone who opens the Insert menu. Because instead of the single row saying “Image” now there are six rows, detailing the different options. The menu itself grew from 18 items to 23, almost by a third. And a few decades of psychological research say that a multitude of options has a detrimental impact on work efficiency. The immediate reference is Hick’s aforementioned Law, but this is also the main idea behind the principles of Minimalism, Reduction of Cognitive and Visual Load, Progressive Disclosure, the elusive concept of Simplicity and many others.

So who else is penalized? Ironically enough, it’s many of the same people who benefit. Let’s say that I went for the “Upload from Album” option, couldn’t find my image in the albums, and now I want to switch to the “From Google Drive” option. Or I meant to provide an URL but then decided to use Image Search instead. Or any other scenario that involves the user changing their mind halfway. The current solution lets them press another tab in their current screen, and there they are. If we remove the tabs in favor of the menu, they’d have to close their modal, open the menu, choose the right option (Hick’s Law Strikes Back at this point), and then get a new modal. I should clarify that this is not about clicks! It’s about switching between contexts, which is truly a high price to pay.

So we’ve identified the “losers”. The damage is actually much smaller than it could’ve been. In our case the penalized are all those who open the Insert menu, as well as people who’ve changed their mind halfway in the workflow (who are basically penalized twice). This is because the options are still tucked away inside the menu. Had we been talking about a toolbar, which is visible always and to everyone, we’d be penalizing every single user of the product.

We’ve only been examining two solutions — the current modal vs. listing all options directly in the menu. There are many others (e.g. listing them in a sub-menu). But in our case the advantages of one solution are automatically the disadvantages of the other, so we don’t need to run this profit-and-loss analysis twice, they’re mirror images of one another. In a larger setup things are more complicated.