I work on the Windows Media Center (MC) Team as a Program Manager.  Most of my work is focused on the large scale integrated user interfaces including information architecture, interactive models and navigation, ‘look&feel,’ and the overall user experience (UX). This here is my first blog contribution.

I’ve been stuck on the 80/20 rule lately.

I first learned about this rule long time ago, in school, as the Pareto Principle. One is likely to recognize the gist behind it if I used a couple of its most typically utilized statements:

• “20% of the employees do 80% of the work” or
• “20% of the customers generate 80% of the revenue.” 

The abstracted notion is that the minority input in any system can often be responsible for the majority of the output in the same system, or better yet, to quote what I found offered on one of the related sites, “vital few and trivial many.”

This powerful and handy 80/20 blurb is frequently used around our MC hallways, and I am starting to get curious about its many layers and incarnations and just how true to and consistent with the rule’s actual premise those are.

For example: Does the 80/20 rule have anything to do with time-driven schedules? If we didn’t have time-driven schedules, but rather feature-driven schedules, how would the rule apply then (would we go for the full 100)? Or, is the rule agnostic to the type of the product cycle approach and it simply focuses on a good design practice—one that states that no good product should try to be everything to everyone?

But, employing the 80/20 rule as a good design practice proves difficult in a system that, for example, covers a broad-ranging audience—say, novices to experts. Because they are so different, one inevitably ends up optimizing for one audience type over the other. This has certainly been my experience working on MC. Unlike many other products I've been a part of, MC ensures to optimize for the novice range (in part a design philosophy and in part due to the added difficulty of remote control operated 10’ UI). This is all good as it is very likely going to encourage simple and easy-to-use product design, but it also inherently limits the scope of offering, focusing on the basic features only. And for this reason, it is also likely going to cause dissatisfaction and annoyance on the experts end as they expect more power features.

So, when we end up making an in-out call for a feature and we do so with the 80/20 tagline, are we practicing good design practice or are we applying prioritization due to a time-sensitive schedule? And, in either case, are we in accordance with the actual meaning of our tagline?