Don’t oversimplify designs: how to work around complexity with Tesler’s law

I got my first taste of Tesler’s Law when my designs were rejected for being “Too Simple.”

As a Designer, it sounds weird to hear that. We often aim for designs that are “Simple, intuitive, and easy to use.” Yet not only can you oversimplify a design: but doing so can harm the user experience and shove complexity onto other people.

Over-simplifying designs often harms the user experience

To explain Tesler’s Law, consider a complex subject like your taxes. Imagine if a tax software just asked for your name, social security number, and Employee ID Number.

It chugged along for a few minutes and then said, “Taxes are all done, here’s your refund, would you like to file and finish?”

More than a few of you might hesitate, wanting to manually go over the details or see what the software did. This is because we associate a set level of complexity with the process.

By simplifying the design, we would not only cause back-end developers grief (figuring out how to build such a system): users would not find it that useful.

In the case of taxes, users might go back and double-check the following:

• If tax-deductible things were counted
• If the correct W-2 documents were provided
• If they’re getting the maximum refund
• etc.

In this case, improving the existing user workflow would have been better rather than oversimplifying it.

This problem was what I faced when my device configuration page was rejected. Users would come here to turn several options On or Off through toggles, and most would be coming here to select 1 or 2 toggles.

I tried to simplify it too much by having those things turned on by default. Theoretically, this would have saved users a fair amount of time, as they could skip the configuration step. In reality, this action would have shoved complexity onto Engineering (i.e., Tesler’s Law of Conservation of Complexity).

There is always an innate amount of complexity in a system

The total complexity of a system is a constant. If you make a user’s interaction with a system simpler, the complexity behind the scenes increases. -Lawrence Tesler

They would have needed to completely alter the data collection architecture if certain defaults were enabled, not to mention when this turned on in the setup process (and whether or not we wanted to have tests like network pings to ensure smooth data transfer).

Tesler’s law, however, doesn’t apply to extremely complex designs. Countless designs have prioritized ‘simplification,’ often at the cost of the user (and Engineering team). For example, QR codes were one of the biggest offenders for the longest time.

What was intended to be an easy way to avoid errors with website addresses and more became a headache initially. Users needed to install a special QR code application, take a picture that wasn’t too blurry, and hope the system could recognize it.

However, QR codes are much more common, and it’s much easier for users to utilize them. What happened? The complexity didn’t get reduced: instead, the system, instead of the users, took on the complexity. Phones nowadays have built-in QR code readers on cameras, so the user must turn on the camera: the system does the rest of the heavy lifting.

This is the approach designers need to take when it comes to simplification. To properly work with Tesler’s Law of Conservation and Complexity, it is usually essential to remember three points:

1. Reduce obvious complexity
2. Assess the value of simplifying further through cost/value analysis
3. Ensure that the system, not the user, is burdened with the remaining complexity

Reduce obvious complexity

Hopefully, you should be able to recognize this to some degree. Still, obvious complexity is based on additional features that either don’t help (or inhibit) the user from completing their task.

For example, suppose users can’t buy a product without signing up for an account, getting a promotional e-mail with a password, logging in, and clicking to purchase. In that case, those additional steps are additional complexity you don’t need.

To follow this step, think about the tasks the user intends to accomplish on a particular page and examine what elements might not be helping with the process. Remember that not all additional steps are bad: 2-factor authentication requires the users to take additional steps but is often required and helpful for the user overall.

Try reducing these elements and seeing if users (or team members) are unhappy with removing these features. If they are, consider the next step.

Assess whether additional effort to reduce complexity is worth it

Sometimes, there are ways to reduce the complexity that will require a lot of work from Developers, but it’s worth it to the user.

In these cases, designers should consider the users’ value (and cost) using similar: severity ratings.

To do this, we would multiply the following things together (with the example of weekly value):

• Average frequency per week a user encounters the complexity in question
• Weekly Active Users (WAU), a metric that exists in most Analytics tools
• Value/Cost, which represents the Impact a user will receive from a change in complexity (or cost incurred due to the complexity in question)

In this example, the math didn’t really add up. My changes would have saved the user 5 minutes, and we had 1,000 Weekly Active Users, but users hardly came to this page (they might have come here once every two months). As a result, it didn’t make sense to move forward with this option. Instead, I used another design option, pre-filled fields, to save users time if they toggled something on.

Match the remaining complexity to the system or user depending on the purpose

Lastly, when you can’t reduce complexity any further, consider who you want to take on the remaining complexity.

In many cases, especially with novice users, you want the system to take on this complexity. That way, the system does all the heavy lifting in the background while it feels like a smooth and simple experience to the user.

However, that’s not always the case: sometimes, you want to show the breadth of options to the user to provide them with customization and personalization of tools that allow them to tackle more complex tasks.

For example, there are many simple drawing applications where all the users must draw on a touch screen. However, there are also more complex applications like Photoshop and Illustrator, which provide users with many more complex options as this is the customer they serve.

This is how you make use of Tesler’s law.

There is some inherent complexity in most things you design

For a time, everyone wanted to be “simple like Google.” The single search bar on a blank page that reduces complexity down to a single field.

However, most websites can’t pull that off: some innate complexity is always required, as part of their product, that prevents users from doing that.

In fact, Google has added complexity as well: you probably didn’t notice it.

So sometimes, the answer isn’t always to try and simplify further: it’s to design around the innate complexity of the product.

By taking those three steps of reducing obvious complexity, checking the value of reducing complexity further, and deciding whether the system or the user takes on the remaining complexity, you can design systems that match the remaining complexity to the user you’re targeting.

Kai Wong is a Senior Product Designer, Data-Informed Design Author, and Data and Design newsletter author. His new free book, The Resilient UX Professional, provides real-world advice to get your first UX job and advance your UX career.