Field note · May 24, 2026
Software that explains itself
Notes on building products whose structure, copy, and behavior reduce the need for documentation.
Good software does more than expose functionality. It gives people enough context to form the right mental model.
Start with the next decision
Every screen should make the next useful decision obvious. That does not mean reducing an interface to a single button. It means establishing hierarchy: what changed, what matters, and what can be done now.
Treat states as product language
Loading, empty, error, and success states are not implementation debris. They are where a system explains its boundaries. A precise empty state can replace a page of onboarding copy.
Build the explanation into the system
The strongest documentation is often a well-named action, a useful default, or a preview that makes consequences visible before they are committed.