How Should I Organise My Files and Folders?

Most people have experienced the frustration of searching for a file they know exists but cannot immediately find. A dataset may be stored in an unexpected folder, several versions of the same file may exist, or an important document may have been named in a way that no longer makes sense months later.

These problems are often dismissed as minor inconveniences, but they can have a significant impact on a project. Time spent searching for files, recreating lost work or clarifying which version should be used is time that cannot be spent on research.

Organisation also becomes increasingly important as projects grow. A structure that works well for a handful of files may become difficult to navigate when hundreds or thousands of files have been created. Similarly, systems that make sense to a single researcher may be less effective when multiple collaborators need to access the same materials.

Good organisation is not about creating a perfect folder structure or following a particular naming convention. Rather, it is about making files easier to find, understand and manage throughout the lifetime of a project.

Importantly, there is no single correct way to organise research files. The most appropriate approach depends on the discipline, the type of research being conducted, the size of the project and the needs of the research team.

The goal of this guide is therefore not to provide a single template, but to help you think about how to organise files and folders in a way that supports your research and remains manageable as the project develops.

A file name is often the first piece of information available about a file. When file names are unclear or inconsistent, finding the correct one can become difficult, particularly as the number of files grows.

Names such as

data.xlsx

results_new.xlsx

 final_version_revised.xlsx

may seem sufficient when only a few files exist, but they often become confusing months later or when shared with collaborators.

A useful and meaningful file name should allow someone to understand the content of a file without needing to open it. The exact information included will depend on the project, but file names often indicate some combination of:

• The project, study or experiment
• The type of data or document
• A participant, sample or site identifier
• The date
• The version number

For example:

The goal is not to include as much information as possible. Extremely long file names can become difficult to read and maintain. Instead, aim to include the crucial pieces of information that will help you and your collaborators search and retrieve the file quickly.

Can the File Stand on Its Own?

Files are often organised within folders that provide additional context. For example, a file called:

Interview_012.docx

may make perfect sense when stored in:

Project_A/
└── Interviews/

However, files do not always remain in their original location. They may be emailed to collaborators, downloaded from shared storage, copied into other folders or deposited in repositories. Once separated from their original context, a file name that relies heavily on the folder structure may become difficult to interpret.

A useful test is to imagine that all files from a project have been placed into a single folder. Would you still be able to understand what a file contains without opening it?

For example:

Interview_012.docx

provides relatively little information on its own, whereas:

ProjectA_Interview_Participant-012_2026-08-08.docx

immediately provides additional context about the project, content and date.

This does not mean that every file name should contain every possible detail. Rather, file names should contain enough information to remain meaningful even when separated from their original folder structure.

There Is No Single Correct Naming System

People sometimes look for the "right" naming convention. In practice, there is rarely a single correct approach.

For example, some projects place the date at the beginning of the file name:

2026-08-08_Interview_012.docx

This approach makes it easy to sort files chronologically.

Other projects place the type of data first:

Interview_012_2026-08-08.docx

This can make it easier to group similar files together.

In a multi-project environment, researchers may choose to begin file names with a project identifier:

ProjectA_Interview_012_2026-08-08.docx

The best approach depends on how the files will be used and searched. Consistency is usually more important than the exact format chosen.

Why Use ISO Dates?

Dates often appear in file names because they provide useful context and can help distinguish between files created at different times.

When dates are included, it is generally helpful to use the international ISO 8601 format:

YYYY-MM-DD

For example:

2026-07-08

This format has two advantages. First, it avoids ambiguity. A date such as 07-08-2026 may be interpreted differently in different countries (it could be DD-MM-YYYYor MM-DD-YYYY).

Second, files sort correctly when arranged alphabetically. For example:

2026-01-15
2026-03-02
2026-08-08
2026-11-21

will automatically appear in chronological order.

How Computers Sort File Names

A naming system that looks sensible to a person may not always sort or behave as expected on a computer.

For example, computers typically sort file names alphabetically rather than numerically. This means that:

Sample_2.csv
Sample_10.csv
Sample_11.csv
Sample_1.csv

may appear in this order:

Sample_1.csv
Sample_10.csv
Sample_11.csv
Sample_2.csv

rather than:

Sample_1.csv
Sample_2.csv
Sample_10.csv
Sample_11.csv

Using leading zeros can help maintain the intended order:

Sample_01.csv
Sample_02.csv
Sample_10.csv
Sample_11.csv

For example, if you expect to generate more than one hundred files but fewer than one thousand, it may be useful to use three digits from the start:

Sample_001.csv
Sample_002.csv
...
Sample_999.csv

This ensures that files remain in the correct alphabetical order as the project grows. If the numbering starts without or not enough leading zeros, a computer may sort files as:

Sample_1.csv
Sample_10.csv
Sample_100.csv
Sample_2.csv

which can make files more difficult to navigate.

Similarly, dates written using the ISO format (YYYY-MM-DD) sort naturally in chronological order. Formats such as 09-12-2026 or 10-08-2025 may not.

For example:

09-12-2026
10-08-2025

would typically be sorted alphabetically as shown above, meaning that 9 December 2026 appears before 10 August 2025, even though it is the later date.

Using ISO dates avoids this problem:

2025-08-10
2026-12-09

which automatically sort in chronological order.

Choosing Characters Carefully

Some characters that appear harmless in a file name can create problems when files are moved between operating systems, uploaded to repositories or processed by software.

It is therefore generally recommended to avoid:

• Spaces
• Special characters such as /, \, :, *, ?, ", <, > and |
• Characters that may not be handled consistently across the systems, software or repositories used in the project (e.g. accented characters)

Instead, separators such as underscores (_) or hyphens (-) are often used.

For example:

Interview Participant "012" - 2026-08-07.docx

could be written as:

Interview_Participant-012_2026-08-07.docx

Many researchers use underscores (_) to separate different elements of a file name and hyphens (-) to separate words within an element. This can make file names easier to read while preserving a clear structure.

For example:

Interview_Participant-012_2026-08-07.docx

may be easier to interpret than:

Interview-Participant-012-2026-08-07.docx

because the different components of the file name are more clearly separated. In this example, it is immediately apparent that the file contains an interview, relates to participant 012 and was created on 7 August 2026.

Consistency Matters More Than Perfection

There is no universally accepted convention, however. The most important consideration is to choose a system that is clear, consistent and understandable to everyone working on the project.

Do not spend considerable time searching for the ideal naming convention. In practice, a simple and consistent system is usually more effective than a complex system that is only followed some of the time.

If collaborators can easily understand file names, files can be found quickly, and the system continues to work as the project grows, then the naming approach is probably doing its job.

Questions to Consider

• Can you understand what a file contains without opening it?
• Would a collaborator understand the file name?
• Does the naming approach work consistently across the project?
• Will files sort in a useful way?
• How will different versions of the same file be distinguished?

A file naming system does not need to be complicated. The most important goal is to create names that remain understandable and useful throughout the lifetime of the project.

Optional: Advanced Naming Conventions

For small projects, agreeing on the information included in file names is often sufficient. In larger projects, however, it can also be useful to agree on how that information should be written.

For example, collaborators may use different approaches to capitalisation:

Interview_012.csv
interview_012.csv
INTERVIEW_012.csv

Although these names refer to the same type of file, the differences can make a project appear less consistent and may complicate searching, filtering or automated processing.

For this reason, some teams agree on additional naming conventions before data collection begins.

Common approaches include:

You do not need to adopt a particular convention. However, it can be useful to decide in advance:

• Whether file names begin with a capital letter or a lowercase letter
• Whether specific elements should always be capitalised
• Whether underscores or hyphens will be used consistently
• Whether abbreviations should follow a common format

Some projects also use capitalisation to make important parts of a file name easier to identify. For example:

DATA_Interview-012_2026-08-08.csv

may be easier to scan quickly than:

data_Interview-012_2026-08-08.csv

because the file category is immediately visible.

The specific convention matters less than applying it consistently. A simple naming system that everyone follows is usually more effective than a sophisticated system that is applied inconsistently.

Just as there is no single correct way to name files, there is no universal folder structure that works for every research project.

A folder structure should help anyone working on the project find information quickly, understand how files relate to one another and keep different parts of a project organised as it grows. The most appropriate structure will depend on the type of research being conducted, the size of the project and the way the research team works.

When designing a folder structure, it can be useful to think about how you naturally look for information. For example, do you usually think in terms of project stages, data types, study sites or work packages? A folder structure that reflects the way researchers actually work is often easier to maintain than one that follows a generic template.

Folders Should Reflect How the Project Works

Many projects naturally divide into distinct activities. For example, researchers may collect data, process them, analyse them and eventually prepare publications or reports.

In these cases, a structure based on project stages may be useful:

Project/
├── 01_Planning
├── 02_Data_Collection
├── 03_Data_Processing
├── 04_Analysis
├── 05_Publications
└── 06_Documentation

Other projects may be organised around different types of material:

Project/
├── Data
├── Code
├── Documentation
├── Figures
└── Outputs

Projects involving multiple study locations may instead be organised by site:

Project/
├── Site_A
├── Site_B
└── Site_C

Large collaborative projects are often structured around work packages or project tasks:

Project/
├── Work_Package_1
├── Work_Package_2
├── Work_Package_3
└── Work_Package_4

Other structures are also possible. A clinical study might organise data by participant groups, an environmental project by sampling campaigns, or a digital humanities project by archive or collection.

Neither approach is inherently better. The most useful structure is often the one that matches how researchers interact with the project on a daily basis. If researchers primarily think in terms of sites, work packages or study phases, the folder structure should reflect that logic.

Controlling the Order of Folders

Most operating systems display folders alphabetically by default. This means that the order in which folders appear may not always reflect the order in which activities take place during a project.

For example:

Analysis
Data_Collection
Documentation
Planning
Publications

will typically be displayed alphabetically, even though planning occurs before data collection and analysis.

If you want folders to appear in a specific order, a common approach is to add numbers at the beginning of the folder names:

01_Planning
02_Data_Collection
03_Data_Processing
04_Analysis
05_Publications
06_Documentation

Remember, that using leading zeros (01, 02, 03) helps ensure that folders continue to sort correctly if additional folders are added later.

Numbering folders can be particularly useful when organising projects around stages, workflows or other sequences where the order is important.

Keep Raw and Processed Data Separate

One of the most common sources of confusion is mixing original data with modified versions.

For example, a researcher may collect survey responses and later clean the data, correct errors or transform variables for analysis. If original and modified files are stored together, it can become difficult to determine which files represent the original data and which contain later changes.

Many projects therefore separate raw and processed data:

Project/
├── Raw-Data
├── Processed-Data
└── Documentation

This can make it easier to retrace the steps that led from data collection to analysis and reduce the risk of accidentally overwriting original files.

Avoid Structures That Become Difficult to Navigate

A common temptation is to create increasingly detailed folder hierarchies as a project grows.

For example:

Project/
└── Data/
    └── Site_A/
        └── Interviews/
            └── Round_1/
                └── Cleaned/
                    └── Final/

Deep structures can become difficult to navigate and may make it harder to locate files quickly.

The opposite extreme can also create problems. Storing hundreds of unrelated files in a single folder may make it difficult to understand how files relate to one another.

The goal is usually to find a balance between too many folders and too few.

Use Folder Names That Are Meaningful

Folder names should help everyone understand what they are likely to find inside.

Names such as:

Data
Analysis
Documentation

are often easier to understand than:

Misc
Old
New
Stuff

Folder names should remain meaningful not only to the person who created them but also to collaborators and future project members.

Think About the Structure Before the Files Arrive

Folder structures are often easiest to establish before large numbers of files have been created.

This does not mean every folder must be planned in advance. However, creating a basic structure at the beginning of a project can help ensure that files are stored consistently from the start rather than requiring large-scale reorganisation later.

Questions to Consider

When designing a folder structure, consider questions such as:

• How do researchers usually look for information in the project?
• Would a new team member understand the structure?
• Are raw and processed data clearly separated?
• Can files be located quickly?
• Is the structure likely to remain manageable as the project grows?
• Does the structure reflect how the research is actually organised?

A folder structure does not need to be complex to be effective. The most successful structures are often those that are simple enough for everyone in the project to understand and use consistently.

The following examples illustrate common situations where small changes to file names or folder structures can make research data easier to understand, search and manage.

Example 1: Making Files Understandable Outside Their Folder

A team collects water samples at three different sites.

Initial organisation:

Project/
├── Site_A
│   ├── WaterSample_001.csv
│   └── WaterSample_002.csv
├── Site_B
│   ├── WaterSample_001.csv
│   └── WaterSample_002.csv
└── Site_C
    ├── WaterSample_001.csv
    └── WaterSample_002.csv

This works until files are copied into a shared analysis folder:

WaterSample_001.csv
WaterSample_001.csv
WaterSample_001.csv

Improved version:

Project/
├── Site_A
│   ├── Site-A_WaterSample_001.csv
│   └── Site-A_WaterSample_002.csv
├── Site_B
│   ├── Site-B_WaterSample_001.csv
│   └── Site-B_WaterSample_002.csv
└── Site_C
    ├── Site-C_WaterSample_001.csv
    └── Site-C_WaterSample_002.csv

Why?

The file name now retains enough context to remain understandable when separated from its folder.

Example 2: Avoiding Special Characters and Accented Characters

A literature review project stores articles by author name.

Initial organisation:

François-Dupont.pdf
Björk-Andersson.pdf
José-García.pdf

Modern systems usually handle these names correctly, but problems can occasionally arise when files are transferred between systems, uploaded to repositories or processed automatically.

Possible alternative:

Francois-Dupont.pdf
Bjork-Andersson.pdf
Jose-Garcia.pdf

Why?

This can improve interoperability across systems. However, projects should balance technical considerations against the importance of preserving names accurately. The decision should be made consciously and applied consistently.

Example 3: Different Parts of a Project May Need Different Naming Systems

A project contains various work packages.

WP1 contains data related to a literature review.

Researchers usually search for papers by author name.

WP1_Literature_Review/
├── Smith_2024.pdf
├── Dupont_2023.pdf
└── Garcia_2022.pdf

WP2 contains sensor measurements.

Researchers usually search by collection date.

WP2_Sensor_Data/
├── 2026-08-01_SensorData.csv
├── 2026-08-02_SensorData.csv
└── 2026-08-03_SensorData.csv

Why?

The best naming system depends on how researchers actually look for information. Different parts of the same project may legitimately use different approaches.

Example 4: When File Names Become Too Long

Researchers sometimes try to include every available detail in a file name:

2026-08-08_France_Paris_Hospital-3_CardiologyDepartment_ResearchAssistant-MarieDubois_PatientGroup-B_BLOOD-PRESSURE-Study_MorningMeasurement_Session-2.csv

While informative, names like this can become difficult to read and maintain.

A shorter alternative might be:

2026-08-08_BPStudy_Group-B_Session-2.csv

with additional details recorded elsewhere in the project documentation.

Why?

File names should contain enough information to identify and locate files, but they do not need to replace documentation. If researchers never search by hospital, collector name or department, those details may not belong in the file name.

A useful question is:

Which pieces of information do researchers actually use when searching for this file?

Example 5: Organising Personal Data

A clinical study collects blood results and physical performance measurements from participants.

Participants are assigned study identifiers:

P001
P002
P003

rather than using names.

Option A: Organise by Data Type

Project/
├── Blood-Results
│   ├── Blood_P001.csv
│   ├── Blood_P002.csv
│   └── Blood_P003.csv
└── Physical-Tests
    ├── PhyTest_P001.csv
    ├── PhyTest_P002.csv
    └── PhyTest_P003.csv

This structure may be useful if researchers typically analyse one type of measurement across all participants.

Option B: Organise by Participant

Project/
├── P001
│   ├── P001_Blood.csv
│   └── P001_PhyTest.csv
├── P002
│   ├── P002_Blood.csv
│   └── P002_PhyTest.csv
└── P003

This structure may be useful if researchers usually work with all information relating to a specific participant.

Why?

Neither structure is inherently better. The most useful structure depends on how the research team accesses and analyses the data.

Organising files becomes more challenging when multiple people contribute to the same project. Even a well-designed structure can quickly become difficult to maintain if different team members follow different practices.

Before work begins, it can be useful to agree on a few basic rules that everyone will follow.

Agree on Naming Conventions

If team members use different naming approaches, files can become difficult to locate and sort consistently.

The project should therefore agree on:

• How files will be named
• How dates will be written
• Which abbreviations will be used
• Any capitalisation conventions

The goal is not to create complex rules, but to ensure consistency across the project.

Agree on the Folder Structure

Similarly, collaborators should share a common understanding of where files belong.

Without an agreed structure, different people may create their own folders or organise information in different ways, making it harder for others to find what they need.

The folder structure does not need to be fixed forever, but any changes should be communicated to the rest of the team.

One Shared Space or Many?

Research projects often use multiple storage systems at the same time, such as institutional servers, cloud storage platforms, personal computers and specialised research infrastructures.

This is not necessarily a problem, but it is important to establish which location should be considered the primary or 'authoritative' source for project files.

Without a clear answer, different versions of the same file may begin to circulate, making it difficult to know which version should be used.

When multiple storage locations exist, researchers should understand:

• Where the authoritative version is stored
• Which copies are working copies or backups
• How changes are synchronised between locations

Planning for New Team Members

Research teams change over time. New researchers, students or collaborators may join after the project has already started.

A project should therefore be organised so that someone new can understand the structure without relying entirely on explanations from existing team members.

Simple documentation explaining the folder structure and naming conventions can make onboarding significantly easier.

Questions to Consider

When organising a shared project, consider questions such as:

• Has the team agreed on a naming convention?
• Has the folder structure been agreed upon?
• Is there a clearly identified authoritative version of project files?
• Are researchers using multiple storage locations?
• Could a new team member understand the organisation of the project?
• Are organisational decisions documented somewhere?

Good organisation is not only about creating a structure. It is also about ensuring that everyone involved in the project understands and follows it consistently.

No folder structure remains perfect forever. As projects evolve, new data types may be introduced, additional collaborators may join and workflows may change.

For example, researchers often begin with a simple structure:

Data

A few months later, it may look more like:

Data
├── Old
├── New
├── Really_New
├── Final
├── Final_2

When folders and file names start appearing simply to compensate for organisational problems, it is often a sign that the current structure no longer supports the project effectively.

When Changes May Be Necessary

A folder structure should evolve when it no longer supports the way the project operates. New data types, additional collaborators or changes in workflow may all justify revisiting the organisation of the project.

A review of the structure may be worthwhile if:

• Researchers regularly struggle to find files.
• New types of data are being created.
• The project has expanded significantly.
• Additional collaborators have joined the project.
• Existing folders have become overcrowded.
• Files are frequently being stored in the wrong location.
• The current structure no longer reflects how the project is organised.

However, changes should be planned rather than emerging gradually through ad hoc additions of new folders and naming conventions.

Before making changes, consider:

• What problem is the change intended to solve?
• Will the new structure be easier to understand?
• Will it remain useful as the project continues to grow?

Document Major Changes

If a project is shared with others, major changes to the folder structure should be documented and communicated.

This helps collaborators understand where files have moved and reduces confusion when referring to project documentation, workflows or shared resources.

Avoid Constant Reorganisation

While changes are sometimes necessary, frequent reorganisation can create its own problems.

Moving files repeatedly can make documentation inaccurate, break links between files and create confusion among collaborators. Team members may also struggle to find information if folders change frequently.

Before introducing a major change, it can be useful to ask:

A structure that is understood and used consistently is often preferable to a theoretically better structure that changes every few weeks.

Consider the Impact on Others

In collaborative projects, changes to folder structures affect everyone who uses them.

Before reorganising shared folders, consider:

• Will collaborators still be able to find their files?
• Do project documents refer to existing folder locations?
• Are automated workflows affected?
• Has the change been communicated to the team?

A small improvement for one person can sometimes create confusion for everyone else.

Questions to Consider

When reviewing a file and folder structure, consider questions such as:

• Does the current structure still reflect how the project works?
• Are researchers able to find files quickly?
• Will changing the structure solve a real problem?
• How will collaborators be affected?
• Has the change been documented and communicated?

A good structure is not necessarily one that never changes. It is one that can adapt when necessary while remaining understandable and consistent for everyone involved in the project.

• Organise files and folders from the beginning of the project.
• Use file names that remain understandable outside their folders.
• Choose a naming convention and apply it consistently.
• Use dates and numbering in a way that sorts correctly.
• Avoid unnecessary special characters in file names.
• Design folder structures around how the project works.
• Different projects may require different organisational approaches.
• Record information in documentation rather than trying to put everything in file names.
• Agree on naming conventions and folder structures in collaborative projects.
• Identify the authoritative location for project files.
• Document organisational decisions so others can follow them.
• Update the structure when it no longer supports the project.
• Avoid reorganising files and folders without a clear reason.