Maybe Computers Should Not Always Be Easy To Use

"Easy to use" is the least examined phrase in software design. We put it in job descriptions, in design principles, in usability scores, and nobody asks what it costs. Advait Sarkar's CHI paper Should Computers Be Easy To Use? asks, and the answer is uncomfortable.

The claim is not that simplicity is bad. It is that simplicity is a historical accident we started treating as a law of nature, and that for one category of software it caps what the tool is allowed to become.

Two doctrines, not one

The doctrine of simplicity is the familiar one: software should be easy to learn, natural, self-evident. The doctrine of gradualism is its corollary: at every stage, give the user the smallest necessary amount of learning, information, flexibility, and power.

Name gradualism and you see it everywhere. Progressive disclosure. Onboarding tours that unlock one feature at a time. Low-code tools promising you never meet the abstraction underneath. Hide the power until the user has earned it.

It is also baked into our rulers. The System Usability Scale asks whether "most people would learn to use this system very quickly." The NASA TLX asks how much mental and perceptual activity a task required. Both are cited tens of thousands of times. If your only instruments measure the first five minutes, every decision drifts toward the first five minutes.

The prisoner's dilemma

The doctrine arrived through events, not evidence. Apple sold simplicity as a weapon against competitors' heavy manuals before it was a design finding. Then the Web trained users to expect document-like simplicity while web apps kept getting richer, leaving designers trapped, as Sarkar puts it, like frogs in boiling water between their ambitions and users' expectations. Subscriptions finished the job: when software changes continuously, why invest in learning a feature that might be gone next quarter?

Then the economics. Two products compete, each able to optimise for first use or long-term use. Optimise for first use while your competitor plays long, and you win at market. So both optimise for first use. That equilibrium is not the efficient one, and neither party can leave it alone.

Sarkar's sharpest line about the consequence: there is a moral hazard to make software appear more usable by making it less useful.

You have watched this happen. Every settings panel flattened into three toggles. Every professional tool whose new version buried the thing you use forty times a day because it tested badly with new users. Nobody made a bad call in isolation. The incentives made the call.

Praxisware

The paper names the software this hurts: praxisware. Feature-rich tools used intensively over long periods, often whole careers. Excel, Photoshop, AutoCAD, Ableton Live. Users develop craft practices and idioms, trade expert knowledge in communities, and build professional identity on competence with the specific tool.

Comparing that to learning an instrument is not a stretch. The paper's best example is algebraic notation, which replaced long-form sentences about mathematics and was harder to learn. Ordinary language was easier, which is exactly why it had been used for so long. A tool that starts easy can have a low ceiling; a tool that starts harder can make everything after the perspective shift easier.

Games are explicitly excluded, and the reason is good: games are played for their own sake, so players are intrinsically motivated to learn. Praxisware produces outcomes in the world. Game tutorial design does not transfer.

Simplicity is not universal

Euro-American design equates simplicity with whitespace. Popular Japanese sites are dense with text, and calling that cluttered applies the wrong measure: it reflects real linguistic and technical differences, and an environment that identifies simplicity with legibility and information richness.

The "paradox of the active user," the finding that people prefer tinkering to reading documentation, has justified forty years of not writing manuals. Work with the GenderMag framework found learning styles vary widely, and correlate with demographics including gender. A product built entirely on learning-by-doing does not just serve some users worse. It encodes a bias.

Negotiated complexity

The alternative is not "make software hard." It is complexity that comes from optimising for long-term use, negotiated with practitioner communities rather than dictated by first impressions.

Two parts are concrete enough to act on today.

Ahead-of-time learning. In-app teaching arrives while you are busy doing something else, so it reads as interruption. Ahead-of-time learning is task-independent and builds awareness of the possible, which changes how you frame the problem before you start. A spreadsheet user who already knows formulas plans the data differently from one who does not. The appetite is already proven: millions follow TikTok creators teaching Excel and Photoshop, on the sofa, with no current task to solve.

Usability as a property of the pair. Stop evaluating an interface alone. Define usability as a function of the interface plus its learning materials. Documentation stops being what you write after shipping.

What I take from it

This does not dethrone simplicity. For most consumer software the doctrine is right and the market feedback is honest.

It does force a question I had been skipping: which kind of software am I building? If people will use it for years, a five-minute usability test measures the wrong thing, and optimising against it makes the product worse in a way the test cannot see. That failure is invisible by construction.

So: ask what a user should be able to do after a year, not after a minute. Treat teaching as product surface with a budget. Be suspicious of any decision justified by new-user metrics on a tool whose users are not new.

Complexity is negotiated: the trade-off between time invested in learning a tool and the power it hands back. Most teams never open that negotiation. They concede it by default, then wonder why their professional users feel condescended to.

The paper is ten pages and worth reading in full: Should Computers Be Easy To Use? Questioning the Doctrine of Simplicity in User Interface Design (PDF), Advait Sarkar, CHI EA '23.