Six markers by which you can spot software that works for you - rather than the other way round. In plain language, without jargon.
Some programs you use every day and think: at last. Others you use every day and find yourself getting annoyed.
The difference is almost never in the features. It's in six places that hardly anyone can name - but everyone feels instantly. Here they are, each with what the research has to say if that interests you. If not, just read the bold headlines - they're all that matters.
Every time a piece of software asks you for something it could just as well answer without you, that's a small admission: We didn't think your day through to the end. You take care of that.
Good software suggests, you correct. It shows the likely date, the matching customer, the obvious answer - and you only have to object when it's wrong. Setup dialogs with ten required fields, empty forms with no suggestion, "How would you like it to look?" with no opening idea: all signs that the software hasn't done its homework.
The term is cognitive load - mental burden. The research (John Sweller, from the 1980s onward) shows: every additional decision a human has to make costs attention. When the software could know the answer itself, the question is pure waste - it pulls attention away from the actual problem.
Second keyword: Paradox of the Active User (Carroll & Rosson, 1987). Users don't read manuals. They try things straight away. Software that assumes the user will read up first loses them in the first 30 seconds.
You open the software for the first time. You see what's to be done next. You do it. No training, no tutorial, no little help texts to explain what a button does.
Every manual is a plaster on a badly designed spot. When a button needs a small explanation to appear before you know what it does, it's really an apology: "Sorry, I couldn't make it any clearer." With truly good software, the next sensible action is always in view. You don't search. You click.
Steve Krug's book "Don't Make Me Think" (2000) is still the benchmark for many designers. His point: when a user has to think about how to use software, the software has already lost. Attention belongs to the problem - not to the tool.
This fits with Jakob's Law (Jakob Nielsen): users already know hundreds of programs. They expect yours to behave similarly. Anyone reinventing the wheel forces relearning - and relearning costs time no one wants to spend.
Anyone who makes everything configurable shifts the work onto you. Which font? Which order of steps? Which default? A hundred questions before you can even start.
Good software makes those decisions for you. In 90 out of 100 cases, the defaults are the right answer. Those in the other 10 notice quickly and can adjust - but don't have to. Software that leaves every question open helps with none of them. It looks flexible at first, and then becomes exhausting.
There are four solid references here. Choice Overload (Barry Schwartz, "The Paradox of Choice", 2004): too many options paralyse rather than liberate. Hick's Law (1952): the time it takes to make a decision grows with the number of options.
Occam's Razor (a philosophical principle since the 14th century): when two solutions do the same thing, choose the simpler one. And Tesler's Law (Larry Tesler, Xerox PARC): every system has an unavoidable minimum of complexity. The only question is: who carries it - the system, or you?
What happens when your list is empty? Most programs write "No entries." Good software says: "Your enquiries will land here as soon as the first one comes in. Your customers get an automatic confirmation."
What happens when something goes wrong? Most show "Error 500" or "An error has occurred." Good software writes: "Something's a bit stuck right now - we've noticed and are looking into it. Your data is safe."
These thousand small spots are the difference between finished building and finished thinking. You don't notice them consciously. But they're the reason you trust one piece of software and not another.
The Aesthetic-Usability Effect (Kurosu & Kashimura, 1995; replicated many times): software that looks well thought-out is also perceived as easier to use - even when it's objectively just as hard. Care in detail generates trust, and trust generates patience with small problems.
Plus the Peak-End Rule (Daniel Kahneman, Nobel Prize 2002): memory forms from the peak and the ending of an experience - not from the average. A good error message at the end of a botched process is worth more than ten smooth clicks before it.
With good software, nothing feels like waiting. Click - and it's there. Type - and it happens. No loading spinner that stretches time. No "Please wait..." that pulls you out of doing.
There's a study from 1982 that shows the magic of it: when software responds in under 400 milliseconds, your mind forgets there's a computer there. You're in flow. Over 400 milliseconds - you're waiting. That's the difference between a tool and an obstacle, and it lies in a fraction of a second.
The phenomenon is called the Doherty Threshold, described by Walter Doherty and Ahrvind Thadani in the IBM Systems Journal in 1982. They demonstrated: under 400 ms, productivity doesn't rise linearly but in a jump - because the user stops waiting for the computer and starts thinking with it.
Related is the concept of flow (Mihály Csíkszentmihályi): a state of complete concentration in which doing and awareness merge. Software that stutters destroys flow systematically. Software that flows away builds it up.
When your new tool is really good, you start to hate other programs - even though they do exactly what they've always done. You've just seen them, for the first time, with some distance.
Suddenly you wonder why your online banking takes four clicks where one would do. Why your accounting program has fields it could fill in itself. Why the printer asks you about format, orientation and paper tray, instead of simply remembering the last setting. The friction was always there - you just didn't notice it, because you had nothing to compare it to.
Here the evidence thins out - this is more an observation from the industry than a proven effect. The psychological keyword is anchoring (Tversky & Kahneman, 1974): we don't judge things in absolute terms, but in relation to a reference point. Whoever has once worked with good software has a new benchmark.
In tech circles, there's a saying: "After Linear, Jira feels broken." Linear isn't objectively better - but anyone used to it can't go back. It's not a law of nature, but a good indicator: if after three months you find other tools worse than you used to, your software has done something right.
Exceptionally good software rarely comes about by chance. It comes from taste - and from the courage to say no.
No to features no one needs. No to target groups that don't fit. No to the thirtieth configuration option that only the initiated understand. The people who build really good software are users of their own product, and they notice every day when something snags. Mediocre software comes from trying not to disappoint anyone. Exceptional software comes from being exactly right for a few.
We don't promise that every line of our code is perfect. But we promise to work to these six criteria - and to speak up when we notice one of them is being violated.
How we clarify the actual problem before building is on Before we build, we figure out what's broken. Why we work in two stages - tools first, AI second - you'll find on Tools first, AI second. Which hurdles most often stand between good software and its use is on The biggest hurdles rarely lie in the technology.