The Naming Convention Graveyard

Every designer's hard drive tells the same story:

Homepage_v1.png
Homepage_v2.png
Homepage_v2_revised.png
Homepage_FINAL.png
Homepage_FINAL_v2.png
Homepage_FINAL_FINAL_USE_THIS_ONE.png

It's funny until a client approves the wrong version and you've already sent the files to print.

Why Design Versioning Is Hard

Developers solved this decades ago with Git. Every change is tracked and you can revert anytime, so everyone works off the same source of truth. But most design versioning tools either require technical knowledge or lock you into a specific design app.

The reality for most freelancers and small agencies:

Files live in folders with creative naming conventions.
Clients see whatever you send them. There's no guarantee they're looking at the latest.
Feedback gets orphaned. The comments a client left on v2 don't carry over when you send v3.
There's no changelog. If someone asks "what changed between round 2 and round 3?" you're recreating history from memory.

This post walks through why that happens and what it costs you when it goes wrong. Then it covers how to build a version habit that doesn't require learning a command line.

Borrowing Developer Concepts Without the Command Line

You don't need Git to benefit from the ideas behind it. Three concepts carry over cleanly, and none of them require typing a single command.

A version is a snapshot, not a replacement. In Git, a commit doesn't erase the code that came before it. It adds a new point in history you can always return to. The design equivalent is simple: every round of work you send to a client should be its own snapshot, kept alongside the earlier ones, not saved over them. If you're overwriting Homepage_FINAL.png with your latest changes, you've thrown away the ability to answer "what did round 2 actually look like?"

A diff is how you show what changed. Developers review pull requests by looking at a diff, the specific lines that changed between one commit and the next. Designers rarely get this for free, so it has to be manufactured. That can be as simple as a side-by-side view of two versions, or a short note under each upload explaining what moved. The point is the same: don't make the client hunt for what's different. Show them.

A branch is a round of exploration that hasn't been accepted yet. When a developer opens a branch, they're saying "this is a proposal, not yet merged into the main line of work." A design round in progress is the same thing. It shouldn't be presented to the client as the new default until they've actually reviewed and accepted it. Mixing "here's an idea I'm trying" with "here's the current approved design" is one of the most common ways teams lose track of what's actually live.

None of this requires a Git client, a terminal, or a computer science background. It requires treating versions as additive history instead of a single mutable file, and it requires a way to surface what changed between them.

What Happens When Versioning Fails

These aren't hypotheticals. They're Tuesday.

The client approves the wrong version. You send a review link on Monday. By Wednesday you've uploaded a revision, but the client opens the old link they bookmarked, the one still pointing to v1. They reply "Approved!" and you push it to production. Two weeks later, during a launch meeting, someone asks why the hero section still has the old headline. Now you're doing emergency revisions on a "finished" project, and the client swears they never approved that version.

The designer overwrites the approved file. You're tidying up your project folder and save the latest round of tweaks right over the previously approved file. The problem is that the approved version was the one the client signed off on, and you no longer have it. When the client later disputes a change ("I never approved that color"), you have no evidence. The sign-off is gone because the file it was attached to no longer exists in its original form.

Feedback gets lost between versions. A client leaves detailed comments on v2: "move the CTA higher," "swap the background photo," "make the subhead shorter." You take those notes, build v3, and send it as a fresh attachment in a new email thread. The client opens v3 but can't remember what they originally asked for. They re-request changes you already made, or they assume you ignored their notes entirely. Meanwhile, the original feedback is buried seventeen messages deep in a thread nobody wants to scroll through.

Two people edit at once and nobody notices. On a small team, it's common for a designer and a junior collaborator, or a designer and a marketer touching up copy, to both open the same source file within an hour of each other. Whoever saves last wins, silently, and the other person's changes are gone with no warning that a conflict happened at all. Developers get merge conflicts flagged to them explicitly. Designers usually just lose the work.

Each of these problems has the same root cause: versions exist, but nothing connects them. The files float in one place and the feedback and decisions float in another. That's what real version control solves. It doesn't only track files, it keeps the whole conversation anchored to the right snapshot in time.

Why Your Design Tool's Built-In Version History Isn't Enough

If you work in Figma, Adobe XD, or even just Google Drive, you likely already have some form of version history. It's tempting to assume that's sufficient. It usually isn't, and the gap matters specifically for client work.

It's built for the editor, not the client. Figma's version history is a scrollable list of restore points meant for you, the person editing the file. It assumes the viewer already knows how to navigate the tool. A client opening a Figma file for the first time to find "the version from last Tuesday" is not a realistic ask, especially for a client who has never used Figma and never will.

It doesn't record a decision. Native version history tracks that a file changed. It doesn't track that a client looked at it and said yes or no. Restoring an old version tells you what the file contained. It tells you nothing about whether anyone approved it, when, or under what understanding.

It doesn't span file types. A single project often mixes a homepage mockup, a PDF proposal, a short walkthrough video, and a staging URL the client can click around in. Figma's history covers the Figma file. Drive's history covers whatever lives in Drive. None of them give you one place where a client can review all four against one consistent record of what was approved and when.

It disappears when the client isn't a collaborator. Most design tools only expose full version history to people with edit access to the file. Clients are usually viewers, if they have access at all, so the history you'd point to in a dispute is often something they can't see or export themselves.

Native version history is still a good safety net for your own editing process. It's just solving a different problem than the one this post is about: making sure the client and the designer are always looking at the same snapshot.

Practical Version Control Without the Complexity

1. Upload, Don't Replace

Instead of overwriting a file, upload the new version alongside the old one. This preserves the history and lets anyone compare iterations.

2. Keep Feedback Tied to Versions

The biggest versioning pain isn't the files. It's the feedback. When comments live in email or Slack, they become disconnected from the specific version they reference.

Aligno handles this by linking comments to specific versions. When you upload a new version, previous comments stay attached to the version they were left on. The client always sees the latest, but the full history is one click away.

3. Make "Current" Unambiguous

Whatever tool you use, there should be one version clearly marked as "current." No guessing, no asking "is this the latest?"

4. Let the Client Always Land on the Latest

Share links should always open the most recent version by default. If the client bookmarked the review link three weeks ago, it should still show them what's current, not what was current when you first shared it.

5. Close Each Version with a Decision

Version control is about more than tracking files. It tracks decisions too. Every version you send to a client should end with an explicit action: approved, or changes requested. Without that, you're left guessing. Did silence mean they liked it? Did they even open the link?

When each version closes with a recorded decision, you get an audit trail that protects both sides. The client can't claim they never approved something. You can't accidentally keep iterating on a version that was already accepted. And if a project gets handed off to another designer mid-stream, the new person can see exactly where things stand without asking anyone.

Look for a tool that bakes client approval into the review flow. The client should approve with a button on the actual design, instead of a follow-up email no one can find later. That way the approval lives right next to the version it refers to.

Different Asset Types Need Different Version Habits

"Version control for design" tends to get discussed as if every project is a single static image. In practice, a design or agency project usually spans several asset types, and each one has its own versioning quirks.

Static images and mockups

This is the simplest case and the one most naming-convention chaos comes from. The habit to build is small: every export gets uploaded as a new version of the same asset, not a new file in a new folder. Comments pinned to a specific spot on version 2 (say, a note on the logo placement) should stay put on version 2 even after version 3 exists, so anyone looking back can see exactly what the note referred to.

Multi-page PDFs

PDFs add a wrinkle: feedback is usually page-specific. A comment about the pricing table on page 4 needs to stay tied to page 4 of that particular version, rather than to the document as a whole. If your review tool treats a 12-page proposal as one flat file, you'll end up with comments that make sense only if you remember which page the reviewer had open when they wrote them.

Video edits

Video introduces a timing dimension on top of versioning. "Fix the transition" is meaningless without knowing which second of which cut it refers to. Comments on video need to be pinned to a timestamp, and that timestamp needs to travel with the correct version, since a re-edit can easily shift where a given moment falls in the new cut. A tool that supports timestamp-pinned comments on video is solving a real, separate problem from pinning a comment on a static image.

Live webpages

Reviewing a staged webpage is different again, because the "file" is a live URL that can change out from under the reviewer at any moment. A client who opens a staging link on Monday and comes back Thursday might see an entirely different page if you've kept pushing changes to the same URL, with no way to tell what they originally commented on. The fix is the same principle as everywhere else: each round of changes to that URL should be captured as its own reviewable version, so a comment made against Monday's layout still makes sense on Thursday, even after the live page has moved on.

A Worked Example: Three Rounds on a Homepage Redesign

Concepts are easier to apply with a concrete run-through. Say you're a freelancer redesigning a client's homepage over three rounds.

Round 1. You upload the initial concept as version 1 and share the review link. The client pins three comments: the hero image feels generic, the call-to-action button is too small, and the footer needs the correct social links. They don't approve. That's fine, that's what round 1 is for.

Round 2. You address all three notes and upload version 2. Because the comments from version 1 are still attached to version 1, you (and the client) can scroll back and check each one off against what changed, instead of relying on memory. The client reviews version 2, likes the direction, but asks for one more tweak: the new hero image is good, but the crop is off on mobile. Still no approval yet, which is expected and normal.

Round 3. You fix the crop and upload version 3. This time the client clicks approve. That decision is recorded against version 3 specifically, with a timestamp. Two months later, if someone on the client's side asks who signed off on the hero section, there's a direct answer: this version, this date, this decision, with no memory required.

Notice what made this workable: nothing was overwritten, every round of feedback stayed attached to the version it was about, and the approval at the end pointed at an exact, still-existing snapshot rather than "whatever's live now."

You Don't Need Git

You need a system that tracks versions and keeps the feedback attached, so everyone knows which version is the one that matters. Keep it simple and visual, and your future self will thank you.

If you're outgrowing your current review tool, see how Aligno compares to GoVisually for version-aware design review, or take a look at the full list of features if you want to see how versioning, comments, and approval fit together in one place.

Design Version Control for Non-Developers