Most software still ships with the assumption that someone, somewhere, will read the documentation before using it. In practice, almost nobody does. People open the thing and start clicking, and the interface either answers their questions as they go or it doesn't.
An interface that explains itself doesn't mean an interface full of tooltips and onboarding tours. Those are usually a sign that the underlying design didn't manage to be clear on its own, and a layer of explanation got bolted on afterward to compensate.
The better version of self-explanation happens in the structure itself. A button labeled with the exact outcome it produces. An empty state that tells you what to do next instead of just showing you nothing. An error message that names what happened instead of a generic failure notice.
One habit that's helped: after building a screen, I try to look at it as if I've never seen the product before and ask what question I'd have looking at it. If the answer isn't visible on the screen, that's a design problem, not a documentation problem.
Documentation still has its place — for edge cases, for integrations, for the things too specific to fit into an interface. But the core experience shouldn't depend on it. If people need a manual to use the main flow of your product, the product is explaining itself to the wrong audience.