IverTabs
A filename is a small message to somebody who is not currently inside your head. That somebody might be a colleague, a family member, or you after a few busy months. Names such as document-new, final-again, and scan-17 make sense for a moment, then lose the context that made them useful. A good name carries enough context to survive that moment.
The aim is not to squeeze every possible detail into a single line. Long, rigid naming systems are difficult to maintain and unpleasant to read. The aim is to answer the questions that distinguish this file from its neighbors: what it is, which project it belongs to, when the relevant event happened, and whether it is the version somebody should use. Choose the smallest combination that answers those questions reliably.
Begin with the difference that matters
Open a folder where choosing the right file feels difficult. Look at two files you often confuse. Are they different dates, different people, different stages, or different outputs? Your naming rule should make that particular distinction visible. If the problem is draft versus approved, adding a date alone may not solve it.
For a workshop, agenda-draft and agenda-approved distinguish status, while workshop-agenda and workshop-handout distinguish purpose. In a folder containing several events, adding the event name is useful. Inside a folder dedicated to one event, repeating that name in every internal draft may be unnecessary, although exported files need enough context to travel independently.
This distinction between internal and travelling files is important. A file named agenda may be understandable inside one project. The same file attached to an email becomes ambiguous. Before sharing, imagine the recipient saving it among unrelated documents. Add the project or event context they will need without making them rename it themselves.
Choose a readable order
Put the most useful sorting clue first. If you normally browse by date, begin with a date. If you browse by project, begin with the project name. If every file in the folder belongs to the same project, the document type may deserve the first position. There is no reason to use one order for every collection you own.
For dated records, a year-month-day pattern such as 2026-09-12 keeps the components unambiguous. It also makes alphabetic sorting useful when names begin consistently. Decide what the date means: meeting date, publication date, receipt date, or revision date. A consistent format with inconsistent meaning still produces confusion.
Write a one-line explanation beside the collection if the date's meaning is not obvious. “Dates refer to the event, not the day the file was downloaded” can prevent mistakes. Avoid quietly switching the rule halfway through a collection because one file happened to arrive late.
Use ordinary words before abbreviations
Abbreviations save a few characters but can remove the very context a filename needs. A name such as WSP-REV-C2 may be efficient for a team that uses those terms every day. For a personal archive or an occasional collaborator, workshop-handout-reviewed is easier to understand.
Keep abbreviations that are genuinely shared vocabulary. Expand private shorthand, especially names based on a person's initials or a temporary department code. Organizations change, people leave, and a folder can outlive the naming convention that once felt obvious. Readability is a form of future maintenance.
Choose a consistent separator, such as a hyphen or underscore, and avoid decorative symbols. Different systems impose different restrictions, so simple characters are a practical choice for files that travel. Do not rename file extensions casually: changing the visible ending does not convert the underlying file format and can make the file harder to open.
Separate versions from status
A version number answers “Which iteration is this?” A status answers “What may I do with it?” Those are related but different questions. Version 03 might still be a draft, while version 02 might be the last approved release. If approval matters, make it explicit rather than assuming the highest number is safe to distribute.
For a small project, draft, review, and approved may provide enough information. For a longer sequence, use a simple version number such as v01, v02, and v03. Leading zeros help keep short sequences in a predictable alphabetic order. Avoid elaborate software-style numbering unless the team has a real reason for it.
Once an approved file is released, do not overwrite it silently with new content. Create a new working version and record the change when it becomes approved. This protects people who need to know what was actually sent or used, even if the only audience is your future self.
Stop using final as a versioning system
The word final becomes unreliable when every later correction produces final-new or final-final. Replace that pattern with an explicit process. Keep changing work in a draft area and place the approved deliverable in a clearly identified output area. The file's location and name should reinforce each other.
For example, a project may contain workshop-handout-v04-draft in its working folder and workshop-handout-2026-09-12-approved in Deliverables. If a correction is released, preserve the earlier approved file when necessary and identify the replacement clearly. A short change note can explain which file supersedes which.
For low-stakes personal work, you may not need to preserve every iteration. The important point is that deletion or overwriting should follow an intentional rule. Keeping everything forever is not automatically safer if it leaves you unable to identify the authoritative file when you need it.
Let folders supply context without depending on them completely
A filename does not exist in isolation, but it may eventually leave its original folder. Balance these two realities. Internal working files can be shorter because the project folder supplies context. Files likely to be emailed, downloaded, printed, or archived independently need names that remain meaningful elsewhere.
Consider a folder named Kitchen Repair containing measurements, contractor-questions, and material-options. Those names are clear in place. Before sending measurements to another person, kitchen-repair-measurements-2026-09-12 is a more helpful travelling name. You have added context at the boundary where it becomes useful.
Do not duplicate every folder component in every filename by default. A path full of repeated project names can become cumbersome without adding information. Instead, identify which files cross boundaries and give those files stronger standalone names. This keeps everyday work readable while making handoffs more reliable.
Rename in small batches and check dependencies
Bulk renaming is tempting because the result looks immediately orderly. It can also break links, scripts, shared references, or application projects that expect specific filenames. Before changing a large collection, determine whether the files are independent documents or parts of a linked system.
Start with a copy of a small representative set when you are testing a rule. Rename several files, open them through their normal workflow, and check that associated material still appears. For a presentation, that may mean confirming linked media. For a website project, it may mean checking references rather than renaming assets casually.
Keep a record of old and new names during a substantial migration. If your tool offers a preview, inspect it before committing. Look especially for collisions, where two different files would receive the same name, and for rules that accidentally remove meaningful details. Never assume that a neat preview proves the contents are duplicates.
Deal carefully with incoming names
Files arrive with names chosen by other people or generated by applications. Some names contain useful identifiers, such as an order reference or a document number. Keep those identifiers when they matter, even if you add a more readable description. Removing them can make later correspondence harder.
A practical pattern is to preserve the original identifier and add context: a reference number followed by event-invoice or equipment-manual. For documents whose exact original name matters to a workflow, leave the file unchanged and add a companion note or use a containing folder instead.
Do not put sensitive personal information into names merely to make searching convenient. Filenames can appear in shared links, recent-file lists, screenshots, and email attachments. Choose the minimum identifying information needed for the task, and use appropriate access controls for the material itself.
Create a naming guide people will actually read
A useful team guide can fit on one page. State the order of components, the meaning of dates, the allowed status labels, and the location of approved outputs. Add three examples drawn from actual work. Examples often resolve ambiguity faster than a long list of abstract rules.
Explain exceptions too. A file supplied by a partner may need to retain its original name. A software project may require fixed asset names. A historical collection may be more useful if its original identifiers remain intact. Good consistency includes clear exceptions rather than forcing every file into the same mold.
Agree on who changes the rule and how changes are communicated. A naming guide loses value when each person quietly improves it. Review it after a few weeks of real use, remove components that nobody needs, and clarify the distinctions that still cause people to open the wrong file.
A worked example: three versions of a handout
Imagine a reading group with three handout files: notes, notes-new, and notes-final2. Open each one and determine its actual role before renaming. The first contains the original outline, the second contains comments awaiting review, and the third is the version distributed at the September meeting.
Rename the first reading-group-outline-v01, the second reading-group-handout-v02-review, and the third 2026-09-18-reading-group-handout-distributed. Place the distributed copy in the project's deliverables area. The names now express real differences instead of merely recording the order in which somebody happened to save them.
Suppose a correction arrives afterward. Create a revised working copy, then release a clearly identified corrected version if necessary. Add a note explaining the correction and whether recipients should replace the earlier handout. This prevents a future reader from mistaking a later working draft for the material originally distributed.
Test your names with a retrieval drill
Choose five files from different parts of your collection. Hide their surrounding folders and inspect only the names. Can you tell what each file contains and which one is current? You do not need to infer every detail, but you should have enough information to choose a plausible candidate.
Next, search using the words you would naturally remember. If your names contain internal codes but your memory contains ordinary project language, the mismatch becomes visible. Add the missing useful words rather than expanding every name indiscriminately. Searchability improves when names reflect the questions people actually ask.
Finally, ask another person to locate one shared document without coaching. Watch where they hesitate. A successful system should not require the original organizer to translate it. Their confusion may reveal an unclear status label, an unexplained abbreviation, or a distinction that belongs in the folder structure instead.
Maintain the rule without renaming your whole history
Apply the new convention to new work first. Rename older files when you touch them or when a particular collection causes repeated confusion. This gradual approach avoids spending hours on material you may never use again while still improving the areas that create real friction.
During a periodic review, look for symptoms rather than perfection: several files called final, dates with unclear meaning, exported documents that lack project context, or duplicate names with different contents. Fix these cases because they affect retrieval, not because every filename must look identical.
If a rule is repeatedly ignored, investigate why. Perhaps it asks for too many components, requires information people do not know, or solves a problem that does not occur. Simplify the convention until following it is easier than inventing an alternative. A modest naming habit maintained consistently is more useful than an impressive standard abandoned after a week.
A compact starting convention
For a dated event document, try date, project, document purpose, and status when status matters. For a reusable reference, try topic and purpose, keeping edition information if needed. For a working project file, try purpose and version. These are starting patterns, not universal laws.
Write down the meaning of each component before adopting it. If you cannot explain why a component helps somebody find or use the file, consider removing it. The filename should carry decisions that matter, while the document and its containing folder provide the rest of the story.
The best test comes later, when you return without remembering today's details. If the name helps you select the right file confidently, the system has done its job. It does not need to look sophisticated. It needs to remain understandable after the immediate context has faded.
