File Management Basics — Naming Conventions and Folder Structure

In production environments without a unified file naming convention, the same types of problems repeat themselves without fail. Let us examine what those workplaces look like in concrete terms.

Near the end of a web redesign project, a designer asked the director: "Which file should I submit as the final version?" Opening the delivery folder revealed the following files coexisting:

design_top.psd
design_top_v2.psd
design_top_final.psd
design_top_final2.psd
design_top_final_OK.psd
design_top_最終.psd
design_top_最終確認済み_20260815.psd

Identifying "which one is actually the final version" requires opening and checking the modification date, file size, and contents of each file individually. In a real project where images, text, HTML, CSS, JavaScript, and documentation are all mixed together, this verification work alone can consume several hours.

The specific problems caused by naming convention breakdown are as follows:

1. Overwriting accidents
Different team members update a file with the same name separately, and one person's work is deleted. Depending on cloud storage sync timing, work completed moments earlier can be silently overwritten.

2. Wrong-version delivery
A pre-revision file is accidentally submitted for delivery. This occurs when files without a "draft" or "wip" marker coexist with the same naming as completed versions.

3. Review cycle collapse
The file attached to a client feedback request email differs from the file that was actually reviewed. The ability to revert to "the version sent last time" when the client requests it is lost.

4. Handoff failure when team members change
Because there are no folder structure rules to follow, a new team member may spend days just gaining a situational overview. In the worst case, it becomes impossible to determine which files are valid without contacting the previous owner.

5. Misaligned understanding between external partners
In projects involving multiple freelancers — designers, engineers, writers — each party delivers files with their own naming convention. The director must perform a name-unification task when consolidating everything, accumulating unestimated working hours.

These problems are not caused by team members having poor awareness. They are structural problems in which confusion arises even when each person names files with good intentions, because no rule exists to begin with.

The basics of file naming come down to a combination of three elements. Understanding this structure allows it to be applied to any type of file.

The Three Elements of a Naming Convention

Element 1: Date (YYYYMMDD format)

Dates must always be written in ISO 8601-compliant 8-digit format (e.g., 20260910). Formats like "R6.9.10", "2026/9/10", or "Sep-10" are prohibited. There are two reasons. First, files will not sort in chronological order. Second, the interpretation of the string may differ between OSes and cloud services.

Element 2: Project name or content name

Use only half-width alphanumeric characters and underscores. Spaces, slashes, parentheses, ampersands (&), and plus signs (+) are prohibited. While Japanese characters are not universally banned, they must be converted to half-width alphanumerics for any files that may be embedded in URLs or systems (such as web files).

Decide on an abbreviated project name at the start of the project. For example, for "ABC Corporation Website Renewal," a prefix such as "abccorp-web" might be chosen. Having all team members use this same abbreviated form consistently increases the precision of folder management.

Element 3: Version (v01 format)

Versions should be unified as "v + zero-padded 2 digits" (v01, v02, v03…). "v1", "ver1", "V1", "_1", and "(1)" will all be treated as distinct notation by the file system, so it is essential for the entire team to agree on a single notation.

Standard file name structure examples:

{YYYYMMDD}_{project-shortname}_{content-name}_{version}.{extension}

Examples:
20260910_abccorp-web_top-design_v01.psd
20260915_abccorp-web_top-design_v02.psd
20260920_abccorp-web_top-design_v03-final.psd

List of Prohibited Practices

Never include the following in file names:

| Prohibited item | Reason | |----------------|--------| | Half-width spaces | URL encoding issues / path errors in shell scripts | | Japanese / full-width characters (web files) | Environment-dependent encoding errors / % encoding in URLs | | / \ : * ? " < > | | Characters reserved by the OS file system | | final, 最終, 完成 | Overlapping version semantics cause confusion | | 新しい, copy, (2) | Auto-generated names that convey no content | | Today's date only | Without a project name and content name, the file cannot be identified later |

Handling File Extensions

Always display extensions and never change them. While macOS hides extensions by default, enable "Show all filename extensions" in Finder during active work. Accidentally modifying an extension will make the file unopenable.

The "final version" problem is widely recognized as a form of confusion unique to Japanese production environments. The root cause is that the term "final" changes meaning depending on the situation.

• At the point of initial proposal to the client: "first draft"
• After incorporating the client's revision instructions: "revised version"
• After receiving the client's final approval: "approved version"
• At the time of submission to the printer or developer: "release version"

Because people try to distinguish these stages with words like "final," "OK," or approved, file names degenerate into constructions like "final_finalOK_absolutely-last."

The Principle: Manage with Version Numbers Alone

The solution is simple. Never use the word "final" at all. Manage files using only a combination of version numbers and status flags.

Version number operating rules:

| Stage | Example file name | Meaning | |-------|------------------|---------| | In progress | _v01.psd | First working file | | For proposal | _v01-proposal.psd | Version presented to client | | After revision | _v02.psd | Revision instructions incorporated | | Approved | _v03-approved.psd | Client approval confirmed | | For release | _v03-release.psd | Exported for implementation / submission |

Status flags such as "-approved" and "-release" should only use labels defined by the team at the start of the project. The core of the rule is that team members do not freely add new flags on their own.

Storing Old Version Files

After approval, do not delete old version files — move them to an _archive folder for storage. If deleted, it becomes impossible to respond to later requests such as "please revert to the earlier proposal" or "I'd like to reference the design from that time."

/project
  /design
    /top-page
      20260910_abccorp-web_top-design_v03-approved.psd  ← Active file
      /_archive
        20260905_abccorp-web_top-design_v01.psd
        20260908_abccorp-web_top-design_v02.psd

This structure creates a clear separation between currently valid files and the archive. Even when a designer, developer, or other contributor opens the folder for the first time, it is immediately apparent which file should be referenced.

When designing folder structure rules, the top priority is a structure that "anyone can understand, whenever they open it."

Standard Project Folder Structure

/{project-shortname}_{YYYYMMDD-start}
  /01_brief        ← Intake sheets, requirements, proposals
  /02_contract     ← Contracts, purchase orders, estimates, NDAs
  /03_reference    ← Reference materials, competitor research, client-provided assets
  /04_design       ← Design files (subfolders by purpose)
    /wireframe
    /visual
    /icon-logo
    /_archive
  /05_dev          ← Coding and implementation files
  /06_content      ← Text copy, image assets, video
  /07_deliverable  ← Deliverables (items to be handed off to the client)
  /08_report       ← Progress reports, meeting minutes, acceptance documents
  /00_admin        ← Miscellaneous administrative files (rarely accessed)

The reason for adding number prefixes is to ensure folders are listed in logical order when sorted. In alphabetical order, "brief" comes before "contract," but in terms of workflow, "brief" (intake) comes first — the number prefix makes this sequence explicit.

Three Principles of Folder Structure Design

Principle 1: Divide folders by "what they are used for," not "who uses them"

For example, do not divide the /design folder by "for the designer" and "for the director." Team members change, but the purpose of files (wireframe, visual, icon) does not. Functional classification outlasts people-based classification.

Principle 2: Maximum three levels of nesting

When folder depth exceeds four levels, paths become long enough to exceed Windows' 260-character limit. Additionally, the cognitive cost of knowing where everything is rises sharply. Keep nesting to a maximum of three levels, and when categorization needs to expand, consider addressing it through naming conventions rather than creating deeper subfolders.

Principle 3: Use half-width alphanumerics as the base for folder names

Japanese folder names like "04_デザイン" look intuitive at first glance, but tend to cause character encoding issues when accessed through terminals, scripts, or cloud APIs. Where Japanese is difficult to avoid, convert consistently to English, such as "04_design."

Designing the Delivery Folder

The /07_deliverable folder requires special treatment. Files in this folder represent final deliverables that have been handed off to the client.

• Do not modify the contents of this folder after delivery
• Include the delivery date in the folder name (e.g., 20260920_final-delivery)
• Store deliverables and the acceptance document in the same folder

This practice makes it easy to track "when what was delivered," enabling immediate responses to later requests such as "please resend that file" or "I'd like to check the version at the time of delivery."

File management naming conventions and folder structure rules must be agreed upon not only within the team, but between the client and the contractor as well. Without agreement, even carefully managed files from the contractor can become "unusable" on the client's end.

Five Items to Agree On

1. Naming convention (notation for date, project name, and version)

When the client's internal naming rules conflict with the contractor's convention, define a project-specific naming convention separately. Unilaterally imposing one party's rules on the other increases naming errors from those unfamiliar with that convention.

2. Standard folder structure template

Document which folder structure will be adopted in a shared document, and have both parties start from the same template.

3. File sharing method and access permissions

Decide which service to use (Google Drive, Dropbox, Notion database, etc.) and who has write permissions to which folders. A setup where "everyone can access all folders" carries a high risk of accidents from accidental operations.

4. Version confirmation procedure

Confirming "which file is the final version" should be done in written form — email or chat text — not verbally. Having a sentence such as "We approve 20260920_abccorp-web_top-design_v03.psd as the final version" allows both parties to reference the version later.

5. Retention period and disposal rules

Particularly for freelance projects, retention arrangements after delivery should be agreed upon. Transaction documents subject to Japan's Electronic Bookkeeping Act (invoices, purchase orders, etc.) are subject to statutory retention period rules. For production draft files, agree on a retention period between the parties.

Example Agreement Format

Add a "File Management Policy" section to the kickoff document at the start of the project, specifying the following content:

[File Management Policy (Project: {Project Name})]

1. Naming Convention
   Format: {YYYYMMDD}_{project-shortname}_{content-name}_{vXX}.{extension}
   Japanese file names: Prohibited
   Spaces: Prohibited

2. Folder Structure
   Shared folder URL: {URL}
   Template reference: {Reference document}

3. Version Confirmation
   Final version confirmation to be documented via {email / chat}

4. Retention Period
   Deliverables: {X} years from delivery date
   Interim drafts: Disposed {Y} months after delivery acceptance

The existence of this single document dramatically reduces the probability of future disputes. Simply having both parties aware that "a rule exists" naturally encourages behavior that follows the naming convention.

File management may appear to be mundane administrative work, but it is the foundation that supports the quality and reliability of the entire project. By putting in place the three essentials at the start of a project — unified file naming, shared folder structure rules, and disciplined version control — the unnecessary cost and friction in later phases can be dramatically reduced.

References

Information on Electronic Bookkeeping Act (National Tax Agency) (2024)

Information Security Top 10 Threats 2024 (IPA) (2024)

Cybersecurity Site for Citizens (Ministry of Internal Affairs and Communications) (2024)