Overview

Who should bear the burden of complexity within an application or process — the user, or the designers and developers? This fundamental question is core to user interfaces and more broadly how humans interact with technology. A key objective for designers is to reduce complexity for the people that use the products and services we help to build, yet there is some inherent complexity in every process. Inevitably we will reach a point at which complexity cannot be reduced any further, only transferred it from one place to another. The result of this transfer is that complexity finds its way into the user interface, or into the processes and workflows that we designers and our development colleagues must absorb.

Origins

The origins of Tesler’s Law can be traced back to the mid-1980s at the seminal Xerox PARC. It was during this time that computer scientist Larry Tesler was helping to develop some of the foundational language that would become known as interaction design and was a key to the development of the desktop and desktop publishing. While at Xerox PARC, Tesler observed that the way users interact with applications was just as important as the application itself. This observation led him to conclude that an inherent amount of complexity that cannot be removed or hidden within an application or process. Instead, it must be transferred to one of two places: to the development (and by extension design) or to the interaction that’s assumed by the people whom use it.

Examples

One common way to illustrate Tesler’s Law is through the humble email. When you write an email, there are two required pieces of information: who the email is from (you), and to whom the email should be sent. The email cannot be sent if either of these is missing, and therefore it’s a necessary complexity. To reduce this complexity, modern email clients will do two things: prepopulate who the email is from because it is aware of your email address, and provide suggestions for who the email should be sent to based on prior emails and/or your contacts (Figure 8-1). The complexity isn’t entirely gone, it’s just simply abstracted away from you so that you don’t have to remember and type your email address and the address of the recipient. In other words, your experience is made a little simpler by moving the complexity of writing an email to the email client, which was designed and developed by a team that assumed that burden of complexity when building it.

Figure 8-1. Modern email client reduces complexity by populating ‘from’ line and suggesting ‘to’ line based on prior emails. (Source: Gmail)

Taking that a step further, Gmail now leverages AI (artificial intelligence) within your email through a feature called Smart Compose (Figure 8-2). This intelligent feature can scan what you’ve typed and use it to suggest words and phrases to finish your sentences, thus saving you additional typing and time. It should be noted that Smart Compose is not the first time-saving feature introduced to Gmail by way of AI — there’s also Smart Reply, which scans email for context before leaving several relevant options for a faster reply.

Figure 8-2. Example of Gmail’s Smart Compose feature. (Source: Gmail)

Email isn’t the only place you can find lots of examples pertaining to Tesler’s Law. Retail is another area where you can find innovative ways that complexity is abstracted away from users. Let’s take for example Amazon’s Go stores (Figure 9-3), which provides a checkout-free shopping experience. First appearing as an experiment in downtown Seattle, they are now popping up around major metropolitan areas all over the United States. With the Amazon Go app installed on their smartphone, customers can simply check in with their phone, grab what they need, and walk out without ever needing to wait in line, scan their items, or even pay in the store. A little later, will receive a receipt and charge their Amazon account.

Figure 8-3. The first Amazon Go store in Seattle (Source: Wikipedia)

The dizzying array of technology a checkout-free shopping experience like that found in Amazon Go stores is nothing short of astounding. Advanced technology like machine learning, computer vision and AI must be deeply integrated to allow for people to simply walk into the store, grab the items they wish to purchase, and then walk out. While the friction of shopping is drastically reduced for customers, the complexity that comes along with it is absorbed by the designers and developers responsible for ensuring it all works.

Key Consideration: When Simplicity Turns to Abstraction

[Note: this section will address when simplicity can turn to abstraction and the resulting downsides]

Key Takeaways

All processes have a core of complexity that cannot be designed away, and therefore must be assumed by either the system or the user.

Ensure the burden of complexity is shared by identifying appropriate places to move inherent complexity.

Conclusion

Tesler’s Law is important for designers to be aware of because it governs a fundamental challenge we face throughout our work, and that’s how we manage complexity. We must first acknowledge that there will be a necessary amount of complexity with any process that cannot be removed, no matter how simplified the process becomes as a result of the design process. Whether it’s the humble email or a highly sophisticated process such as checkout-less shopping, inherent complexity must be transferred to either the user or the designers and developers responsible for creating and managing it.