Design for the Common Case

There is a rule I find myself repeating at work, often enough that colleagues could finish the sentence for me: in software product design, you don’t design for the most exotic cases. You design for the most common cases, and you add the exotic ones only if enough people complain about not having them.

Said out loud, it sounds almost rude. Somewhere out there is a user with a genuinely unusual need, and my rule tells them to get in line and complain. But I work on HR and payroll software for companies across the Gulf, and payroll is edge cases all the way down: employees paid in multiple currencies, unpaid leave taken mid-cycle, backdated salary changes, end-of-service calculations that turn on when a contract was signed.

The trap is that nobody ever asks you to bloat a product. Every exotic case arrives with a human being attached: a customer with a real problem, a salesperson with a deal that hinges on one missing checkbox, an adviser with a strong opinion. Each request is small and reasonable on its own. Bloat is what happens when you say “yes” to hundreds of individual, reasonable requests, without carefully managing the bigger picture.

What the usage data says

When Pendo analysed feature usage across 615 software companies for its 2019 Feature Adoption Report, it found that 80% of features in the average product are rarely or never used. Pendo put a price on the waste too: an estimated $29.5 billion of public cloud companies’ development spend going into features that mostly sit there. Four out of five features, built and paid for, waiting for users who never arrive.

Microsoft learned the same thing from its own telemetry. Before designing the Office 2007 ribbon, the team measured what people actually did in Word 2003. Out of the thousands of commands available, the top five — paste, save, copy, undo, bold — accounted for around 32% of everything users did. Paste alone was over 11% of all command use, more than double second-placed save. Word could do mail merges, macros, and master documents; what humanity mostly wanted was Ctrl+V.

I find these numbers clarifying rather than depressing. From the user’s side, the common case essentially is the product, and every hour spent polishing the long tail is an hour not spent making paste feel instant.

Complaints are data

The second half of the rule — add the exotic cases only if enough people complain — sounds passive, possibly arrogant. But if you look past the crude wording, there is a lot of truth in there.

A feature request made before the thing exists costs the requester nothing. A complaint means someone reached for the feature, found it missing, and cared enough to tell you. Complaints are revealed preference.

Apple ran this play in public. The original iPhone shipped in 2007 without copy and paste; one of the original engineers later admitted the team simply ran out of time to do it properly. Users complained, loudly, for two years. When iPhone OS 3.0 finally delivered it in June 2009, Apple didn’t apologise — it put copy and paste in a television advert. Two years of complaints had told the company exactly what the feature was worth and exactly how it needed to work.

Where the rule breaks

Some caveats:

First, the evidence deserves the same scepticism as a feature request. The most famous statistic in this genre — the Standish Group’s claim that 64% of features are rarely or never used — traces back to a 2002 conference talk and a sample of four internal applications, as Mike Cohn has spent years reminding people. The Pendo data, drawn from 615 live products, is sturdier. But the honest summary is that we know the long tail is barely used, not precisely how barely.

Second, and more importantly, the rule covers conveniences only. Some exotic cases are obligations: security, accessibility, statutory compliance — and in payroll, correctness itself. An edge case in a document editor is a missing menu item; an edge case in a payroll run is a person’s salary arriving wrong. The employee on the receiving end does not experience that as exotic. Complaints are a fine instrument for missing conveniences but useless for harms: nobody should have to complain that their pay came out wrong before the case gets taken seriously. When an edge case touches money, law, or safety, you engineer it no matter how few people ever hit it.

There is also a gentler version of the same point. Designing for the common case doesn’t mean the exotic must be absent, only that it must be out of the way. Jakob Nielsen has been teaching this since 1995 as progressive disclosure: show the few things most people need, and let the rest stay findable without taxing everyone else. The advanced settings can exist; they just shouldn’t stand between a payroll manager and the pay run.

What I actually do

So here is the rule as I live it: Make the common case fast, obvious, and boring — boring the way running water is boring. When an exotic request arrives, the default answer is “not yet”, written down rather than forgotten. When the same complaint comes back a third time from people who pay us, it has stopped being an edge case; it has become common, and it gets built properly. And when it ships, tell people about it the way Apple told people about paste — because a feature built in response to real complaints is the rare feature you already know somebody wants.