The 80/20 heuristic states that in most computer systems, you spend 80 percent of your time in 20 percent of the code. Another way to say this is that 80 percent of your users will spend most of their time using about 20 percent of the application that you have so painstakingly constructed for them. This leads to a lot of meetings where we spend time trying to guess which workflows we must support in order to please the “80 percent” users. In my experience, concentrating on the 80 percent users allows projects that have limited resources and short schedules to get done and ship something that most users will be happy with.
Having watched this process a long time, I have noticed one paradoxical difficulty with applying this heuristic. The problem is this: many users (mostly the dorks) are convinced they are in the “special” 20 percent rather than the happy 80 percent, and you can’t do anything about it.
I have a lot of experience with the mindset that self-selects into the special 20 percent because I spend a lot of time in indulging in dork hobbies. In fact, this particular sort of delusion is related to the OCD that also afflicts those who buy technical gadgets.
In general, what I will call “the 20 percent delusion” is a syndrome in which the dork dreams up requirements that fall outside those of the 80 percent workflows that are absolutely critical to whatever it is they think they want to get done with the device. You see this all the time.
For example, in photography, there is the creature who is completely paralyzed when he needs to decide what equipment to carry for a particular photo project. He thinks he must be ready for everything because he really has no specific purpose in mind. Therefore, instead of the single body and one lens that he needs, you will find him walking around Paris pulling a rolling suitcase with the EOS-5d, a Rebel for backup, 3 huge zoom lenses, 4 “fast” prime lenses, macro equipment, two flashes, a light stand, umbrellas, radio remotes, and a tripod strapped to his wife. I saw this guy once. He had just set up his Pentax 6×7 (which is in the roller along with the digital stuff) in front of the Arc de Triomphe at noon taking a bad shot of the Arc with a white sky behind it.
The photo neurosis takes people in other directions too. The internet forums are full of people who are convinced they need the most robust, most flexible, most expensive and heaviest “pro” equipment. There are usually one of several rationales presented for this need for “pro” equipment. For example:
1. I take pictures in manly man environments and no wimpy-ass plastic body will hold up. I need my camera to be a solid 15 pound chunk of metal. Also, there should be no electronics in it, because I might get stuck in a cave 2000 feet underground where there are no batteries.
2. All my favorite pro photographers use German lenses, so my camera must use German lenses. Also, it must be able to run for 5 years without needing to change the batteries for the light meter.
3. I take pictures of such a wide variety of subject matter that I must have a completely modular 18-piece camera kit that I can “configure” any way I need. Also, it must be able to run without batteries, because I might be in the desert away from human contact for months at a time.
The neurotic need for configurability comes up in other contexts besides photography. You see it all the time in computing. One favorite target of my hatred, the X11 window system, is so configurable that they didn’t even specify the user interface that it presents to the user at all. This is great for a research system on user interfaces, but it pretty much sucks for everything else. The problem is that for more than a decade now, the design discipline that puts flexibility before functionality has resulted in huge amounts of work going into X11-based desktop systems that are very configurable but completely unusable.
This attitude extends naturally into the realm of computer hardware. Historically, computer hardware used to be something that you tinkered with. I knew people in high school who built single board computers from parts, because at the time this was the only way to get something cheap. This led naturally to people who tinkered with the insides of their Apple II, or IBM PC. If you wanted to tinker, things like expansion slots, prototype boards, and user editable operating system kernels made a lot of sense. In those times, that was what the 80 percent user wanted to to.
Of course, all of this has changed. Computer systems these days want to be a turnkey commodity; something that you just turn on an use. And yet the hardware design is still driven by the people who think they want to tinker. Marketing literature that speaks of expandability and flexibility still tries to drive the purchasing decision from the mindset of the guy with the soldering iron, even though only a tiny fraction of users actually care about that stuff.
The truth is, most people would be happier with a box that they could plug in, turn on, and use. Of course, when companies try to actually build a machine that can do this, they get slammed by the 20 percent crowd for building an underpowered, inflexible piece of crap that you can’t upgrade. The result is that the industry is still dominated by hardware that has a lot of useless flexibility built-in, even though no one really wants it.
So, how can you tell if you sometimes fall into the delusional 20 percent? When was the last time you saw a really excellent tool that would make a big difference in your life, only to reject it out of hand with a sentence that begins with the words “if only”. Yeah, I’ve done that too. It’s OK. There is still hope. Here is what you do.
First, deconstruct the “if only” sentence. Then sit down and really evaluate what you are asking the tool to do, and decide if you really really need it, or if you just think you need it. It can be helpful here to collect some quantitative data. Mark down the number of times you really need the “if only” feature over some period of weeks or months. My experience is that usually this number will be close to zero, and you will find that the tool in question really does do everything you actually need it to do.
For example, one of my “if only” hang-ups is that I can’t stand the idea of the meta-data in my digital pictures not being stored in the picture files themselves. I used to have a really well-argued rationale for this, but I can’t remember it anymore. The result was that I resisted moving to an integrated photo workflow solution like Lightroom even though the app is fabulous to use and much faster and simpler than what I used to do. Having thought about this harder, I think I have convinced myself that I don’t really care about this problem anymore. So now I can be happy using Lightroom, and I have reduced the number of tools I use for my photo workflow significantly (truthfully: I still use Photo Mechanic for import and initial tagging, but that’s just because I’ve paid for it and I haven’t figured out exactly how to remove it yet).
There you have it. One small secret on the path to happiness: analyze your life, and figure out how to get yourself out of the 20 percent and into the 80 percent. I have worked hard over the last ten years to apply this principle in my computing and to some extent my photography and it has served me well.
I strongly suspect that this is one of the main reasons for Apples’ recent successes. *All* of their hardware (and Software) doesn’t really care about configurability – as an end user, you get your system, and that’s it. (I.e. the old saw “How do you upgrade a Mac? Simple! Throw old one away, buy new one!”)
The genius in there is that it’s still *possible* to configure things, and the fact that it’s hard actually *appeals* to the 20% crowd.
Now if I could only figure out what 80% my users cared about….
Another way to say this is that 80 percent of your users will spend most of their time using about 20 percent of the application that you have so painstakingly constructed for them. This leads to a lot of meetings where we spend time trying to guess which workflows we must support in order to please the “80 percent†users.
The problem is, only 20% of that 20% will be common across all 80%. The 80% will be using only 20% of your app, but it’ll be a different 20%.
It’s true. The whole trick is trying to guess which of all the 20 percents are the most important, so you don’t have to build 100 percent of the 20 percents to cover the 80 percent users who only want their 20 percent.
To psu’s point, finding that 20% that fits the bill is part and parcel of proper design. Proper design requires a deconstruction of what the app is trying to solve — no more no less.
The proper approach in my mind for those dorks who want more is to provide an extensible language say like python or ruby as part of the app. That way if Mr. Dork wants it he can cobble it together themselves. If they don’t have the talent to do so? So sad, have a nice day!
As to your complaint about X11. Well yeah it was a kludge from the start. But don’t necessarily blame the X11 team. Go back and blame the various Unix vendors over the years, most now dead. Blame them, for they were the ones who wanted the extensions and expanded widget pallete to add some discerning marketing differentiation. Ha! But considering all the fluff that’s been added a simple startx simply configured for a color depth of 24 is a pretty rock solid tool kit.
The proper approach for dorks who want more is to encourage them to go buy a different product. Then they are somebody else’s problem.
The challenge of product design is to figure out what you can build, and figure out what you can sell, and come up with a spec that does as good a job of intersecting those two things as you can. Once you’ve done that, you need to have confidence that your plan is good and execute it. Except for certain very carefully defined classes of products, time spent building in extensibility layers as a hedge is generally time wasted. Instead of bolting on extra layers to please people who don’t actually like the product you decided to build, spend your time polishing the parts that matter to the people who actually do want to buy the product you decided to make.
iPod Shuffle: Doesn’t do anything except play tracks in random order, for pretty close to the price of a full-function MP3 player of another brand.
But it’s really small and foolproof. 80% wins again.