Maybe Computers Should Not Always Be Easy To Use

"Easy to use" is the least examined phrase in software design. It sits in job descriptions, design principles, and usability scorecards, treated as an absolute good rather than a tradeoff.

Advait Sarkar's CHI paper Should Computers Be Easy To Use? asks what it costs. His claim: simplicity is a historical accident we started treating as a law of nature, and for some software it puts a lid on what the tool can become.

Two doctrines

The doctrine of simplicity is the one we all know. Software should be easy, natural, obvious. The doctrine of gradualism follows from it: give the user the smallest amount of learning, information and power you can get away with at each step.

Once you have a name for gradualism you see it everywhere. Hide the power until the user has earned it.

We measure for it too. Event tracking, funnels, time to first action. All of it points the same way: least possible friction, learn the tool as fast as possible. Fine as a goal, but it's the only one we instrument, so it's the one we design for.

Why nobody breaks out of it

Two products compete. Each can optimise for first use or for long-term use. Go for first use while your competitor plays the long game and you win the deal. So both go for first use. It's a bad place to end up, and neither can leave on their own.

Sarkar's best line: there is a moral hazard in making software look more usable by making it less useful.

You've seen this. Settings pages flattened into three toggles. A pro tool burying the thing you use forty times a day because it tested badly with new users. Nobody made a stupid decision here. The incentives did, and we need to be aware of this.

Praxisware

He has a name for the software that pays for this: praxisware. Big, feature-rich tools people use for entire careers. Excel, Photoshop, AutoCAD, Ableton. People build craft, habits and a bit of professional identity on being good at the specific tool.

Nobody expects a guitar to be easy on day one, and nobody would thank you for making it easier by removing strings. Easy to start can mean a low ceiling.

Nobody read the manual, so nobody wrote one

The "paradox of the active user" is the finding that people would rather poke around than read documentation. It's true. The tooltip took over from the reference guide, and the guide never came back.

The alternative

Not "make software hard". Sarkar calls it negotiated complexity: complexity that comes out of designing for long-term use, agreed with the people who use the thing daily, instead of set by first impressions.

The part I find useful is ahead-of-time learning. In-app tips show up while you're busy, so they feel like an interruption. Ahead-of-time learning isn't tied to a task. It widens your idea of what's possible, and that changes how you set the problem up. Someone who already knows formulas structures the spreadsheet differently.

In practice that's not a tooltip, and not a wiki nobody opens. It could be a document with the conceptual model in it, what the objects are and how they relate. Write that once and your power users stop guessing. Or a command palette, to teach the vocabulary while people work: a searchable list of everything the product can do, one keystroke away, with the shortcut next to each command. Every search teaches you a word and hands you a faster route next time.

The startup problem

Here's where the paper stops being enough for me. Photoshop and AutoCAD earned their complexity over decades, and they have a whole industry teaching them. Courses, certifications, endless YouTube. None of it was paid for by the vendor. It came for free once the tool got big enough.

I work in startups, on complex professional tools, and we onboard new customers every month. I can't tell them to invest six months first, and nobody is making courses about us. So "design for mastery" and "a new user has to get it this week" are both true at once. That's the actual job.

The way out, I think, is that the negotiation isn't simple against deep. It's who pays for the learning. Photoshop got it for free. If you're building something deep now, you are your own course industry, and that's a budget line.

Onboarding can still show the ceiling. Getting someone productive in a week doesn't mean pretending the shallow end is the whole pool. Teach the model early, including the parts they can't reach yet, so they know what to come back for.

What I take from it

AI makes this more interesting. A prompt looks like simplicity finally winning: ask for revenue by cohort, get the SQL. But it only takes away the syntax. It doesn't tell you a cohort query was worth asking for. The hard part moves from writing it to knowing what to ask for. An empty chat box tells you nothing about what's possible, so you get out what you already knew to want. That's an argument for teaching, not against it.

So if you're building for skilled professionals: ask what someone should do after a year, not after a minute. Make the power findable, with a command palette and real shortcuts. Give teaching a budget like any other part of the product.

Complexity is negotiated. Time spent learning against power you get back. Most teams never open that negotiation. They give it away, then wonder why their experts feel talked down to.

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.