How to Run a Design Review Without Losing the Previous Version

A design review that ends with the previous version gone is not a review. It is a demolition. The file gets overwritten, the old screens vanish from the shared drive, and the only record of why the earlier layout worked sits in someone's memory, fading. Months later a new hire asks why the navigation sits where it sits, and the honest answer is that nobody can pull up the version that explains it. Version loss during review is one of the quiet, expensive failures of design work, and it happens because the review meeting treats versions as disposable rather than as evidence.

The fix is structural, not attitudinal. Reviewers will not suddenly become careful about file hygiene because a manager sends a memo. The review has to be built so that preserving the prior version is the path of least resistance, the default that happens without anyone deciding to be disciplined. A review process that depends on good intentions will lose versions at exactly the moments that matter: the rushed Friday afternoon before a launch, the second round when everyone is tired, the session where a senior person says "just do it" and the old file disappears into a save.

The review that eats its own history

The common failure looks like this. A designer opens the current file, the one that has been through four rounds, and the reviewer starts marking changes directly on it. By the end of the hour the canvas holds a hybrid: three panels from round two, a new header nobody has discussed, and a color change that was supposed to be a question. The file is saved. The previous version, the one that was actually approved two weeks ago, is now unrecoverable except by digging through autosave logs that may or may not exist.

What got lost is not merely a file. It was a decision. The round-two layout was the version a stakeholder signed off on, and the reasoning behind it lived in the relationship between that layout and the conversation around it. Once the canvas mutates, the decision loses its anchor. A reviewer who wants to ask "why did we move the sidebar" now has no object to point at.

Design review is uniquely vulnerable here because the artifact and the discussion are bound together. In code review, the diff preserves the before and after automatically; the tooling does the remembering. In design review, the artifact is a visual whole, and the tool that displays it is the same tool that edits it. The ease of editing is the problem. A reviewer with edit access and a strong opinion can erase the baseline in a single drag.

Snapshots before the room, not after

The single most effective habit is to freeze the version before anyone walks into the review. Not after, when changes have already crept in. Before. The file that enters the room should be exported, duplicated, or tagged as a numbered snapshot with a timestamp and the name of whoever owns it. That snapshot is the baseline, and it does not get touched during the session.

Practically, this means a review never starts on a live working file. It starts on a copy, or better, on a read-only artifact: a PDF, a flat image, a locked frame. Reviewers annotate the flat version, and the live file stays sealed until the session ends and the notes are triaged. This one change eliminates most accidental overwrites, because the thing under discussion cannot be edited by accident.

The snapshot needs a naming convention that a stranger can parse six months later. "Final_v3_reallyfinal" tells nobody anything. A date, a round number, and a one-line note about what changed gets the job done: "2025-03-14 round 3, sidebar moved left, header simplified." The note is the part people skip, and it is the part that makes the snapshot useful. A version without a description is a file; a version with a description is a record.

Why verbal review notes vanish

Spoken feedback is the second silent killer of versions. A reviewer says "this feels too heavy" and points at a region of the screen. The designer nods, and later, working from memory, changes the wrong thing. The version that was actually critiqued drifts from the version that gets edited. Two weeks later the team cannot tell whether the heavy feeling was addressed, because the note that described it was never written down.

The remedy is captions bound to the snapshot. Each piece of feedback gets a number, a location, and the exact words of the reviewer, attached to the frozen artifact. The designer who edits later works from the captioned snapshot, not from recollection. When the next round is reviewed, the previous captioned snapshot sits beside the new one, and the conversation can reference specific numbered notes. The history of decisions stays legible because each note is anchored to a version that still exists.

There is a social benefit too. Reviewers who see their words captured tend to be more precise. The person who would have said "make it pop" writes "increase contrast between the button and the background," because the note has to survive on its own after the meeting ends. The format disciplines the feedback.

The comparison view that keeps both frames visible

Any review worth its time compares at least two states: what existed before and what is proposed now. The comparison should be visible in the room, side by side, at the same scale. Not a slide deck where the previous version flashes for two seconds and disappears. Two frames, held open, for the length of the discussion.

The side-by-side changes the quality of the argument. A reviewer who claims the new spacing is tighter can be shown the old spacing directly beside it, and the disagreement resolves in seconds rather than in a follow-up thread. A designer who believes the old hierarchy was clearer can point at the specific region where the two frames diverge. The comparison turns vague preference into a concrete claim about a visible difference.

When the comparison is not possible because the previous version was lost, the review collapses into assertion. Whoever speaks with the most confidence wins, because there is no shared object to arbitrate. Preserving the prior version is what makes comparison possible, and comparison is what makes the review an actual review rather than a series of opinions delivered at a screen.

Separating the decision from the edit

A review meeting should produce decisions, not files. The edit comes after, in a separate session, working from the captured notes and the frozen snapshot. Mixing the two in one hour is how versions die: the discussion is still live, the file is open, and the boundary between "considering a change" and "making a change" blurs until the baseline is gone.

The separation also protects the designer from the worst review dynamic, where a senior person reaches over and drags something on the canvas mid-sentence. If the artifact in the room is read-only, the reach has nowhere to land. The change gets described instead of performed, and a described change can be captured, weighed, and applied deliberately later. The room stays a room for thinking; the edit stays a deliberate act.

Some teams formalize this with a rule: no live editing during review, period. Others simply keep the live file closed and work from exports. Either works, as long as the boundary holds. The boundary is what preserves the previous version, because the previous version is never in the same window as the editing cursor.

When a change is approved, the old file becomes the reference

The moment a new version is approved, the version it replaced gains a new job. It becomes the reference for what was rejected or superseded, and that reference has value. The old file answers the question "why did we not do it that way" without anyone having to reconstruct the argument from memory. Teams that keep every approved version, each with its captioned notes, build a decision log that a new hire can actually read.

The log also shortens future reviews. When someone proposes revisiting an old direction, the file and the notes are right there: the earlier attempt, the specific feedback that killed it, the date. The conversation can start from evidence instead of from a fresh debate that recycles arguments the team already settled. Version preservation is, in this sense, a form of institutional memory, and design teams that treat it as overhead pay for the neglect later in repeated discussions and lost context.

A short checklist for the review room

Before the session: export or duplicate the current version, name it with date and round, and write the one-line description. Open the prior version beside it at the same scale. Close the live working file. Set the artifact to read-only if the tool allows it.

During the session: capture each note with a number, a location, and the reviewer's exact words. Keep the frozen snapshot on screen. Resist the urge to demonstrate a fix by editing in place; describe the fix instead. If a change is small and obvious, note it and apply it after the meeting, on a new copy, so the baseline stays intact.

After the session: triage the notes, apply the accepted changes to a fresh copy, and save the result as the next numbered version. File the captioned snapshot alongside it. The chain from round to round stays unbroken, and any future reviewer can walk backward through it without guessing.

The teams that lose versions are rarely careless. They are fast, and speed rewards working directly on the live file. The cost of that speed shows up later, in the question nobody can answer and the decision nobody can cite. A review that keeps its previous version is a review that can be trusted a year after the meeting ends, when the only thing left to consult is the file itself.