A few years ago, I heard a joke from a pilot instructor friend about single-engine airplanes in the aircraft industry. He said that some pilots like to call them “air conditioners.” When they stop working, wait, and watch: you will see how the pilot starts to sweat.
This joke is just a little anecdote about something that it’s a fact. Single-engine aircraft are not as reliable in emergencies because when their engines fail, the only real source of propulsion is effectively gone.
This scenario is one of the main reasons why the aircraft industry has avoided exploring any single-engine design for jet airliners. (I want to clarify that I’m referring exclusively to jet-propelled aircraft, not aircraft powered by propellers).
Although modern jet propulsion technologies can easily be tailored to generate enough thrust to lift a passenger jet airliner with a single-engine (which will result in massive maintenance cost savings), such kind of aircraft will eliminate one of the concepts that make air travel one of the safest forms of transportation: engine redundancy.
Two engines can increase the safety of the aircraft concerning engine propulsion availability and can help with backup emergency strategies like asymmetrical power (which can be essential support in a situation where hydraulic control is partially lost.)
The concept of redundancy, however, is not exclusive to aircraft. Many digital and technology products rely on particular redundancies to improve their final user experience.
These are what I call “Designed Redundancies.”
Designed Redundancies are usually a set of two (sometimes more) user flows or interface mechanics that allow a user to achieve the same result.
Designed Redundancies can be helpful with some troubling aspects of software design. For example, a Designed Redundancy can aid discoverability or be a sound fallback system to increase accessibility.
Some of the most common Designed Redundancies are the ones that exist with computer peripherals, in particular, mouse and keyboard. These two peripherals share a wide range of input functionality. In many cases, mouse left clicks and return keystrokes are interchangeable.
Also, the arrow system of a keyboard can often traverse and scroll a screen user interface the same way a mouse does.
But as beneficial and evident as they sound, Designed Redundancies can be very complicated and sometimes critically harmful to the user experience. Learning how to design useful and helpful redundancies can make a huge difference in solving severe design problems.
One example of poorly Designed Redundancies is the ones you can find in text processing software like MS Word.
MS Word comes with hundreds of layout and formatting options. Many of them are functionality duplicates that aim to address two different use cases with the same endpoint.
With the right scrutiny, this can be beneficial for the user since the software can adjust to different behaviors. However, in the MS Word case, most of these redundancies are the consequence of a malformed product backbone that increases the difficulty of deprecating old features.
This is a critical aspect when it comes to designing practical and useful redundancies. Many people try to defend the idea of concurrently keeping two competing features in a product since this can help existing users with change.
There’s a fear that by introducing sudden change, you will annoy and lose your existing customers (newsflash: if you’re changing is because there’s something wrong in the first place).
New features that are created to replace old ones should do exactly that. Despite the potential backlash from completely replacing a legacy feature, it is better to deal with and address this individually.
Keeping two redundant features for the sake of avoiding confrontation with your user base is counterintuitive. This approach usually creates confusion for new users and alienates existing ones.
Redundancy should never be a product delivery strategy. This is the most critical difference between a harmful redundancy and helpful Designed Redundancy. The former is created as a response to undesirable product evolution effects, while the latter is consciously designed to increase the performance and delightfulness of the product.
Designed Redundancies in Modern Technology
Designed Redundancies have been around for quite some time, but only in recent years became a prevalent user experience concept.
As modern technology has become more sophisticated, learning these technologies has become an equally complex task.
Many new technology products rely on well thought Designed Redundancies to increase their performance, ease of use, and overall satisfaction. Here is a list of Designed Redundancies examples in modern software and tech:
When playing a song on Spotify (iPhone), you can skip the current song by either using the skip button or swiping the album covers.
When browsing an Instagram feed, you can like a photo either using the dedicated ‘like’ button or by double-tapping the actual image.
The Apple Watch allows you to scroll and navigate some screens by either touching the screen or turning/winding the watch crown.
The Nintendo Switch has several form-factor redundancies that provide multiple modes and experiences with a single device. Nintendo relied on redundancies to create a console that adapts to an almost infinite amount of user conditions and behaviors from the symmetrically redundant joy-cons to the integrated device screen.
The Controversial Nature of Designed Redundancies
Designed Redundancies can be powerful mechanisms to enhance the speed, discoverability, and learnability of your products. In some cases (like in the Nintendo Switch case), they can be a core component of how your product delivers an experience.
However, redundancies are usually seen as a bad design paradigm. I can’t recall the number of times that I have been on a design review or critique in which someone presented a redundancy unsuccessfully.
Redundancies are seen as a contradiction to other more prominent paradigms like Simplicity. It’s easy to see how a not very well thought redundancy can make a product exponentially harder to understand and use.
But this shouldn’t discourage designers and product professionals from exploring and design useful redundancies. When created and used correctly, they can make a significant impact on the ultimate user experience.
The concept of Designed Redundancies can be a helpful resource to unblock design issues related to the general flow progression of a product. Although they are often misunderstood and often can be the source of confusion, they can become an essential differentiator of the product itself when designed mindfully and implemented correctly.
One excellent way to identify the difference between a harmful redundancy and helpful Designed Redundancy, it’s to determine its primary driver and how it fits contextually in a product.
If the redundancy feels and sounds like a band-aid solution or emerged from a non-user obsessed reason, the redundancy is likely harmful.
On the other hand, a positive Designed Redundancy will feel an integral part of the design contextually. By removing it or altering it, the product will likely lose its perceived performance/delightfulness.
Think about something like the wireless charging capabilities of the most recent iPhones and modern Android devices. Wireless charging is a redundant feature, but its addition improves the usability of the product and allows the product to be more adaptable to the user’s behaviors.
Not every Designed Redundancy needs to feel as crucial and vital as having two turbine engines in a jet airliner, but at the very least, they should feel useful enough to be noticed if they are gone.