If you’re old enough to remember (Google it if you’re not), think about the original VCR, first built in 1985. Then take a look at today’s DVD players, or cable/satellite TV boxes or video game consoles. You’ll see a startling difference in the physical interface of the two models.

The VCR built in 1985 will have an abundance of buttons readily available on the faceplate of the unit, many of which remained a mystery, since the manual was lost roughly three minutes after the box was opened.

The DVD players of today, by contrast, will have only a few buttons for the key features people use: play, fast-forward, reverse, stop, and eject.

Take a look at an XBox or PS3 game console and you’ll find two controls: power and eject. These newer components have infinitely more features than those built decades before, but they’re all tucked away, some behind a panel or a sliding door, some only accessible onscreen via remote control.

The point is that these features and functions are accessible only when needed. They’re there when you need them, and are completely out of sight and (more importantly) out of mind when you don’t.

The lesson is this: while it’s important to ensure that the most frequently used features are readily available, you must avoid the temptation to put everything onscreen.

• Don’t load your menus or toolbars with rarely-used options.
• Don’t provide 12 categories when only 3 really matter to your users.

As most of us know, too much of anything is too much, and this is no different. Offering too many choices at the same time results in cognitive overload, which results in them choosing nothing. That’s known as choice paralysis among cognitive scientists, and it’s often the main reason new apps, sites or other digital products fail.

So it stands to reason that design and development teams – along with their client counterparts in Marketing and Product Development – should spend some serious time considering and analyzing which features can go “behind the panel” instead of up front on the faceplate, so to speak. And the main reason for that is because…

Our Reach Exceeds Our Grasp.

In terms of website or app features and functions, what we say we want is rarely what we actually want. Not because we lie or because our egos get in the way (although that does happen), but because of the physiological wiring of our grey matter.

For example, nearly every designer or developer has, at some point, been confronted with a stack of features from a client. And an equal majority has asked the next obvious question: “which of these features are most important?”

I’ll give you three guesses as to what the answer is, and the first two don’t count.

If you ask users the very same question, you’ll get the very same answer: all of them. While on the client side this can be motivated by worry or uncertainty about what people will want or will use, more often it’s a case of our innate need to have more choices.

The non-scientific-sounding version goes like this:

• When we have more information, we feel like we have more choices.
• Having more choices makes us feel like we have more control.
• Having more control makes us feel like we’ll survive better.

The survival instinct is programmed very, very deep into the rear part of the brain, what’s known as the reptilian brain. It’s where our survival instincts are. And as crazy as this sounds, lots of tiny little insignificant things trigger that survival response.

The inherent problem for people who make things for other people to use, however, is the fact that even though we want everything all at once, too many choices paralyzes the thought process. An overload of options actually paralyzes people or push them into decisions that are against their own best interest.

Sheena Iyengar wrote an excellent book in 2010 called The Art of Choosing. In it, she detailed what has come to be known as the “Jam” study, which does a really good job illuminating this phenomenon.

In a California gourmet market, Professor Iyengar and her assistants set up a booth of samples of Wilkin & Sons jams. Every few hours, they switched from offering a selection of 24 jams to a group of 6 jams. On average, customers tasted 2 jams, regardless of the size of the assortment. Now here’s where it gets good.

• 60% of customers were drawn to the large assortment, while only 40% stopped by the small one.
• 30% of the folks who sampled from the small assortment decided to buy – compared to 3% of those confronted with the two dozen jams.

Over the years, versions of that study have been conducted on any number of things, from retail chocolate to speed dating. And the results have been remarkably consistent. The net-net is this: at the point when a person is confident in a decision, he stops seeking choices. Once we find the core things we need, we basically ignore everything else.

So in terms of developing websites or apps or systems, the key takeaway is that less truly is more. Surfacing every feature possible only results in use paralysis.

So time – and money – has to be spent figuring out what really matters. Otherwise every dollar you spend after that, every hour your team spends designing or developing, is completely wasted. As such, I offer you…

One Guiding Design Principle Above All Others.

One of the easiest ways to put all of this into practice is to make sure every designer and developer involved in your project follows what I believe to be the single-most important principle of design:

All features (and elements) in a design are not equal.

In the 25 years I’ve spent with organizations of all sizes – across nearly every industry and in designing all manner of digital products – this single principle is the one that makes or breaks the finished product.

From mobile apps to ecommerce websites to web-based applications, this is the golden rule. It’s the single, core best practice that determines whether or not the product gets used and is considered to be useful. It’s the difference between true ROI and a wasted investment.

In almost everything you will ever design or build, roughly 20% of that product’s features will be used 80% of the time. So your efforts – from strategy to scope to design and development – should focus squarely on those features. This is not a new idea, and it’s not just my opinion.

The Pareto Principle, otherwise known as the 80/20 rule, has been proven true time and again since the early 1900s. I wholeheartedly suggest you check this out for yourself, but to summarize, the following maxims have been true for several hundred years now:

• 80% of a product’s usage involves 20% of its features
• 80% of a town’s traffic is on 20% of its roads
• 80% of progress comes from 20% of the effort
• 80% of errors are caused by 20% of the components

Successful companies like Apple, Google, Amazon and others use the 80/20 rule religiously to assess the value of features, the volume of content and the number of options available to the user at any given time. Despite what people may ask for, they really don’t want it all at once and they’ll really never use it all at once.

Focus on the 20% of your features that deliver the most value – both to users and back to the business – and save everything else for possible future releases. Make those features visible, accessible and obvious in the UI. Those are the places where money gets made or saved, and those are the places where user adoption and market share grow most consistently.

That 20% is what will make or break you. It’s what will cause people to Tweet and Retweet your praises (or not). It’s what will cause them to tell everyone they know about it because they cannot imagine they lived this long without it.