Tessler's Law: The Hidden Art of User Experience Balance

Imagine this: You're redesigning a complex financial app. The stakeholders want it to be comprehensive yet simple, powerful yet intuitive. You've spent weeks crafting the perfect interface, only to watch users struggle during testing. Despite your best efforts, something's off. The balance feels wrong.

You've just encountered the invisible force known as Tessler's Law.

What is Tessler's Law?

Tessler's Law, sometimes called the Law of Conservation of Complexity, states that complexity cannot be eliminated from a system—it can only be shifted between different parts of the system. In UX terms, this means that complexity can be moved from the user to the system (or vice versa), but the total complexity of a task remains constant.

To put it simply: "Every application has an inherent amount of complexity that cannot be removed or hidden. Instead, it must be dealt with, either in product development or in user interaction."

Named after Larry Tessler, a pioneer at Apple and Xerox PARC, this principle challenges the notion that simplicity should be the ultimate goal of design. Instead, it suggests that complexity management is the true art.

The Core Principles of Tessler's Law

1. Complexity Conservation

The total complexity of a system remains constant. If you simplify the interface, the complexity might just shift elsewhere—perhaps to the backend, to documentation, or to mental models users must learn.

2. Complexity Distribution

The designer's job isn't to eliminate complexity but to distribute it optimally between the system and the user.

3. Appropriate Complexity Allocation

Some complexity belongs with the system, and some belongs with the user. The skill lies in knowing which is which.

When to Embrace Tessler's Law

Pro: Designing for Expert Users

For tools aimed at professionals (like video editing software, financial trading platforms, or professional design tools), hiding complexity can be counterproductive. Experts often need and want direct access to complex functionality.

Practical Example: Adobe Photoshop doesn't try to hide its complexity behind a simplistic interface. Instead, it exposes powerful tools that professionals need, while organizing them logically and providing multiple paths to the same functions based on user preference.

Pro: Building Scalable Systems

Systems that grow with users' expertise benefit from careful application of Tessler's Law.

Practical Example: GitHub's interface reveals increasing complexity as users become more familiar with the system. New users can perform basic operations with minimal friction, while experienced developers can access advanced features through the same interface. This often employs techniques like chunking or progressive disclosure.

Pro: High-Stakes Environments

In medical, financial, or industrial systems where mistakes can have serious consequences, appropriate complexity allocation is critical.

Practical Example: A patient monitoring system in a hospital ICU should surface critical information clearly but also provide immediate access to detailed data when needed. The complexity is necessary—hiding it completely could be dangerous.

When to Reconsider Applying Tessler's Law

Con: Consumer Applications

For everyday apps aimed at broad audiences, excessive complexity can be fatal to adoption.

Practical Example: If a food delivery app exposed all the complexity of routing algorithms, inventory management, and dynamic pricing to users, it would be unusable. Here, the complexity must be handled almost entirely by the system.

Con: First-Time User Experiences

When designing onboarding experiences, too much complexity can overwhelm new users and lead to abandonment.

Practical Example: Tax preparation software that immediately displayed all possible tax forms and calculations would terrify most users. This is an example of choice overload and high cognitive load. Instead, interview-style question flows handle the complexity while collecting necessary information, often by chunking the information.

Con: Emergency Situations

Interfaces designed for emergency use must minimize cognitive load and decision-making complexity. (See also Miller's Law for managing short-term memory limits on cognitive load).

Practical Example: A fire alarm system shouldn't require multiple steps or complex decision trees. The complexity should be handled by the system, with the user interface reduced to essential actions.

The Designer's Balancing Act

Tessler's Law doesn't give us permission to create needlessly complex interfaces. Rather, it challenges us to be thoughtful about where complexity belongs.

I once had a manager who said, "Designing simple things is complex, and designing complex things simply is an art form." He wasn't wrong—just unnecessarily complex in his explanation! (A little designer humor there.)

Three Strategic Approaches to Handling Complexity

1. Appropriate Defaults

Good defaults can absorb system complexity while giving advanced users the option to customize.

Practical Example: Email clients like Gmail handle enormous complexity through smart defaults (sorting algorithms, spam filtering) while still allowing power users to create custom filters and organization systems.

2. Progressive Disclosure

Reveal complexity gradually as users need it, rather than all at once. This often involves chunking information.

Practical Example: Microsoft Word shows basic formatting tools by default but allows users to access increasingly specialized functions through menus, ribbons, and advanced settings dialogs.

3. Contextual Complexity

Show complex options only in relevant contexts.

Practical Example: Navigation apps show different interface elements and options depending on whether you're planning a route, actively navigating, or dealing with a detour.

Common Pitfalls When Applying Tessler's Law

The Oversimplification Trap

Simplifying the interface without considering where the complexity goes can lead to hidden functions users can't find or mysterious system behaviors they can't predict.

Practical Example: Early versions of Windows 8 tried to simplify the desktop experience by removing the Start button. This didn't reduce the system's complexity; it just made it harder for users to access basic functions because it violated established mental models.

Designers often underestimate how complex their systems appear to novice users. This is a common type of cognitive bias.

Practical Example: Command-line interfaces may seem efficient to developers but can be impenetrable to average users. This isn't inherently wrong—it's just a clear choice to allocate complexity to the user rather than the system.

The Feature Creep Cycle

Adding features without managing complexity leads to bloated, confusing products.

Practical Example: Enterprise software often suffers from feature bloat as vendors try to satisfy every customer requirement, resulting in interfaces so complex that users need extensive training just to perform basic tasks.

Real-World Application: The iPhone Calculator

Apple's iPhone Calculator app provides a perfect illustration of Tessler's Law in action. In portrait mode, it shows only basic functions—deliberately limiting complexity to match the casual use case. Rotate to landscape, and the scientific calculator appears with its additional complexity.

This isn't merely hiding complexity; it's thoughtfully distributing it based on likely user needs and contexts. The complexity is always there, but Apple has made deliberate choices about when and how to reveal it.

The Humility of Good Design

Tessler's Law teaches us design humility. We cannot make complex tasks simple through interface magic—we can only redistribute the complexity in thoughtful ways.

This reminds me of the old UX designer joke: "How many designers does it take to change a lightbulb? One to change it and four to explain why the old bulb had better contrast ratio."

But in all seriousness, accepting that complexity is conserved liberates us from the impossible task of making everything simple and focuses us on the achievable goal of making complexity manageable.

Conclusion

Tessler's Law isn't about embracing or avoiding complexity—it's about respecting it. The next time you're designing a system, ask yourself: "Where should the complexity live in this interaction? With the system or with the user?" The answer will depend on your users, their goals, and the context of use.

Remember that the best designs don't eliminate complexity—they place it where it belongs.