Version Names That Survive a Handoff: A Naming Test with 40 Files
Forty files were renamed under a single scheme, and the time needed to identify the newest one fell from 74 seconds to 9. The test took place in a marketing team that had never agreed on a naming rule and had strong opinions about starting one.
The team produced campaign assets for four brands, with two designers, one copywriter and a shared drive that had been in use since 2019. Nobody could say how many files existed, which was part of the problem.
The 74-second baseline
Five people were timed opening the drive and answering one question: which file is the current version of the spring catalogue. Each was timed separately on the same folder, with no help and no conversation. The median was 74 seconds, the slowest was 3 minutes 20 seconds, and one person answered with a file that had been superseded twice.
The folder held 40 files for that catalogue, all of them plausibly named.
The five schemes people proposed
Five naming schemes were suggested in the first meeting. One put the date first, one put the brand first, one used a running number, one embedded the designer’s initials, and one argued for no scheme at all on the grounds that search was good enough.
The search argument was plausible and easy to test. A search for the word spring returned 31 results across four folders.
The scheme that won
The winning scheme was the dullest: brand, asset type, version number, date in reverse order. Four tokens, separated by hyphens, no spaces and no initials. Initials were excluded because people leave and the initials outlive them.
It won because it survived the handoff test. A person who had never seen the folder could sort alphabetically and get the newest file at the bottom of each group.
The migration
Renaming 40 files took under an hour with a script. Renaming the other 3,400 files in the drive took three afternoons spread over two weeks, because each rename had to be checked against a link in a document or a campaign brief.
Eleven links broke during the migration and were repaired by hand.
What broke in practice
The scheme has one weak point that showed up in month two: two people created a version 4 on the same day for different reviewers. The rule had no field for the reviewer, so both files were correct and neither was distinguishable without opening it.
The team added a fifth token for the recipient’s team, not their name. That fixed the case without reintroducing the initials problem.
Eleven weeks on
The same five people were timed again on the same question. Median time fell to 9 seconds. Nobody answered with a superseded file. A new joiner who had never seen the drive answered correctly in 14 seconds on her first attempt.
The cost of migrating 3,400 files
The migration was the expensive part and it was underestimated by a factor of three. Three afternoons went into checking each rename against a document or a brief, and eleven links broke. Two of the broken links sat inside a client-facing deck that had been sent a week earlier, which produced a short and deserved complaint.
A cheaper approach existed and was rejected: rename only files created after a cut-off date and leave history alone. It was rejected because the folder would then carry two naming systems and nobody would remember which applied to which year.
What the scheme cannot encode
The five-token name describes a file but not its status. Nothing in the name says whether a version has been approved, only that it exists and when. The team considered adding a status token and dropped the idea, because people would write draft into an approved file and the token would become decoration.
That decision pushed status to a separate place, which is the review channel. The name answers what and when. It does not answer whether.
Forty files once took 74 seconds to disambiguate. They now take 9, and the gain came from a naming rule that fits on one line, not from better software or a cleaner drive.
