On Building Software That Feels Good
There is a particular kind of software that you reach for without thinking. You open it, do the thing you came to do, and close it — no friction, no mystery, no frustration. It just works.
This quality is hard to name. "Good UX" is too clinical. "Intuitive" doesn't quite cover it either — plenty of interfaces are learnable without ever feeling natural. What I'm after is something closer to how a well-made object feels in your hand: considered, honest, right.
The Physical Analogy
A good chef's knife has a certain weight distribution. The blade tapers at a specific angle. The handle fits a particular grip. None of this is accidental — every dimension is the result of accumulated understanding about how knives are used, passed down and refined over centuries.
Software rarely has this kind of depth. Most of it is assembled quickly, optimized for shipping. Features are layered on rather than integrated. The result is tools that work, technically, but leave users with a vague sense of friction — nothing broken, nothing exceptional.
The craftsperson, by contrast, is obsessed with the material. They understand not just what something does, but why it was designed that way, and what that reveals about how it will be used.
What "Feeling Good" Actually Means
When software feels good, I think a few things are happening:
It is honest about what it is. A text editor doesn't try to be a publication platform. A task manager doesn't try to be a social network. Scope is a form of integrity.
It responds well. Interactions are fast, or feel fast. Animations don't mask delays — they communicate process. The interface acknowledges your actions.
It treats you as capable. Good tools make your intent clear without being condescending. They provide enough information to understand what's happening without overwhelming you with it.
It is consistent. The same gesture does the same thing. Terminology is stable. Mental models transfer between parts of the application.
The Cost of Not Caring
When software doesn't feel good, the cost is invisible but real. Users work around rough edges. They develop habits that compensate for confusing interfaces. They abandon tools that could have served them well.
More insidiously, software that doesn't feel good communicates that its makers didn't think about you. Whether or not that's true, the product carries that impression.
A Practice, Not a Feature
The quality I'm describing isn't something you add at the end. It's the result of sustained attention throughout a project — constant questioning of whether something is actually clear, actually fast, actually honest.
It requires treating users as real people with limited time and attention, rather than as sources of engagement metrics. It requires resisting the temptation to add more, and instead doing less, better.
This is hard. Markets don't always reward it. But software that genuinely serves people — that makes something in their life a little cleaner, a little more reliable — is worth making.
That seems like a good enough reason to try.