Skip to main content

Complexity

"...Every application must have an inherent amount of irreducible complexity. The only question is who will have to deal with it... If a million users each waste a minute a day dealing with complexity that an engineer could have eliminated in a week by making the software a little more complex, you are penalising the user to make the engineer's job easier."

Larry Tesler

Every product carries inherent complexity. The challenge lies in determining who shoulders this complexity — the user or the software itself. Here's a breakdown of standard strategies to manage complexity:

  1. Eliminate Unnecessary Complexity: The ideal scenario is to avoid unnecessary complexity from the outset. However, if you're revisiting a design or if the goal is to simplify a design without sacrificing utility, techniques might include consolidating controls, introducing direct manipulation, or redefining concepts.
  2. Reduce Features: While it might seem like a straightforward solution, reducing features can compromise utility. History has shown that oversimplifying, especially in professional software, can backfire. Apple's disastrous redesign[1] of Final Cut Pro serves as a cautionary tale of removing functionality.
  3. Guided Complexity: This approach involves progressive disclosure and better data organisation. It's about presenting users with the essential features upfront and making advanced features accessible when needed. However, it's crucial to avoid oversimplification, such as replacing three distinct buttons with a single menu containing three options when there’s no acute shortage of space. Guided complexity does not mean hide everything, it means you should optimise and distill.
  4. Redefine the Workflow: This strategy is a game-changer. It's about reimagining the problem to achieve the desired outcome with a more streamlined workflow. The key is to shift the burden of complexity from the user to the product, creating a clear distinction between your product and competitors. This comes naturally if you use concepts to design your software.

In essence, the fourth strategy is the gold standard. When that's not feasible, the third approach is the next best thing. I'm a firm believer in pulling complexity downward, away from the user and into the architecture of an app (be that the engineering architecture, the information architecture, or the general design and layout), that way users don't have to deal with it. A benefit of this approach relates to an observation by Bruce Tognazzini, which is that people want[2] a certain level of complexity in their lives, therefore when you simplify an app, users will attempt more complex tasks. Thus by streamlining workflows, users will effectively push themselves to do more or better. This goal is what we should all be striving for in any DCC, getting the software out the way of the user and allowing them to get the job done, and perhaps even to do a better job of it. 

[1] See: https://www.fastcompany.com/1664942/when-is-the-right-time-for-a-product-redesign and https://daringfireball.net/2011/06/final_cut_pro_x_backlash

[2] Flow: The Psychology of Optimal Experience by Mihaly Csikszentmihalyi explains why this might be.

Balancing Interaction Complexity against Interface Complexity​

A common mistake designers make is to not account for interaction complexity when designing interfaces. Interface complexity is often the only kind of complexity considered, and this missing perspective is responsible for bottlenecks and much unnecessary friction in products.

Imagine that you want to send a message, let's take a look at two possible ways of doing this. First we'll consider the telegraph key, it has an irreducibly simple interface consisting of just one button, it literally could not be more simple, however the interaction complexity is exceptionally high, the user is required to tap out messages in Morse code, an outcome which cannot be inferred from its interface. Next let's look at a keyboard, a device where the interface complexity is extreme; on most keyboards there are 104 keys. So, let's say it's 104x more complex than the telegraph key interface. However, the interaction complexity is far simpler than the telegraph key. To type an 8 on a telegraph key, that's dash, dash, dash, dot, dot (and don't make a mistake!), to do the same on a keyboard requires you to simply locate the number and tap it. If you get it wrong, there's the backspace key; finally, the task of typing on a keyboard can also be mostly inferred from the interface, which is not true of the telegraph key. Which one would you rather write a book with? The simple interface? Or the complex one? To hammer the point home, the average telegraph operator would tap 10 times a second to achieve a very rapid 24 words per minute. Professional QUERTY keyboard typists routinely hit 95 words per minute, but, if you increase the level of complexity further and look at professional stenographers, they can achieve an astonishing 360 words per minute. Achieving both minimal interaction and interface complexity is of course possible; Apple opted for a single button mouse on the original Macintosh (most mice at the time had 3 buttons) and a huge engineering and design effort was required to support this pairing of simple interface/ interaction in the system and software, however compromise was needed such as the invention of the double-click[1].

All in all, reducing interface complexity can cause interaction complexity, and interaction complexity is what costs users the most time. Bare this in mind when looking over the section on progressive disclosure and make sure this is not a mistake that you're making.  [1] Double click is not a universally loved idea, see https://blog.codinghorror.com/double-click-must-die/