Designing for power laws
Ben Hyde makes the great point that systems are often designed with an implicit assumption of uniformity in traffic loads, when in fact these loads usually follow a power law. Ben focuses mostly on network design, but this point is just as valid for application design.
It’s understandable that this happens: you sit down to design the system, and figure “OK, if a user does X then we’ll look up record Y and do Z” when in fact the reality is that most actions will be a small subset of the possible ones and will be initiated by a small subset of users. Keeping this in mind can change your design in a major way; *not* taking this into account can frustrate the users who account for the majority of activity and whose opinions have a big effect on the reputation of your app. At an even higher level, this gets beyond performance and into the realm of features. Specific solutions for dealing with “power users” such as “expert modes” have a mixed reputation, but ignoring the problem won’t make it go away.
It’s interesting that this point runs contrary to the usual “long tail” argument that focuses attention on the *less* active users or objects. I guess the lesson is that we should design for both the head and the tail, and not fall into the trap of designing for a mythical “average user” who doesn’t really exist.
April 10th, 2006 at 5:13 am
“Keeping this in mind can change your design in a major way; *not* taking this into account can frustrate the users who account for the majority of activity and whose opinions have a big effect on the reputation of your app. At an even higher level, this gets beyond performance and into the realm of features.”
When I was designing (what is now) lavalife.com (it was called webpersonals.com then) we had access to very exact information about the telephone based service (telepersonals) the web version was to be integrated with. It did in fact include information about feature use per user, per demographic, per psychographic even (lots of psychos on dating services;-)). Power users, especially women, were the target for everything innovative we did. Their opinions had the most effect on the reputation of the service. It did in fact change the design in a major way.
That was ten years ago, and I’ve developed the principle very rigourously since. Instrumenting user interfaces to log feature use is quite important. Among other things, it tells you when to offer help, what “tips” to pop up if the user lets you, etc.. Though a lot of users hate Microsoft’s Paperclip Guy, a surprising number like him just fine.
Designing for the head and tail entails (hah!) knowing the most bizarre and unreasonable visions, and the most horrific service-gone-wrong nightmares. Focusing attention only on statistically valid best cases and worst cases is a mistake: you’ll lose your outliers, and fail to discover when a vision becomes viable, or when a user deems a nightmare to have happened (thus making them your new best case and worst case). There’s no legitimate scenario analysis without outliers that are so far out you don’t believe in them at all. After all, out there, SOMEONE believes in them.
Leadership is a lot like design in that leadership is required when things are going really well (to make sure the maximum exploitation is achieved) and when they are going really badly (to save the sinking ship), and design really is constrained by the worst damage that can be done, and not preventing the best result that can be achieved. Both are creative activities, and neither of them can be done based solely on the numbers. If you have good numbers, you’re going to be choosing a small subset of users to be the gurus or masters that you are enabling, and you’ll do enough testing with naive users to discover how difficult it is for others to follow in their path. Alan Kay nailed it: “simple things should be simple - complex things should be possible.” Those two constraints, plus “users should tend to want to try more complex things rather than restrict themselves to simple things because the behaviour of the system when they attempt complex things scares them”, add up to as much design method as I think can actually be stated as a ruleset. More than three design rules never get followed anyway…