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.