Reprinted from TidBITS by permission; reuse governed by Creative Commons license BY-NC-ND 3.0. TidBITS has offered years of thoughtful commentary on Apple and Internet topics. For free email subscriptions and access to the entire TidBITS archive, visit http://www.tidbits.com/ iTunes and the 80-20 Rule Michael E. Cohen The '80-20 Rule' ' you often see it cited in discussions of software usability, usually in support of calls for simplifying complex apps or for breaking them apart. I most recently heard it come up in the entertaining and informative discussion that Kirk McElhearn and Chuck Joiner had in [1]a recent MacVoices interview about Kirk's '[2]Take Control of iTunes 12: The FAQ.' At issue was the ever-expanding feature set of Apple's iTunes, which, with the addition of Apple Music and Beats 1, has become increasingly difficult for users to use and navigate, turning it into what Marco Arment colorfully described as a '[3]toxic hellstew.' Kirk brought the rule up to drive home the point that most iTunes features are not used by most iTunes users, and that the app could use a complete overhaul to make it more manageable and accessible. But what is the '80-20 Rule' to which Kirk referred? Lately, it has come to mean something like this: '80 percent of an application's users use only 20 percent of its features.' Lurking behind this 'rule' is the idea that developers could make apps far easier to use and far more reliable if they devoted their time to clarifying and optimizing the 20 percent of features that the 80 percent of users most often use. Like many such rules, such as 'wait 30 minutes after you eat before you go swimming' or '[4]never go in against a Sicilian when death is on the line,' there is a kernel of sense behind the rule: [5]as some studies have shown, for many systems a large percentage of functions are seldom, if ever, used. But the systems in question in those studies tend not to be widely used consumer apps but those being developed for specific business or engineering purposes, and the studies are mostly interested in examining how to get the most bang for the in-house development staff's bucks, and not about usability. In any case, widely used consumer apps ' and by 'widely' I'm talking about apps used daily by millions of users ' are rather different creatures than, say, an enterprise's in-house inventory control and management system that might have only a few hundred users at most. In fact, the original '80-20 Rule' was not a rule at all, but an observation by 19th century Italian economist Vilfredo Pareto, who noticed that 80 percent of Italian income was received by 20 percent of the Italian population. It was promoted to a '[6]principle' by [7]Joseph M. Juran in 1941, who suggested that most results in any situation are determined by a small number of causes. All of which is to say that the '80-20 Rule' is really just an observation, and one that has less to do with usability than with the effort involved in developing and debugging complex systems. Nor can you rely upon the magical 80-20 ratio: depending on the app and the user, it might be 95-5, or 60-40, or some other ratio. 80-20 is only a ballpark figure, and the ballpark dimensions themselves vary from team to team and from sport to sport. I have little doubt that any one iTunes user is apt to use only a small number of the many features that iTunes offers. The problem is that, for iTunes as for any app, you cannot assume that the small number of features used by one user are the same features as those favored by another user. In addition, the very idea of a single 'user' as some sort of Platonic ideal creature whose needs you must meet to have a successful app won't get you very far when it comes to making an app usable. Most usability analysts worth their salt don't even envision a single user at all. They often develop a variety of 'personas,' imaginary folk who come with specific needs, goals, backgrounds, and tastes, and they look at an app's feature set and implementation in terms of each of those personas. What's more, when it comes to usability testing, analysts try to match actual test subjects to one or more of those personas: test results are seldom considered reliable if the tests don't encompass a range of different users that match the range of personas. Nor are the analysts' personas themselves cast in stone: they, too, are developed and expanded and refined as more information about real breathing, living human users of a product is acquired. Usability analysis, in short, is a complicated blend of science and art, and applying it reliably to any particular app is usually fraught with caveats. And the larger and more varied the population of users of that app, the more difficult it is, and that is even when you don't consider the business goals that the app must also meet for it to be considered a success. Kirk, in the MacVoices interview, wisely employed the '80-20 Rule' only to illustrate how users might find the bevy of features offered by iTunes confusing, and he smartly acknowledged that coming up with a list of substantive suggestions that would finally 'fix' iTunes to the delight of users everywhere, given how many different user needs it has to meet, was beyond him. It may be beyond Apple as well ' iTunes has seen significant user interface changes in each of its last three major incarnations, a level of variability that generates its own confusions. That is not to say, of course, that Apple shouldn't keep trying: the company's $200 billion cash pile could certainly pay for a lot of formal usability analysis and careful engineering. However, simple rubrics like the '80-20 Rule' are not apt to get the company very far in such an effort. References 1. http://www.macvoices.com/macvoices-15157-kirk-mcelhearn-takes-control-of-itunes-12-and-apple-music/ 2. http://tid.bl.it/tco-itunes12-tidbits 3. http://www.marco.org/2015/07/26/dont-order-the-fish 4. http://www.imdb.com/title/tt0093779/quotes 5. http://www.featuredrivendevelopment.com/node/614 6. https://en.wikipedia.org/wiki/Pareto_principle 7. https://en.wikipedia.org/wiki/Joseph_M._Juran