Confused People Create Confusing UIs

If you're still baffled, flummoxed, or concerned about Facebook's now-infamous privacy policies, here's a handy chart from The New York Times. (Thanks, Madiha, for the pointer.) While the diagram retains a neutral tone, it's hard to read the phrase 50 settings with over 170 options without having a "What the hell?!?" moment.

In defense of Facebook, they're no worse than many technology companies that devise confusing UIs, full of knobs and dials that users don't understand or use. These companies are still to blame for creating the circumstances in which a confusing UI is hard to avoid, so they're not completely blameless.

An apology to future generations
Here's where we venture into the idiosyncratic sub-culture of the tech industry, which is hard to understand if you've never been part of it. In spite of having big development budgets, a staff of seasoned professionals, and months to build a useful product, tech companies repeatedly build software that begs the question, "Daddy, why is your product so hard to use?" (Even weirder: usability is often inversely proportional to the price.)

There's more than one source of confusing UI design. To its credit, the tech industry has addressed some of them, such as the previous habit of treating the UI as an afterthought. In the old days, many development teams built the moving parts that the user didn't see first, and then, in the classic phrase, "threw a UI on top of it." Imagine designing a car by bolting together the engine, frame, transmission, brakes, and other components, and then squeezed in whatever seats, dashboard, and steering wheel you could. Not exactly sound engineering principles, but that's how many UIs came into being.

While the move to better UI design isn't universal in the tech industry, certainly the situation has improved. Many development teams now start with the UI, or something that will lead to a better understanding of how people will use the technology (user stories, use cases, etc.). Still, some sources of confusion remain, and the biggest one is at the heart of the Facebook problem: Too many options.

More is not always better
Why do all these options exist? Honestly, in many cases, development teams lose track of the reasons for them. Some may have started with an honest effort to give the user something useful, such as control over who can see your personal information. In many cases, development teams provide options that aren't really helpful: to use the car analogy again, I don't really want to modulate the flow of oxygen through the engine, even if I were given the option. 

Some may have started with an idea that served the vendor's interests, such as Facebook's instant personalization features. Raise your hand if you wanted to see Facebook updates while reading The Washington Post. Nobody? Guess Facebook wanted that feature more than users did. Here's where software isn't completely analogous to automobiles: car manufacturers don't insert a lot of features that are only useful to the manufacturer.

Over time, these boundaries get blurry. Options are like government agencies: once they exist, it's hard to get rid of them. Their raison d'etre becomes irrelevant, if you're afraid to pull the plug on something that someone, somewhere, might be using.

Pruning with a chainsaw
Dealing with this problem is difficult, but not impossible. My Forrester colleague Mike Gualtieri writes frequently about best practices for user experience (UX), as well as their flip side, worst practices. (I don't think too many of you will object to the statement, "Many app dev organizations don't have enough (if any) UX professionals.") Cindy Alvarez's blog has lots of useful pointers. Her willingness to talk about it in very specific terms, about her own company, connects generally useful advice to very specific examples. And I wholeheartedly endorse her overarching thesis that the user experience is the product.

Still, humans being humans, exhortation often isn't enough. If you're really serious about pruning the complexity of your UI, you might need to take more dramatic steps that compel UI simplification. Here are a few examples:

  • Go SaaS. There's nothing that focuses the mind like having your users walk away from your product because it's confusing. SaaS also makes it possible to monitor which features actually get used.
  • Go Agile. The economy of effort in each sprint forces hard questions like, "How much do people use any of this stuff?"
  • Rebuild your product. I wouldn't recommend taking a measure this drastic just to winnow UI complexity. However, if you're going to re-write the product anyway, it's a good time to push back on the necessity of re-building options that don't have a clear, compelling justification to exist.

You might notice that I didn't say, Embrace Lean. While Lean is an extremely effective approach, its adoption needs initial momentum from other changes, such as Agile or SaaS.