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…