Design for Understanding

A good design reveals how it works. Whether the artifact is code or a physical object, understanding should come from the thing itself rather than from external explanation. The burden is on the designer to communicate, and confusion is the designer's failure, not the user's.

Reinforced By

• Obvious Code — code a reader understands on the first pass, judged by the reader.
• Discoverability — being able to tell what actions are possible just by looking.
• Affordances and Signifiers — what is possible, and the cues that communicate it.
• Conceptual Model — a system image that lets a person predict behavior.
• Ubiquitous Language — one rigorous, shared vocabulary so the domain is understandable directly, in conversation and in the code, with no translation layer in between.

Why it Matters

A Philosophy of Software Design makes the claim about code: obviousness is a property the reader judges, and nonobvious code is the enemy. The Design of Everyday Things makes the same claim about everyday objects: affordances, signifiers, and a clear conceptual model let people act without a manual, and blame for confusion belongs to the design. Domain-Driven Design extends it to the domain itself: a ubiquitous language makes the business understandable directly in the code and in conversation, so awkwardness in the language is treated as a design flaw to fix. Across code, everyday objects, and domain models the worldview is identical: if people cannot understand it, the design has failed.

Tension

Revealing how something works competes with simplicity and minimalism. Showing every capability aids understanding but adds clutter; hiding it cleans the surface but can leave users unable to discover what is possible.