4 Make the emerging design visible

A conversation unfolds one sentence at a time. A design often depends on relationships that must be considered together. Who owns a resource while another task is using it? Which state permits publication? Which unanswered question affects two competing approaches? A suitable visual can keep those relationships available while the conversation moves on.

Puma's proposal for discovery includes a local page maintained alongside the discussion. Its purpose is to show the emerging picture: findings, open questions, choices, and relevant relationships. It should help participants notice a mismatch before a formal plan makes it look settled.

The page is useful only if its representation fits the question.

Choose what the reader needs to notice

A state diagram can clarify which transitions are valid. An ownership map can show who retains a resource after a caller disappears. A sequence view can distinguish the order of events. An interface mockup can expose the words a person will see. A comparison table can put alternatives against the same criteria.

For acquisition, a progress bar alone may conceal the distinction between transfer and readiness. A better discussion aid could show:

This is a proposed product contract, not a universal acquisition lifecycle. It makes assumptions available for discussion. Someone may object that consumers need simultaneous access to both versions, or that there is no previous version. That objection improves the model.

Show uncertainty without making the page unreadable

A live visual can accidentally look more authoritative than the discussion behind it. Clean typography and complete-looking boxes suggest that the design has been decided. If an option is provisional, say so near the option. If a finding depends on a particular version, keep the version available with the source.

Avoid turning uncertainty into a sea of warning badges. Distinguish the few unresolved points that affect a decision from background details. A useful page might have a current proposal, two open material questions, and a small evidence list. It need not contain every sentence of the conversation.

The page also needs a clear owner. If several agents rewrite it independently, they may merge incompatible assumptions into a polished composite. Puma's discovery design assigns a separate author to the visual while the lead owns synthesis and decisions. The benefit is coherent editing, but the arrangement still has a cost: the author must receive current information, and stale representations must be corrected promptly.

A prototype answers a particular question

Houde and Hill distinguish prototypes by what they investigate: a product's role, its look and feel, or its implementation. The distinction is useful because apparent completeness in one dimension can conceal absence in another. A convincing interface can say little about resource safety; a robust backend probe can say little about whether a person understands the result. What Do Prototypes Prototype.

For our example, a mockup asks whether “Transfer complete, preparing for use” is understandable. A failure-injection test asks whether a candidate rejected before publication leaves the old version usable. A lost acknowledgment after publication is a different case: the transition may already have committed, so reconcile the uncertain result instead of assuming rollback. Chapter 25 returns to that boundary. Both are valuable. Neither replaces the other.

Sometimes making the prototype changes the intended outcome. Mitchell Hashimoto's account of a Ghostty update feature starts with a bounded UI investigation and discovers preferences through the prototype. A later implementation works but conflates concerns; he changes the model and continues. The account supports intent and boundaries while challenging any rigid idea that intent must be completely discovered before construction. It is a first-person case with a linked change, not a controlled productivity comparison. Vibing a Non-Trivial Ghostty Feature.

Preserve access beyond the visual

A diagram should have readable labels and a textual account of its central claim. People may use screen readers, small screens, monochrome printouts, or slow connections. A relationship that exists only as a colored line may be difficult to inspect or cite later.

Keep the important decision in a durable record once it is made. The visual can remain an explanatory view, but it should not become a competing authority whose outdated boxes contradict the plan. The cost of a live page rises when it duplicates information that must be changed in several places.

For a current design discussion, choose one question a visual could answer. Make the smallest representation that exposes it. Ask someone to explain the proposed behavior from the view. Where their explanation differs, investigate whether the defect lies in the design, the labels, or an unstated assumption. The success criterion is improved understanding of that question, not an impressive page.