1. Reduction leads to clarity
Take a pencil and draw a circle. Add two smaller circles, and finish off your masterpiece with a horizontal line underneath. What you’ll unwillingly end up with is something that resembles a face. Remove any of the geometric shapes, and your ingenious creation turns into abstract art.
Removal changes what something stands for.
Sometimes we have to remove significantly, before a change in perception happens. Sometimes a mere change in detail can make the most benevolent user go berserk:
97% OF ALL PEOPLE WANT THE SEARCH BOX BACK ON THE LEFT SIDE. SO WHEN WILL THIS FINALLY BE FIXED ? — Georg Scholz, Wikipedia User
If change is hard, removal is daunting. It’s one of the hardest things we do. Removal feels like undoing, when in fact, it’s an opportunity in disguise. It frees us from the limitations of the past to tap into the unlimited potential of the future.
In a recent meeting, a colleague argued that we can’t remove a feature because it would be too embarrassing to re-add it in case users want it back. This argument, whatever truth it has, doesn’t stand the test of time. It’s not about whether something is embarrassing, it’s about whether it’s meaningful. When we take the risk to remove something and realize a product won’t work without it, we gain invaluable insights of what the product stands for. Just like learning that a line is essential to convey the concept of a face.
The closest notion to Via Negativa that comes to mind is the Minimal Viable Products (MVP) methodology. This approach found great adoption and success in product teams for a good reason. It forces them to radically remove everything that isn’t necessary to validate the core of their idea. Through reduction, teams greatly benefit from minimized waste while at the same time increasing their flexibility to adjust course. The problem with MVP is that we treat it somewhat like user on-boarding. Something that seemingly only matters in the beginning.
As Krystal Higgins, Staff Interaction Designer from Google points out: don’t ask yourself where onboarding starts but where it ends. We should apply the same line of thinking to products. Rather than embracing reduction in the beginning, we should embrace it throughout the entire journey.
A great product often grows in popularity not because of the number of its features, but because of continuous improvements to the features that made it popular in the first place.
As Jeff Bezos aptly put it:
“Be stubborn on vision but flexible on details.”
Takeaway: What isn’t part of the vision must be removed. Our willingness to remove early on will reward us with the clarity of what’s essential later.
2. Reduction adds resilience
In 2009, two pilots from Air France flight 447 were in serious trouble. After flying through some storms earlier during their journey, some sensors on the wing caught ice and stopped working. This by itself, was not a big deal. As with most aviation accidents, it was a series of small errors that ultimately lead to a catastrophic outcome.
When some of the airspeed sensors stopped working, the autopilot disabled itself to give control back to the pilots. They themselves went on and were confronted with an array of different signals that were all simultaneously competing for their attention. A focus on the wrong signals lead to wrong interpretations. This on the other hand lead to wrong decisions that eventually resulted in the plane to stall.
It wasn’t until the very end that the pilots realized what was happening. The last recorded exchange was “Damn it, we’re going to crash… This can’t be happening!.” A few seconds later, the sound of desperate insight turned into fatal silence.
That day, all of the 228 passengers on board of Air France 447 died.
We increasingly depend on automated systems. As long as everything works as expected, they bring us great comfort, increased safety, and reliability. The moment systems become “safer”, however, is the moment we become negligent of what they actually do. Once they fail, we fail spectacularly, or even worse: we crash.
A large number of safety features and signals can easily become so complex that it’s hard to make sense of the overwhelming information. All these well intentioned additions and precautions may have well added to the cause of the failure itself. The more complex something gets, the harder it is to understand what’s happening.
It usually involves setting up NPM, Webpack, Babel, React JS and all the other technical mumbo jumbo. All these layers come together to build a pyramid of inter-dependent blocks. This approach has greatly increased the efficiency of our craft but came at the cost of fragility. Once a module or dependency breaks, the whole system falls apart. We easily forget that the underlying foundation of the web is plain old simple HTML, CSS, and JS — even if some of the most avant-garde technologists want us to believe they aren’t.
Most websites get awwwarded to do more, not less. There is nothing wrong with that, as long as nothing goes wrong.
More than ever, it feels like we’re building and designing with the assumption that everything just works. That everyone will be using the same class of device, browser, and network connection we have. And how are many of us dealing with this ever increasing challenge? By reducing complexity where it’s easiest: empathy. Instead of designing and building for others, we’re designing and building for slightly altered versions of ourselves.
Through Via Negativa, we are getting into similar territory to what Jeremy Keith calls Resilient Web Design.
Resilient Web Design is about starting with the essence, and enhance from there. Instead of building an array of features simultaneously, you start with what’s needed and augment it with all the nice-to-have’s. When someone uses the crappiest browser we shall not mention by name, the core of the experience still works:
By forcing us to focus on what’s needed, we ensure that we get our priorities straight. We all prefer boarding a plane that is safe, over a plane that hast the best entertainment system. The same applies to the way we build products — even when it’s not about life or death.
Make no mistake, that doesn’t just apply to the web. It applies to any technology, whether it’s development for iOS, Android or any other platform out there. If you are thinking about replacing a standard OS component or navigation pattern with your own, think again. Reinventing existing components is more expensive than we think. It’s not just that custom code needs to be maintained but users need to learn it too. Overall consistency often trumps individual greatness.
In iOS, swiping to the left is a system wide gesture convention to navigate to an app’s previous screen. In Gmail however, instead of going back to my inbox, it opens my previous email. Gmail behaves like Photos, instead of most other productivity apps. Swiping through emails is a well intentioned idea, but it quickly results in confusion since it clashes with pre-existing OS patterns.
When I started turning my website into a chat, I originally started with a version that was technically much more complex than what I have now. It used Natural Language Understanding so users could speak freely instead of the constrained version I eventually went for. The problem was that it became technically so difficult to manage, that I couldn’t ensure the experience was robust and consistent. I limited the functionality for the sake of the interface’s predictability. Interestingly enough, very few people ever complained about the fact that they couldn’t type whatever they wanted.
Takeaway: A reduction of complexity doesn’t necessarily lead to a reduction of usefulness and delight. By removing what isn’t essential, we’re adding resilience to the things that are. The baseline experience is the same for everyone. From there, everyone is on their own.
3. Reduction adds to quality
“An iPod, a phone, and an internet communicator.” With these words, Steve Jobs unveiled a device that didn’t just disrupt an entire industry, but our collective consciousness. It’s hard to remember time before iPhone. It’s so deeply ingrained in our culture that we easily forget what life was like before Apps, Animojis, Maps, and a thousand songs in our pockets.
January 9th, 2007, kicked-off what would later be called the mobile revolution.
For designers, the mobile revolution imposed a new way of design. Whereas before, the amount of pixels we were designing for steadily increased, the iPhone propelled us right back to where we started. We were all designing low resolution again.
The reduction of screen estate forced us to rethink foundational information architectural decisions that we started taking for granted. Sidebars that cluttered websites with an indecisive set of crap were no longer a viable strategy on a screen this small.
As Luke Wroblewski put it:
Losing 80% of your screen space forces you to focus.[…] There simply isn’t room for any interface debris or content of questionable value. You need to know what matters most.
Showing the essential upfront meant removing what wasn’t. The companies that were first to embrace reduction where the ones that flourished. Today, mobile websites often outperform their noisier desktop counterparts. The removal of pixels led us to design more intentionally for the ones that remained.
Now… what happens if such constraints aren’t forced upon us? We lose perspective.
Feature-creep is a problem that is as old as product design itself. People get paid to do something, not nothing. It’s much easier to point at something you added, than it is to point at something you removed or improved.
When startups realize their idea isn’t working, they often start adding new features instead of eliminating the ones that got them into their precarious situation in the first place. New features can quickly turn into distractions hiding the truth. An excuse to keep our heads down and grind forward. They delay the moment of insight that we might be on the wrong track.
Steve Jobs famously said:
“People think focus means saying yes to the thing you’ve got to focus on. But that’s not what it means at all. It means saying no to the hundred other good ideas that there are. You have to pick carefully. I’m actually as proud of the things we haven’t done as the things I have done. Innovation is saying no to 1,000 things.”
Thinking is painful. Deeply reflecting on what is essential can be so hard that we just stop midway and start building “something” because we crave the soothing feeling of progress.
Jobs pointed out what most of us largely overlooked. That we need to be equally proud of the things we haven’t done as the things we have. Not designing, not building, and not shipping something doesn’t mean we’re not productive. It’s our very own definition of productivity and the behavior we reward that is at the core of the problem.
Reduction leads to quality and focus but it’s first of all a cultural issue. You can’t simply walk into a meeting and tell people that reduction is cool. It needs to be part of the team’s DNA.
Again, what sounds simple doesn’t mean it’s easy.
Marissa Mayer notoriously said “if you’re not visibly busy, I’ll assume you’re not productive”. For her, replying to emails is visible ‘business’. Thinking deeply about a problem is not. It’s easy to see how flawed this attitude is but if you look at how many companies operate, you’ll notice that it’s not that different from hers.
In cultures where people are measured by the number of things they ship, rather than the quality of it, you can expect a lot of crap along the way. As my friend Konstantin Weiss said, you get what you track.
Don’t get me wrong, it’s great to foster a culture of trust where everyone can bring in their ideas. The problem arises when such behavior gets disproportionally rewarded. This quickly leads to a culture of shallowness instead of a culture of depth.
During the last year, I was working on an effort at Google that had different code bases, different teams, and slightly different experiences between one and the same product. About a year ago, my team and I worked out a proposal to merge everything into one experience. This meant some features teams had built needed to be removed. It was hard, sometimes it was painful, but the result was that the entire team’s attention started falling into one place. Instead of many, there was one. Through reduction, the product’s quality, stability, and consistency of UI greatly improved with it.
Takeaway: We don’t focus on absence, we focus on what’s present. The things we remove, give quality and focus to the things that remain.
4. Reduction adds to timelessness
The first HTML standard consisted of 19 HTML tags and was originally developed to read and share documents within the research team at CERN in Switzerland. Even though today’s HTML documents look vastly different from the ones in the 90s, their underlying essence is still the same: content.
Gone are the blink and the marquee tags, the grunge and leather textures, and the long shadows and shiny buttons that have each become representative for a certain era of the web.
What remained is an entirely new design language instead.
Instead of skeuomorphic or flat interfaces, we somehow converged on something that can perhaps best be described as content-forward design.
Rise of Content-Forward Design
Content-forward interfaces are based on the idea of eliminating what gets in the way to make content come to life. Since a large portion of content is written information, typography became one of its most characteristic building blocks.
The stronger focus on content and type naturally led to design that didn’t just start to look the same, it also started to work and feel the same. As the web became more typographic, so did everything else.
When Twitter dumped it’s fav button, started embracing more visual content, and relaunched their new desktop site that looked surprisingly similar to Facebook, it caused a lot of negative reactions. At the end, it didn’t take long until even its harshest critics made peace with it. The similarity between the designs shifted our focus to what those designs contained.
The more we take away, the more the content itself becomes the design. If content ages well, so will the design.
Reduction in Industrial Design
In the last decade, the shelf-life of technology and design have rapidly decreased. When everything gets new faster, everything gets old faster as well. Unlike designing for screens, where a design can be updated relatively easily, physical products remain they way they are. An industrial design can’t be updated, it can only be replaced. That’s why creating products that are unintentional is not just a waste of time and resources — it’s ecologically irresponsible.
German industrial designer Dieter Rams, who famously established the 10 universal principles of good design, believed that obsolescence in design is not just bad design, but an actual crime.
His good design is as little design as possible mantra, just like Via Negativa, proceeds through elimination to get to an object’s essential form.
It’s through reduction that the design work of Rams inspired devices we still use today. By not succumbing to the trap of following trends, he created a legacy that outlived what many others had created after him. This captures the core idea of the Rams era: The idea of making less, but better.
Takeaway: The more we remove, the less a design is prone to age. By removing what isn’t essential, we increase our chances to create a classic.
5. Reduction leads to new insights
In early 2014, millions of commuters in London were late to work. Due to decreasing salaries and job cuts, a large part of London’s underground network went on strike. For two full days in a row, commuters were faced with a complete disarray and chaos. While some stations remained operational, the majority were shut down. Many of the routes commuters started taking for granted were now unavailable to them or completely overfilled.
How did Londoners cope with this nerve-wracking situation?
When commuters were deprived of their standard routes, they were forced to think about new ways to get to work. As a result, city bike rentals increased by 50 percent, and many found new and more efficient ways to reach their everyday destinations.
Many London commuters failed to find their optimal route until they were forced to experiment.
Shaun Larcom and his colleagues found that the long-lasting
benefits of shorter commutes are worth more than the total travel disruptions during the strike.
This is surprisingly similar to product design, where the time it takes to properly think about a problem is negligible in the face of long-term results. The problem is that we often end up with suboptimal results, because we’re stuck with suboptimal assumptions.
As I mentioned earlier in the section about resilience, I assumed that Natural Language Understanding was a core part of what makes up a conversational experience. It wasn’t until I started experimenting with a simplified interaction model that I realized that what looked like a hard requirement, was in fact just a nice-to-have.
We don’t need to rely on external nudges to better understand how individual parts contribute to the whole. Asking ourselves what would happen if we took something away, is a surprisingly powerful method to gain new insights about the kind of problem a feature actually attempts to solve. Once we understand a problem, we realize that there is often more than one solution.
As Nikkel Blaase said, a collection of features don’t make up a product. Features are answers. Problems are questions. The quality of an answer is directly proportional to the quality of its question. Since problems are abstract and features are concrete, it is much easier for us to think in features than problems. It is the comfort we take in features that unknowingly gets us stuck with mediocre results.
Most of us don’t know what we want, but we all know pretty well what we don’t want. No one wants underground strikes but everyone wants faster commute times. Through removal, whether imagined or real, we are forced to focus on the problem rather than the solution. This can lead to surprising and new insights that often leave us with better answers than the ones we initially came up with.
Takeaway: By removing what we take for granted, we’re forced to experiment with what is left. When we deprive ourselves of options, we gain new insights about the value these options actually provided.