Don’t Confuse Complex with Complicated, Part 3 – Assuming the Burden

Article summary

More than ever, digital experiences impact how we work, learn, and play. As these experiences become more connected and therefore complex, it’s important to design for clarity and be intentional in how we build our information.

In part two of this three-part series, we looked at why we need to be clear with our definition of “simplicity” and why it’s not the same as reducing the complexity of a system. In part three, we’ll talk about why we can’t choose our way out of complexity.

We can’t design away complexity.

For this part, we’ll reference The Law of Conservation of Complexity (Tesler’s Law). This law states that, for any system, there is a certain amount of complexity that cannot be reduced. More importantly, all processes have a core of complexity that cannot be designed away. That means either the system or the user must assume the mental burden.

This is the true basic value of any piece of software. To build something people will want to use, we need to ensure as much of the mental burden as possible is lifted from users by dealing with inherent complexity during design and development. If we’re not doing this, then we’re not actually solving a problem for our users. Instead, we’re just asking them to perform the same task differently. This means our software might work and be successful, but it makes growth and adoption a lot more difficult for the business.

Can it be too simple?

To add another layer of complexity (see what I did there?), we also need to realize that we can, and often do, make things too simple. This is especially true for experiences dealing with complicated subjects.

In these scenarios people resist reductions to the amount of complexity.

If it’s too easy to obtain a $500,000 mortgage, you might be a little suspicious. This further emphasizes the need to understand our users and their mental model if we want to build a successful piece of software.

To recap, we have two primary approaches to the information layer to make our software usable and valuable to our audience.

  1. Lift the burden of completing a specific task by using technology to assume some of the complexity.
  2. Make things “simpler” or, more specifically, make the experience easier to interpret through content, clear instructions, and transparency.

The two approaches aren’t mutually exclusive, and mature teams will tackle both. However, each approach can have a profoundly different impact on how you think about and tackle the work. So, I encourage you to get specific with your goals and align with your team on what you are trying to accomplish.

That way, your complex software project won’t have to feel complicated.

In this Series:

  • Part 1: We start by defining ‘information’ and how it plays a crucial role in the success or failure of a project.
  • Part 2: We take a look at why making something simple isn’t the same as making something less complex.
  • Part 3: We explore why you can’t design away complexity, and why you might not want to.

Join the conversation

Your email address will not be published. Required fields are marked *