When the joint review happens determines how much work is thrown away

What it is

Looking together — at a file, a prototype, or already-written UI — surfaces structural collisions neither side sees alone. When that joint look happens decides how much finished work will be thrown away. Review while the interaction model is clear and production layout is not yet laid down changes intent. Review after pixels are on a branch and tests already follow the old structure changes demolition.

Timing is about how much downstream work is already committed. It is not about whether to look together, and not about splitting exploration from delivery. A late joint review still finds problems; the bill just moves from editing a file to tearing out code.

Why it happens

The more implementation stacked on a wrong assumption, the steeper the hours to overturn it. Structure — how many steps, how states split, which action lives at which layer — is the foundation for layout, components, and tests. Rewrite the foundation in review, and every layer above is redone. If review happens after the foundation is poured and walls are up, the problems are real and the payment is rebuild. If it happens while the foundation exists only on a file, not yet bitten into by code, the same structural miss is a file edit.

“Looking together” does not by itself cut rework. Two people picking at UI already on main the night before release, and two people picking at a flow at the interaction-draft stage, can find the same class of issue at wildly different rework volumes. Volume is how much of the wrong assumption was already locked in by construction when the review ran.

Where it stops holding

A copy tweak or an icon nudge is cheap to reverse whenever it is reviewed; it does not need its own structural review gate. A greenfield repo with nothing to tear out yet has a light late-review bill — until the first production layout lands, after which it is no longer greenfield. A single person who both designs and implements turns “joint” into self-check; the timing rule still applies (stop before writing production layout), but there is no second role. A review that arrives before there is any intent to review — mood boards, unchosen directions — idles, and the real structural review can still arrive too late afterward.

Applying it

• Fix a design–engineering review at the point the interaction model can be stated and production layout has not started. Review steps, states, and layering; not visual polish.
• Mark “first time we looked together was at already-written UI” as late. Late reviews handle only structure that must change, and record the teardown scope separately.
• Visual and copy reviews can sit later; do not crush them into the same sitting as the structural one.
• How to check: on recent rework tickets, mark whether the joint review happened before layout code or after. Every structural fix that required tearing out written layout or tests is late timing. The aim is for that class of ticket to approach zero.

Related

• Same group: R2.12.1 Delivering design one iteration ahead reduces mutual waiting · R2.12.2 Problems found in implementation must be written back into the design source · R2.12.4 Exploratory design and delivery design must be scheduled separately
• Nearby: R2.02 Design QA · R2.05 Completeness of edge-case delivery
• Search terms: joint-review timing · late review rework · structural review gate