Name creative files so the next person can find the right version

Separate identity from status

A filename should help a person identify the project and the artifact. Status is a separate idea: draft, review, approved or superseded. Mixing the two without a rule produces names such as “banner-final-new-fixed.” The words describe a sequence of emotions rather than a dependable version. Start with a stable project label and a clear artifact name, then add a revision or date according to the workflow.

For a small campaign, a name such as “spring-event-poster-r03” is easier to interpret than “new poster latest.” It does not by itself prove approval, so keep approval status in the project record or a clearly managed folder. The exact syntax is less important than consistency. Choose a scheme people can type and understand without a long manual. A naming rule that is too elaborate will be shortened differently by each collaborator, defeating the purpose of having one.

Give sources and exports different homes

An editable project file and a distribution export serve different roles. Store them in clearly named folders, such as source, review and delivery, or an equivalent structure that fits the team. Do not force every project into a large template with many empty folders. For a single image, two locations may be enough. For video or audio, separate media dependencies can be essential because the project may refer to files rather than contain them.

The distinction is supported by the behavior of creative tools. Audacity's official documentation, for example, distinguishes the editable project from an exported audio file. Our practical recommendation is to make that difference visible in the folder structure. A recipient looking for something to publish should not have to guess whether a file is the working project or the approved output. Likewise, a future editor should be able to locate the source without attempting to reverse-engineer a compressed export.

Use versions for meaningful changes

Choose when to increment a revision. A useful rule is to create a new review version when the artifact is sent for feedback or when a substantial alternative is developed. You do not need a new filename for every keystroke if the app's save and history behavior already supports ordinary editing. Too many nearly identical files make it harder to find meaningful milestones. Too few overwrite the states people actually reviewed.

Keep a short change note for important revisions. “r04: corrected event date and replaced the licensed photo” tells a reviewer what to inspect. A filename cannot carry every detail. If two alternatives exist at the same stage, label their purpose, such as portrait and landscape or short and extended, rather than treating one as a later version when neither supersedes the other. This preserves the difference between a variant and a revision, which is often lost in ad hoc naming.

For example, poster-r03-square and poster-r03-portrait can identify two layouts from the same review round. If only the portrait date changes, record that correction explicitly rather than silently replacing its file while leaving the shared revision note unchanged. Related outputs can diverge, and the record should make that visible.

Include only useful dimensions

A filename can include platform, aspect ratio, language or size when those fields help select the right artifact. For example, a multilingual campaign may need a language code, while a single-language internal poster does not. Avoid adding metadata that never changes or can be read easily from the file itself unless it prevents a real mistake. The aim is quick identification, not a miniature database embedded in every name.

Order the fields consistently so that related files group together in a folder listing. If date order matters, use a date pattern that sorts chronologically. Keep names reasonably short and avoid characters that cause trouble across the systems you use. Test the scheme with the actual transfer path, especially if files move between operating systems or cloud services. A naming convention is only useful if it survives the tools and people that handle the files.

Make approval visible without losing history

When an artifact is approved, record which exact version was approved and for what use. An approved social image may not be approved for print, and a review audio export may not be the release master. Put the distribution-ready files in a controlled delivery location with a clear note. Keep the editable source linked to that delivery, so later corrections can start from the correct state.

Do not rename every approved file simply “final” and discard the revision identifier. If a correction is needed, the team must be able to distinguish the old approved version from the replacement. Mark superseded delivery files clearly or move them into an archive, while respecting any retention obligations. The public or downstream handoff should expose only the intended current files. The archive can preserve the history without competing with the active delivery folder for attention.

Test the system with a stranger's question

Ask someone unfamiliar with the project to find the current editable source, the latest review copy and the file intended for publication. If they cannot do so from the names and folder structure, improve the labels. This is a practical usability test for file organization. It is more revealing than debating whether underscores or hyphens are aesthetically preferable. The system exists to reduce ambiguity in real tasks.

Add a short README when the project has dependencies, special export settings or several related deliverables. Explain the naming rule and identify the current handoff version. Keep that note concise enough to remain current. A good file system does not require the original author to be present whenever someone needs an asset. It makes identity, version and intended use visible, while preserving the editable materials needed for future work. That is the standard to optimize, rather than the visual neatness of the folder listing.