Simplicity is Overrated

Posted 2 years ago by Gabriel Colombo

“Fast, simple and easy to use”. This is the motto that drives the majority of tech companies nowadays. Fueled by Agile methodologies, these companies strive for fast deliveries and quick iteration cycles.

But, in order to deliver fast, the outcome must be simple. But how simple? One of LEAN’s methodology principles says the following:

(…) Keep things simple. Keep the requirements simple. Keep the technical solution simple. Find the easiest way to meet the users’ goals. Don’t over-engineer. Don’t spend too long considering future requirements that may never materialize. Get something simple to market and build on it based on real customer feedback— (source)

The problem is that sometimes “simple” ends up treated as “minimal”, resulting on faulty features that don’t add much value to the user until the next iteration comes around, causing flaws on the user experience.

Is the simplest path the best one? Not always. Most of the time unexpected things will get in the way mid process, increasing its complexity.

In order to get a better understanding on this concept, let’s take a deeper look at the meaning of simplicity.

Understanding simplicity

I believe the easier way to describe simplicity is being devoid of unnecessary complexity. Professionals are more often used to measuring how complex a process can be by focusing on its technical aspects.

“I believe the easier way to describe simplicity is being devoid of unnecessary complexity.”

Personally I like to say that simplicity is knowing what is “just enough”. It’s that moment when know that you’re providing just enough functionality for the users to get things done without getting in their way.

It can be achieved through many ways, like reducing the amount of features or hiding things until they are necessary, but attention must be paid when going down this path to not lose quality on your product.

Tesler’s Law— Why things will never be that simple

Also known as the law of conservation of complexity, it presents the following concept:

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.

This concept was coined by Larry Tesler, who claims that an engineer should spend extra time reducing complexity on the application instead of making users spend more time on the task they’re trying to perform.

Although reducing complexity in order to make the interface easier sounds like a must, these decisions should not be based solely on the technical aspects of the application. Psychology also plays an important role when making these decisions.

Finding the perfect balance

Discussions about how simple a feature should be usually derives from the following question:

“Should we take some control from the user in order to make the experience simpler or give him control of the situation at the price of increasing complexity?”

John Maeda gives us a very straightforward way for working this problem:

How simple can you make it? Vs. How complex does it have to be?

At first, you want the application to be easy to use and provide value to the user in a simple way. On the other hand, it should provide just enough functionality to get stuff done.

So, what’s the goal? To reduce functionality without significant penalty.

Knowing by Tesler’s Law that a process can only be simplified to a certain point, let’s analyze a couple different approaches:

Delegating control to the application

This approach is most valuable on situations where complex tasks must be performed.

Computers are much better at handling complexity than humans, so situations like performing calculations, multi-tasking, understanding complex patterns and querying extensive data-sets can be delegated to the application, reducing the cognitive load from the user.

In order to compensate for the lack of control, the results from such operations might be presented in the form of smart defaults or even be used to perform certain steps automatically, simplifying the interface and making the experience predictable.

The problem with this approach is that it relies heavily on feedback. If the application fails to communicate its state to the user, the experience will quickly become confusing.

“If the application fails to communicate its state to the user, the experience will quickly become confusing.”

Giving the user more control

This approach is most valuable when direct manipulation or customization is required.

Sometimes the application must accommodate custom preferences, so some decisions are delegated to the user.

On the technical side, this approach opens possibility for the creation of modes, which can complicate the experience even more if not managed properly.

On the human side, Bruce Tognazzini claims that people have some amount of resistance against reducing complexity. Tasks that are expected to be complex, like banking, if overly simplified might create the impression of being unsafe or not be working properly. Even if the computation takes only a second to complete, it doesn’t feel right that a “complex operation” like transferring money could be performed so fast.

These factors should be taken in consideration when allowing users to make decisions.

Conclusion

Don’t take simplicity for granted, take the time to figure out when you’re providing the most value to the user. Simplicity needs complexity, so what’s considered to be simple might not always be simple, it’s just doing a good job on hiding its complexity.

“What’s considered to be simple might not always be simple, it’s just doing a good job on hiding its complexity.”

Here are a few things to consider when simplifying things:

Thanks for reading, and let me know your opinions in the comments. If you like it, don’t forget to share it.

This article was originally published on Gabriel’s Medium page.

Design and prototyping for everyone

Design and prototyping for everyone

Thousands of individuals and teams use Marvel to design and prototype ideas.

Get Started, it's Free!

Designer, Front-end Developer and coffee addict. In love with tech and writing about it. Say hi on Twitter!

Related Posts

We increasingly rely on digital systems to either mediate or replace human communications. But often, these experiences feel clunky and impersonal, or even scammy and deceptive. Asking Alexa to add something to my shopping cart is a breeze: “Hey Alexa, add bananas to my shopping list.” “Okay, I’ve added bananas to your shopping list.” But if I want to add… Read More →

I’ve had several recruiters read my resumé about my experience in Design Systems and contact me about jobs. Only to find out they were hiring for people with Systems Design experience. I’ll be outlining what both topics are and help people understand the qualities of each. Design Systems An engineer who works on a design system typically has some interest… Read More →

I love stories. One of my favorites is the legend of how James Cameron pitched his idea for Aliens, the sequel to Ridley Scott’s 1979 film Alien—an example I always hoped was true until Lynda Obst confirmed its authenticity in her book Hello, He Lied. Even though it grossed over $100 million at the box office—on a measly $11 million… Read More →