How to Name and Organize Design Project Files

Good file organization makes design work easier to hand off, revise, approve, and reuse. A consistent system helps you find the correct logo, export the right campaign version, and understand what changed without opening every file.

Start With a Naming System You Can Repeat

The best naming convention is not the most elaborate one. It is the one that your team can apply consistently when creating a file at the end of a busy day. Before renaming anything, decide which pieces of information are genuinely useful for identifying a file.

A practical design filename usually includes:

• The project or client name
• The deliverable or asset type
• The intended channel or size, when relevant
• The status or version
• The date, if the date matters to the workflow
• The file extension, which should remain visible

For example:

acme-spring-launch-instagram-post-v03-approved-2026-09-23.psd

You may not need every element in every project. A small internal flyer might only need team-retreat-poster-v02.indd. A large campaign with many contributors may need the longer format.

Choose one order and keep it stable. A useful pattern is:

project-deliverable-channel-version-status-date.extension

Avoid switching between formats such as Final_Logo, Logo_final2, and logo_USE_THIS_ONE. Those names communicate urgency, not reliable information. If a file is approved, record that clearly; if it is still being edited, use a draft or working label instead.

Use Clear, Searchable Words

Name files for the words another person would search for six months later. Use descriptive nouns and avoid private shorthand that only one designer understands.

Prefer:

• northstar-brand-guidelines
• homepage-hero-desktop
• product-packaging-front-panel
• holiday-sale-email-header

Avoid:

• stuff
• new design
• thing 2
• latest
• misc assets

Use a consistent separator, such as hyphens or underscores. Hyphens are usually easy to read and work well in URLs and command-line tools, while underscores can make long names harder to scan. Do not mix separators randomly.

Keep capitalization predictable. Lowercase filenames are often the least troublesome when files move between Windows, macOS, servers, cloud storage, and web systems. If your organization already uses title case, keep using it consistently rather than creating a second standard.

Avoid characters that can cause syncing or export problems. A safe filename generally excludes:

• Slashes and backslashes
• Colons, asterisks, question marks, and quotation marks
• Angle brackets and vertical bars
• Emojis
• Excessive punctuation

Also avoid trailing spaces and extremely long names. A filename should explain the file without becoming a paragraph.

Build a Folder Structure Around the Workflow

A good folder structure mirrors how a project moves from brief to production to delivery. The exact labels can vary, but the hierarchy should answer three questions quickly: what project is this, what stage is it in, and what kind of asset is inside?

A useful starting structure is:

client-project/
├── 00_admin/
├── 01_brief-research/
├── 02_working-files/
├── 03_review/
├── 04_approved/
├── 05_exports/
├── 06_assets/
└── 99_archive/

Numbered folders keep stages in the intended order. The leading zero matters when a project grows beyond nine folders, because 02 will sort before 10.

The folders can have more specific subfolders:

02_working-files/
├── illustrator/
├── photoshop/
├── indesign/
└── motion/

05_exports/
├── web/
├── social/
├── print/
└── presentation/

Do not create folders merely because you can. Too many nested levels slow people down and encourage files to be stored in random locations. If a folder contains only one or two files, ask whether that category is necessary.

Keep source files separate from exports. A flattened JPEG or PDF may be useful for delivery, but it should not be confused with the editable Illustrator, Photoshop, Figma, InDesign, or After Effects source. Separating them reduces the chance that someone edits an outdated export instead of the master file.

Separate Working, Review, Approved, and Archived Versions

Version control is one of the most important parts of file organization. A version number should describe progression, not emotional confidence. Use v01, v02, and v03 as a sequence, and increment the number whenever a meaningful revision is saved for review or handoff.

A simple status system might look like this:

Status	Meaning	Typical action
wip	Work in progress	Designer is actively editing
review	Ready for feedback	Stakeholders should comment or approve
approved	Accepted for the stated use	Use for final production or export
archive	Retained for reference	Do not edit unless intentionally restored

Use status labels carefully. If v05-approved is later changed, do not overwrite it and keep the same name. Create v06-review or v06-approved, depending on the new state. An approved file should be treated as a record of what was accepted at that point.

For collaborative projects, distinguish between a working file and a review package. For example:

• evergreen-brochure-v07-wip.indd
• evergreen-brochure-v08-review.pdf
• evergreen-brochure-v08-approved.indd
• evergreen-brochure-v08-approved-print.pdf

The review PDF and editable source can share a version number while retaining different extensions and purposes. This makes it easier to verify that the delivered export came from the approved source.

Avoid names such as final-final, final-revised, or final-new. If you need to distinguish two approved variations, use a meaningful descriptor such as approved-a4 and approved-us-letter, or approved-dark-background and approved-light-background.

Manage Dates, Versions, and File Metadata

Dates are useful when they answer a real question: when was the file delivered, when was a campaign published, or which revision belongs to a specific meeting? Use the unambiguous YYYY-MM-DD format, such as 2026-09-23. It sorts chronologically and avoids confusion between day-first and month-first formats.

Do not use dates as a substitute for version numbers. A designer may save several revisions on the same day, and a file created later is not necessarily the approved one. When both matter, use both:

civic-center-brochure-v04-approved-2026-09-23.indd

Add useful information to the file itself when possible. Include document properties, a cover page, or a small internal note with details such as:

• Owner or responsible team
• Dimensions and color mode
• Fonts or linked assets used
• Intended audience or channel
• Approval date
• Production notes

Metadata should support the filename, not replace it. Cloud storage search may not index every application-specific field, and metadata can disappear when files are exported or converted.

Keep Assets, Links, and Fonts Under Control

Many design files depend on external assets. A neatly named source file can still break if its linked images, fonts, or plugins are scattered across personal folders.

Create a project asset directory with categories such as:

06_assets/
├── brand/
├── photography/
├── illustration/
├── icons/
├── logos/
├── fonts-info/
└── licensed-materials/

Store only assets that the project is allowed to use. Record licensing information for stock photography, typefaces, music, templates, and third-party graphics. If a font cannot legally be shared, keep a text note with its name, supplier, license owner, and installation instructions rather than copying the font file into the project.

When an application supports packaging, use it before handoff. Packaging gathers linked files and other dependencies into a controlled location, but inspect the package afterward. Packaging may copy more material than needed, miss unsupported dependencies, or create duplicates. Open the packaged source on another computer or have a teammate check it before delivery.

For shared libraries, decide which items are authoritative. If a team uses a cloud brand library, do not also keep multiple unofficial logo collections in every project. A project may contain a snapshot of the approved logo used at delivery, but it should identify the source and date.

Establish Team Rules for Collaboration

A naming system fails when every contributor interprets it differently. Put the rules in a short README file at the project root. It should include examples rather than a long theoretical explanation.

Your README can state:

• The required filename pattern
• Which separator to use
• How version numbers increase
• Which statuses are allowed
• Where source files and exports belong
• Who can mark a file approved
• What belongs in the archive
• How to handle urgent exceptions

Decide whether cloud tools, design platforms, or project-management systems are the source of truth. A folder should not contain one status while the task tracker contains another. If comments are collected in a design platform, keep the exported review file clearly connected to that discussion.

Use file locking, check-out rules, or branch-style duplication when the application supports them. If two people edit the same source independently, rename their copies immediately, such as v09-designer-a and v09-designer-b. After choosing a direction, create a new consolidated version rather than silently replacing one contributor’s work.

Do not put sensitive information in filenames. Client passwords, private customer names, unpublished product details, and confidential campaign language can be exposed through sync logs, email attachments, or shared links. Use internal project IDs where necessary.

Archive Projects Without Losing Context

When a project is complete, archive it deliberately. An archive should preserve enough information for future maintenance without becoming an unsearchable dump of every temporary experiment.

Before archiving:

1. Remove obvious duplicates and accidental downloads.
2. Confirm that the approved source opens correctly.
3. Keep the final exports that were actually delivered.
4. Collect or document linked assets and fonts.
5. Add a README with owner, completion date, software requirements, and notes.
6. Move obsolete drafts into a clearly labeled archive subfolder or delete them only if policy allows.
7. Verify that the archive is included in the organization’s backup system.

Do not delete old versions simply because a newer one exists. Earlier versions may document decisions, support legal or client questions, or help restore a design when requirements change. Instead, distinguish active files from historical files.

Use a retention policy for large projects. For example, retain approved deliverables and the final editable source indefinitely, but keep daily working snapshots for a defined period. The correct period depends on client agreements, industry regulations, storage costs, and the likelihood of future revisions.

Troubleshoot Common File-Organization Problems

If someone cannot find the correct file, begin by searching for the project name, deliverable, and approximate date separately. The problem may be inconsistent naming rather than missing data. Once located, rename the file using the current standard and record the change if others may still use the old name.

If several files appear to be final, compare their version numbers, modification dates, approval status, dimensions, and export settings. Open the source and inspect the actual content instead of trusting the filename alone. Then mark one file as authoritative and move superseded versions into an archive location.

If links are missing, use the application’s relink or package feature. Avoid relinking blindly to similarly named files; confirm dimensions, crop, color profile, and revision date. For future projects, keep linked assets inside a project-controlled folder and avoid paths tied to one person’s desktop.

If cloud syncing creates conflicts, stop editing the conflicting copies and identify which version contains the latest intentional changes. Create a new merged version, then archive the conflicting copies with explanatory names. Do not repeatedly rename conflict files without documenting the decision.

If filenames become too long, shorten repeated terms and move context into folders or a README. For example, store campaign-specific files inside client-campaign/ rather than repeating the full client and campaign name in every filename. Retain the information that helps search and remove decorative words.

A Practical Daily Routine

At the beginning of a project, create the folder template, add the README, and agree on the filename pattern. During production, save meaningful versions instead of creating many ambiguous duplicates. Before sending work for review, update the status and export a review copy into the correct folder.

When feedback arrives, create the next version before making major changes. After approval, protect the approved source from casual edits and export delivery files using names that identify the channel, dimensions, and format. At the end of the project, clean the asset folder, document dependencies, and archive the result.

The goal is not perfect administration. The goal is that another person can open the project, understand what each folder contains, identify the latest approved source, and continue the work without needing a private explanation from the original designer.