Problems found in implementation must be written back into the design source

What it is

Mismatches, impossibilities, and interaction changes discovered while building have to be written back into the design source — the file that will be opened as the starting point for the next version — not only into the code. A code patch lets this release ship. Leaving the design source untouched means the next job starts from the old intent again.

Write-back is for changes that alter interface intent: a missing state, a revised structure, replaced copy, an action the platform cannot do. Image compression and lazy loading that do not change intent stay out of the design file.

Why it happens

The next change opens the design source, not last week’s commit message. While two sources run in parallel, the file keeps “ought” and the code keeps “is.” The next mock starts from ought, implementation collides with is, and the same fight is staged again. Write-back puts the negotiated result into the source so the next open already contains the constraint.

A chat note or ticket comment that “we ended up doing it that way” is, for the design source, no change. A newcomer, you in three weeks, and the person implementing the other platform will all copy the old frame. The waste is not the discussion when the problem was found; it is paying for that discussion again because the result never returned to the source.

Where it stops holding

A one-off campaign page that will not be opened again can live with a code-only fix; write-back returns little. A file that will be archived when this round’s replacement lands is the wrong target — write into the successor. Pure performance or packaging choices that do not change layout, copy, states, or actions only add noise if forced into the design file. When several design sources exist (per platform, per experiment), write-back must hit the file the next job will actually use; the wrong file is no write-back.

Applying it

• Keep interface-intent changes in the same ticket as the code change; the ticket does not close until the design source is updated. Code-only is not done.
• Edit structure, states, or copy in the file itself, with a one-line “matches implementation” note. Do not describe the change only in comments.
• When files are split, record which file was updated; experiment and platform files are updated separately.
• How to check: the moment the ticket closes, open the design source against the shipped UI. Every mismatch is a code-only patch. One iteration later, have someone else start from the design source; if they hit the same implementation conflict, write-back still failed.

Related

• Same group: R2.12.1 Delivering design one iteration ahead reduces mutual waiting · R2.12.3 When the joint review happens determines how much work is thrown away · R2.12.4 Exploratory design and delivery design must be scheduled separately
• Nearby: R2.02 Design QA · R2.11 Identifying and paying design debt
• Search terms: write back to design source · source-of-truth sync · implementation feedback