Forget About the Details in UX Design

The title of this post may strike you as weird. After all, we know how important details are for UX, right? There are lots of descriptions of design details and the impact they had, and, not least, Steve Jobs' obsession with details is legendary. (See, e.g., “The Tweaker – The real genius of Steve Jobs”.) So why this post?

Well, because there is a right time for everything, and this also applies to dealing with details. Or, put differently: just because you are obsessing over details does not mean you are contributing to UX in a significant way, quite the contrary may be true.

Obsessing over details too early

Take, e.g., a CEO who is obsessed with the way a certain button looks like. Iteration after iteration he drives visual designers insane until they come up with a look that pleases him. For him, that may be an expression of his perfectionism. This may very well be. But at the beginning of a project it may be more simple: refining the look of one individual button over and over again may just be a case of bothering with details that are absolutely insignificant, which is likely to prove a waste of resources. Without knowing where one wants to go with a user interface, what experience one ultimately wants to offer, there is no conceptual framework against which design decisions can be validated. In such a context, obsessing with details is a useless intellectual or aesthetic exercise.

Discussing details is easy…

But why is there this tendency to obsess over details (even when someone does not want to emulate Steve Jobs)? Because it’s easy! – This should not be misunderstood in a sense that solving a detail issue is easy, but engaging in discussions about details is easy because such detail issues can quickly be communicated and everyone can form an impression on what they are about, even with little contextual information. (Leaving aside for now that missing or diverging contextual information may cause problem of its own.) It’s not hard to understand that the detail is the look of a button, the alignment of a label or the hover state of an interface element. Those details can be discussed much easier than, e.g., how to optimally match an implementation model to the user’s mental model. Team members can quickly grasp a detail issue and engage in discussions about it. And those discussions may provide a fake sense of project efficiency: “We have lively discussions about the user interface, so we must be doing good.”

In addition, thinking in terms of user interface details matches the tendency of some organizations or project teams to conceive user experiences in terms of features. Both can often be discussed in isolation of other aspects of the user interface while being “agnostic” towards overarching concepts or ideas that cannot directly be mapped on individual details or features. This approach to user experience, however, ignores the fact that UX is much more than the sum of design details – one cannot create an Excel sheet made up of design details and then, as discussions on individual details are settled one by one, track the progress from 0% UX up to 100% UX.

…Measuring even more so

Details also often lend themselves readily to measurement. Decide about button size? Do an A/B test! Label? Same! Shade of blue? Google already worked that one out. Testing details is easy because one can quickly come up with variants while one does not have to change the overall context. So what could possibly be wrong about having real quantitative data regarding details?

For an answer, see above: the best quantitative data is useless when it concerns irrelevant details of the user interface. Statistics are no tool for generating good designs, they can only provide information that helps in evaluating designs. When evaluating details, you can get relative information regarding detail alternatives (e.g. click rates based on button sizes), but if your overall design vision is flawed in the first place, statistics on design details won’t show you how to achieve good (or better) UX.

A detail that is worth exploring in this context is the difference between statistical significance and practical relevance. Basically, with a sufficient number of trials, every difference, no matter how small, can become statistically significant – so knowing that there is a statistically significant difference between to detail alternatives does in no way mean that choosing “the better” detail alternative over the other(s) is equal to choosing good UX vs. bad UX. It may still be a local (detail) optimization that has little (if any) impact on actual UX.

So what should be done about the details?

So how should detail issues be addressed? As said at the beginning: there is a right time for dealing with details. Roughly speaking, as a UX design project progresses, details become more important. After the foundations have been laid and you know where you are heading UX-wise, deal with the details in order to make sure that they optimally support your overall plan. Discuss them, test them, but be aware that you cannot assemble great UX just from details. Details can make or break UX, but often, the “making” part is way overrated in early stages of a project.