Some software feels good before I can clearly explain why.
It is rarely because the product has the longest feature list. More often, the interface feels predictable, common actions are easy to find, and the product does not constantly ask for attention.
I notice this in tools such as Zen Browser, Helium, Samsung Browser, GitKraken, and Visual Studio Code. They solve different problems, and I do not use each of them for the same reasons, but they highlight qualities I value in software.
Good structure reduces effort.
A browser can support many tabs without turning them into a single crowded row. A Git client can make branches and commits easier to understand visually. An editor can provide powerful functionality while keeping the basic writing experience simple.
The feature itself matters, but its placement matters just as much. I should not need to remember a hidden sequence of actions for something I do every day.
Good defaults are a form of design.
Customization is useful, but a product should not depend on the user fixing it first. I appreciate software that already has sensible spacing, readable typography, understandable navigation, and shortcuts that match the most common workflows.
Visual polish helps, but polish alone is not enough. An interface can look beautiful and still feel frustrating if every action introduces another modal, menu, or confirmation.
Feedback should be quiet but clear.
When I switch a workspace, move a tab, create a branch, or save a file, the product should confirm what happened without interrupting me. Small states—hover, focus, loading, empty, selected, disabled—often determine whether an interface feels reliable.
These details are easy to call decorative. In practice, they explain the system.
The product should respect its role.
A browser should help me reach and organise information. An editor should help me work with code. A Git client should make repository state easier to understand. Problems begin when the surrounding interface becomes more demanding than the task itself.
This does not mean every product should be minimal. GitKraken can be visually rich because Git history is complex. Visual Studio Code can expose many commands because its users need them. The important part is that complexity has a purpose.
Software feels better when its complexity belongs to the problem—not to the interface around it.
These products are not perfect, and my preferences continue to change. Still, they influence how I think about my own interfaces: make the common path clear, provide useful defaults, show state honestly, and avoid making the user manage the product more than the task.