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 Tesler1

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 redesign2 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.

Simple to Operate, Sophisticated to Investigate​

It is worth pausing on an important distinction that Barbara Mirel draws: easing burdens and simplifying work are not the same thing.3 For complex problem solving, simplicity means a program eases users' investigative burdens without reducing the layering and nuances of their work. Unfortunately, in many development contexts, easing burdens and simplifying work get equated — leading to designs that strip away the very capabilities professionals need.

A useful way to think about this comes from cognitive load theory4, which distinguishes three types of load:

  • Intrinsic load: The inherent complexity of the domain task — this cannot and should not be reduced
  • Extraneous load: Complexity imposed by the interface design — this should be minimised
  • Germane load: Effort devoted to building understanding and mental models — this should be supported

The goal is to reallocate cognitive budget from extraneous load (fighting the interface) to intrinsic and germane load (doing the work and learning from it). Automate tedious data conditioning. Never automate professional judgment.

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 a certain level of complexity in their lives5, 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.

Footnotes​

  1. Tesler, L. G. (1985). The Smalltalk environment. Byte Magazine, 10(8); also documented in "Designing the Star User Interface," folklore.org account of Tesler's work at Xerox PARC/Apple. ↩

  2. Gruber, J. (2011). Some thoughts on Final Cut Pro X. Daring Fireball. https://daringfireball.net/2011/06/final_cut_pro_x_backlash ↩

  3. Mirel, B. (2004). Interaction Design for Complex Problem Solving: Developing Useful and Usable Software. Morgan Kaufmann. ↩

  4. Sweller, J. (1988). Cognitive load during problem solving: Effects on learning. Cognitive Science, 12(2), 257–285. ↩

  5. Csikszentmihalyi, M. (1990). Flow: The Psychology of Optimal Experience. Harper & Row. ↩