Much is made in the business world about the 80/20 rule. Also known as the Pareto principle, the basic idea is that in many phenomena 80% of consequences stem from 20% of the causes. Wikipedia has a good discussion of the principle, its myriad applications, and its common misuse and abuse. (I should have called this post “The Principle of Factor Sparsity”; that would definitely have merited an honorary doctorate down the road…)
80/20 and its variants play an almost mythical role in all facets of mainstream software design. You’ll hear that 80% of users only use 20% of the features. Or that 20% of bugs account for 80% of the problems people find in released software. Of course, none of the numbers are exact, and people are quick to point out that the principle is in effect even when the numbers aren’t exactly close.
For example, it turns out that it’s more like 5% of the crashing bugs account for 95% of the error reports people send. Is this still the 80/20 rule? Can I just substitute any numbers and there’s still some validity to the model? If so, I’ll coin the Harris Principle–that X% of consequences stem from Y% of the causes. It’s bound to be applicable to an even wider array of scenarios!
Sarcasm aside, there is something valid to be learned from the 80/20 rule. In general, in mainstream software, we do try to design around how the majority of people expect it to work. In such a broadly used tool as Word or Excel, we hope we can suit more like 90% or even 98% of the people; the value of the data we gather from the Customer Experience Improvement Program is that we really can tell how we’re doing.
One of the challenges of designing a piece of software for 400 million people is that even if you are extremely successful with a design–even if you totally hit it out of the park and delight 99% of your customers… well, you still have roughly the population of New Zealand who think you made the wrong decision.
The good news is that although most design decisions fall somewhere along the lines of 80/20, it doesn’t have to be a zero-sum game. There’s often ways to satisfy the 80% and the 20% both because they work in different ways of have different expectations of the software.
For instance, sometimes the 80% are “normal” users and the 20% are “expert” users. In order to satisfy both groups, you must determine how to enable expert-level functionality in a way that adds no complexity for people who have no need for it. It can be done, but it takes some thought.
I think a good example of this is the “Lock Toolbar” feature in recent versions of Internet Explorer and Windows. You can’t drag the toolbars around unless you right-click the toolbar and uncheck “Lock the Toolbars” on the context menu.
For “normal” people, the toolbars just work the right way. They don’t move unexpectedly, and they don’t end up mysteriously disappearing or floating in the middle of the screen. The software feels more predictable, and because most people don’t right-click on the toolbar, the complexity is hidden from them.
On the other hand, for the expert user like me who does want to move around their toolbars, finding the setting to unlock them is just a minor inconvenience. The Windows taskbar adopted the same design in Windows XP and I believe this is a good thing. (No more explaining to people how to get the taskbar back on the bottom of the screen!)
The hardest problem in user interface design is when you come face to face with the 50/50 rule. Although rare, occasionally you will discover a a situation in which the needs and wants of half of your customers are diametrically at odds with that of the other half.
Here’s a simple example of a 50/50 scenario in the Outlook keyboarding model. Everyone in the world knows that CTRL+F performs Find within a program, right?
Well, actually, that’s the newfangled shortcut, standardized around 1993. Before that, most programs used F4 as the standard shortcut for Find. (Just like CTRL+X, C, and V used to be Shift+Del, Ctrl+Ins, and Shift+Ins before they were changed in Windows 3.1.)
So, with F4 firmly cemented as the shortcut for Find, early 1990s-era Microsoft electronic mail products used CTRL+F for Forward. Of course, forwarding e-mail being one of the most common things you do in a mail program, in retrospect that design decision makes perfect sense.
Fast forward to today. Millions of loyal customers have learned to rely on CTRL+F in Outlook to forward mail and brace at the thought of it going away. Millions more are confused by their inability to use CTRL+F to Find in Outlook and can’t understand why new mail windows keep popping up. “F4?!?!?” they gristle under their breath.
What to do? If you change CTRL+F to Find, millions of people have their productivity impacted for no positive gain at all. If you don’t, millions of people are confused by your software and find it hard to use. Of course, you could make it a customizable option, but experience and data show that hardly anyone would think they could change it. There’s no easy way to satisfy both groups out-of-the-box.
When the 50/50 rule bites you, it leaves a mark.