Start with a name that answers basic questions
A folder full of files named design-new, design-newer, and design-final2 makes it hard to tell what changed or which file to open. A useful name should identify the project, the piece of work, and its version. For example, alder-cafe_menu_v03.indd is more informative than menu-latest.indd. The goal is not to fit every detail into the name; it is to make the file recognizable outside its folder or an email thread.
Choose a short pattern you can repeat: project, deliverable, version, then an optional status. Keep the order consistent, use a separator such as an underscore or hyphen, and avoid characters that may cause trouble when files move between operating systems. If your work includes several formats or sizes, add a brief identifier: alder-cafe_menu-print_v03.indd and alder-cafe_menu-screen_v03.indd. A few predictable parts are more helpful than a long name nobody wants to maintain.
Give version numbers a clear meaning
Use a new version number when you reach a revision you may need to revisit: before sending a proof, after receiving a consolidated round of feedback, or before making a substantial change in direction. Save routine tweaks within the current working file if your software already provides a reliable edit history. This keeps versions meaningful without creating dozens of nearly identical files.
Simple numbers work well: v01, v02, v03. The leading zero helps files sort neatly as the count grows. Keep the same number when exporting different formats of the same revision, such as alder-cafe_menu_v03.pdf and alder-cafe_menu_v03.png. If the source file changes after those exports, advance the version and export again. That way, matching numbers indicate matching content.
Dates can help when timing matters, especially for recurring work. Use a consistent format such as 2025-04-18 so files sort chronologically. A date should add context, not replace a version number if multiple revisions might happen on the same day.
Separate working files, review copies, and approved deliverables
A status label is useful when it describes a real stage in the work. For example, v04-review can identify a proof sent for feedback, while v05-approved can identify the revision the client accepted. Avoid using final as a permanent status: a last-minute correction can quickly lead to final-final. If you do use it, treat it as a delivery label tied to a specific version, not as a substitute for one.
Folder structure can carry some of this information without making every filename longer. A project might have folders for source files, assets, review exports, and delivery. Put editable design files in the source folder and only client-ready exports in delivery. Do not rename an approved file after sending it unless you also make clear which copy the recipient should use. Keeping the sent copy intact gives both sides a stable reference.
Make changes traceable without writing an essay in the filename
Filenames are poor places for detailed notes. Instead of alder-cafe_menu_v04-fixed-prices-and-spacing-really-final.pdf, keep the filename short and record the changes in a project note or review message. A brief entry might say: “v04: updated prices, adjusted heading spacing, replaced the back-page photo.” This is especially helpful when feedback arrives through several channels or more than one person reviews the work.
Before applying feedback, gather it into one list and resolve any contradictions. Then save the next meaningful version and check the export against that list. When sharing a proof, refer to it by its exact filename. A message that says “Please review alder-cafe_menu_v04-review.pdf” is clearer than “Here’s the latest one,” particularly after attachments have been forwarded.
Keep the system easy to maintain
The best convention is one you will actually follow under deadline pressure. Create a project folder template, decide on a naming pattern before the first export, and use it throughout the job. If collaborators are involved, agree on who advances version numbers and where approved files belong. Otherwise, two people may independently create different files called v04.
Finally, remember that version numbers are not backups. Previous revisions help you compare decisions, but they may live on the same device as your current file. Keep copies of important project folders in a separate, dependable backup location and check that you can restore them. With clear names, a small number of meaningful versions, and a known place for delivery files, you can spend less time hunting for the right file and more time improving the work.
