Building Products
People Enjoy Using

Ask people why they love a particular app and they'll struggle to name a feature. They'll say it feels fast, or it just makes sense, or it does exactly what they expect. Enjoyment in software is rarely about a single delightful thing. It's about the accumulated absence of small frustrations, the product never made them feel slow, stupid, or stuck.

That's the first thing to understand about building products people enjoy: most of the work is subtraction, not addition. You earn enjoyment by removing the things that would have spoiled it.

Get the basics invisible before you get clever

Not all improvements are equal, and the Kano model explains why. It sorts what a product offers into three rough kinds. Basic things are expected, nobody praises you for having them, but their absence causes real anger (the app doesn't lose your data; the button does what it says). Performance things scale with satisfaction, faster is better, more reliable is better. And delighters are the unexpected touches that create disproportionate joy but that nobody would have missed.

The mistake teams make is reaching for delighters while the basics are still shaky. A charming animation on a screen that loses your work isn't delightful. It's insulting. Enjoyment is built bottom-up: make the expected things invisible, make the measurable things fast, and only then spend effort on the surprises.

Enjoyment is emotional, and that's not soft

Don Norman, who named the field of user experience, spent his later work on exactly this: products don't just get used, they're felt. He describes how our response to a thing operates at several levels at once, the immediate gut reaction to how it looks and feels, the satisfaction of it working smoothly in the moment, and the longer story we tell ourselves about what using it says about us. A product that people enjoy tends to get all three right without the user being able to articulate any of them.

None of this requires whimsy. The most enjoyable software is often the calmest. It responds instantly. It remembers what you told it. It never makes you redo work. It fails gracefully and rarely. That restraint, competence that never draws attention to itself, is what reads to users as 'I like using this,' even when they can't say why.

Build for the person, not the feature list

The through-line is a shift in what you're optimising. Not 'what can we add,' but 'what is it like to be the person using this, on an ordinary day, in a hurry.' Answer that honestly and the roadmap changes. You stop shipping things that impress in a demo and start removing things that annoy in real use.

Products people enjoy aren't the ones with the most. They're the ones that respect the user's time, attention, and intelligence at every step, and make the whole thing feel like it was built by someone who imagined them clearly.