How to manage creative versions without losing track

Every designer has seen the folder. Banner_final.png, banner_final2.png, banner_FINAL_v3_use-this.png and, my favourite, banner_final_final_approved_NEW.png. Each name made sense to the person who saved it. Together they are a small disaster waiting to go live.

Version control sounds like an engineering problem, but in creative work it is mostly a habits problem. You do not need special software to fix it, although the right tool makes the habits easier to keep. This guide covers the five habits I rely on: naming, a single source of truth, resetting approvals, comparing versions and archiving.

Why do creative versions get out of control?

Versions get out of control because files get copied. Every time a file is attached to an email, downloaded and re-uploaded or saved to a desktop, a new copy starts its own life. Soon nobody knows which copy is current, and the approval someone gave applies to a file nobody can find.

The cost is real, even if it is rarely tracked. An old version gets printed. A client approves something the designer has already changed. A requested fix gets lost between rounds and reappears in round five. If you want to see that cost spelled out, read the real cost of version 7_FINAL.

Step 1: Agree on a naming convention

Pick one naming pattern, write it down and use it for every file on every project. The pattern should tell anyone what the file is and which version it is, without opening it.

A pattern that works for most teams looks like this:

client_project_asset_size_v#

For example, a second round of a square social post for a spring campaign might be named acme_spring-sale_social-post_1080sq_v2. A few rules make the pattern hold up:

• Always end with a version number. Never use final, latest, new, updated or use-this.
• Use lowercase and one separator style consistently, so names sort cleanly.
• Put the size or placement in its own segment, so each size can move through versions independently.
• Do not reuse a version number, ever. If v3 changes, it becomes v4.
• Keep internal drafts out of the numbering the client sees, for example with a letter suffix like v2a, v2b, until one is ready to share.

The word final is the enemy because a version is only final in hindsight. The moment you call something final, the client asks for one more change.

Step 2: Keep one source of truth

There should be exactly one place where the current version of every creative lives, and everyone should know where it is. Share links to that place instead of sending files.

That place could be a well-organized shared folder or a review tool. What matters is that people come to the file rather than the file going to them. When a reviewer opens a link and always sees the current version, they cannot approve a stale attachment from three days ago.

A good source of truth also keeps history. You should be able to see every earlier version in order, with the comments that were made on each one. In Yesquill, for example, you upload a new version onto the same creative, so the stack stays in one place and reviewers always land on the latest one. Whatever you use, the test is simple: can a new team member find the current version and its history in under a minute without asking anyone?

Step 3: Reset approvals on every new version

When a new version is uploaded, the approvals on the old version no longer apply. Every reviewer needs to look again and make a fresh decision, even if the change looks tiny.

This is where most teams get burned. Someone fixes a typo after approval, does not bump the version or re-request sign-off, and in the process nudges a logo or swaps a font. The client approved something that is no longer what goes live.

Here is what should and should not reset with a new version:

• Resets: approval decisions from every reviewer, the overall status and, usually, the due date for the round.
• Does not reset: comments made on earlier versions. They stay attached to the version they were about, so you can always see what was asked and when.
• Carries forward: the brief, the reviewer list and any brand or legal rules that apply to the creative.

Some tools handle this automatically. In Yesquill, uploading a new version resets decisions while old comments stay on their own version. If your setup does not do it for you, make it a written rule in your approval workflow so nobody has to remember.

Step 4: Compare against the previous version

Before you send a new version for review, open it next to the previous one and check two things: every requested change was made, and nothing else changed by accident.

Work through the comments on the old version one by one and find each fix on the new version. Then scan for unintended changes: shifted text, a different crop, a colour that moved slightly during export. Side by side comparison catches these far more reliably than flipping between two tabs from memory.

For video, compare the same moments in each cut, especially the opening, the caption-heavy sections and the end card. Frame-level problems are easy to reintroduce during an edit. The same idea runs through how to review video ads frame by frame.

When you send the new version, include a short change note: “v3 addresses the five comments on v2: headline shortened, logo enlarged, price updated, legal line added, background lightened.” Reviewers move faster when they know what to look for.

Step 5: Archive finals with their approval record

Once a creative is approved, move the approved version to your finals storage along with a record of who approved it and when. Then clear the working versions out of everyday view.

The approval record matters more than people think. Months later, when someone asks why the campaign said what it said, you want to point to a decision with a name and a date, not search an inbox. An activity log in a review tool, an exported summary or even a simple note in the folder will do.

A tidy archive usually includes:

1. The approved final export for each size or placement.
2. The source file used to create it.
3. The approval record, with reviewer names, decisions and dates.
4. Any licences for stock, fonts or music used.

Working versions can be kept for a while in case of questions, then cleared according to your client agreements. Keeping everything forever makes the next search harder, not easier.

What does good version management feel like day to day?

It feels quiet. Nobody asks which file is current. Designers do not re-fix the same issue twice. Clients approve what actually goes live, and when someone asks who signed off, the answer takes seconds.

None of these habits are hard on their own. The challenge is doing them every time, on every project, including the rushed ones. Write them down, put the naming pattern where everyone can see it, and let your tools carry as much of the load as possible.