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.