Don’t oversimplify designs: how to work around complexity with Tesler’s law | by Kai Wong | May, 2023

Oversimplifying design results in unhappy Engineers and confused users

UX Collective

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

A image which encapsulates Tesler’s law, including the definition (there is a certain amount of complexity which cannot be reduced) along with 3 takeaways. All processes have a core of complexity that cannot be designed away, Ensure burden is lifted from users by dealing with complexity in design, and be careful not to oversimplify to the point of abstraction.
Tesler’s Law, courtesy of

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

A Curve showing the balance yet the strike between oversimplifying and over complicating. It is a reverse shape you, where the highest possible value is in the middle, with the stuff to the left and the stuff to the right showing over complicating or oversimplifying

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.

A phone held downward to try and scan a QR code on a screen.
Photo by iMin Technology:

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.

The page, which has a number of different options at the bottom left the right and right next to the search bar. This includes things like Gmail, store, accessibility, and all the other Google suite products.
Have you seen all the add-on stuff on recently?

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.

Read the full article here

Leave a Reply

Your email address will not be published.

Mental Models; A Guide to how your Users Really Think | by Faith Olohijere

Mental Models; A Guide to how your Users Really Think | by Faith Olohijere

Palmihelp on Stock Photos Understanding users’ mental models is one aspect of

The Significance of Brand Consistency in Packaging Design

The Significance of Brand Consistency in Packaging Design

If you have a small business, you have heard about brand consistency and want to

You May Also Like