Simplicity is Overrated

Posted 7 months 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

How my Sketch file started: a separate artboard for every type of Yammer thread. There were lots. Reducing our design handoff from 30 mockups to just one I’ve recently begun working on a design revamp of Yammer’s Android app, beginning with conforming all Yammer conversations to a 4px vertical grid for better readability. Because a single misaligned pixel could throw off the… Read More →

As designers, we create user flows and give them to developers, product managers, clients, and sometimes even users for testing. At its best, a user flow is a concise, clean, and compelling way to showcase the scope and vision of your application before it is developed. Oftentimes user flows are the key piece of documentation that we provide developers to… Read More →

I have a lot of friends who work in Growth, but I never really knew exactly what they did. Whenever our conversations turned towards “growth stuff”, I would always just smile, nod, and occasionally contribute a, “that’s really cool!” It’s not like I was clueless. I mean, I had an idea of what “Growth” meant — growing users, making money,… Read More →