Your File Naming Convention Is a Design Decision

A messy file naming convention looks, on its face, like a purely administrative problem - the kind of thing that might annoy a particularly tidy-minded person but doesn't actually affect the work. That reading turns out to be wrong, and wrong in a specific, traceable way. When nobody can quickly tell which file is the current version of a given flow, the default behavior isn't confusion, exactly - it's duplication. Someone can't find the file with confidence, so they make a new one, because starting fresh feels safer than building on top of something they're not sure is even the right base to build on.

That single, individually reasonable decision - better safe than sorry, just make a new copy - compounds fast once it's repeated across a team over months. What starts as one ambiguous file becomes three or four diverging copies of the same flow, each edited independently by someone who had no way of knowing the others existed, none of them clearly marked as canonical, each slightly out of sync with the others in ways that only surface later. Nobody set out to create four versions of the checkout flow. Each person just made the locally sensible choice not to risk building on top of a file they weren't sure was current, and those individually sensible choices summed into a genuinely bad outcome.

It's worth taking seriously the version of the counterargument that comes from teams using modern design tools with built-in project structures, shared libraries, and real version history: doesn't that infrastructure already solve this, making a naming convention a solved problem from an earlier, more chaotic era of shared folders and email attachments? It solves a meaningful part of it - nobody's emailing zip files around anymore, and that's real progress. But infrastructure solves the mechanical problem of storage and access. It doesn't solve the human problem of scanning a list of forty files, at speed, under deadline pressure, and knowing at a glance which one is safe to build on and which one is a stale exploration somebody abandoned two sprints ago.

A simple, consistently enforced naming convention removes an entire category of coordination overhead that most teams don't notice they're paying until the day it's fixed and the difference becomes obvious in hindsight. The specific scheme matters less than the fact that everyone actually follows it: project, then flow, then version, then status - something like Checkout_GuestFlow_v3_inReview - read left to right, answering exactly the questions someone glancing at a file list actually has. What project is this. What flow within that project. Which version, and is it still being actively worked on or already signed off.

What that looks like in daily practice is less dramatic than it might sound, which is exactly why it's easy to underrate: someone joining a project mid-stream can scan a file list and immediately identify the current, active version without needing to ask anyone. A designer picking up someone else's flow after they've gone on leave doesn't have to message three people to confirm which of five similarly-titled files is safe to extend. A stakeholder reviewing progress can tell from the file name alone whether they're looking at something still in exploration or something already approved, without opening it and hoping the content inside confirms one or the other.

The edge case where this discipline earns its cost most visibly is exactly the moment teams tend to skip it under pressure: handoff, whether to a new hire, a different team, or an outside partner picking up a project partway through. Someone with zero accumulated context, who's never sat in the threads where everyone else silently agreed which file was current, has to be able to figure that out purely from what's in front of them. A consistent convention makes that possible in minutes. Its absence turns it into an afternoon of archaeology - comparing timestamps, opening five files to check which one actually matches what shipped, and eventually just asking around and hoping someone remembers.

There's a fair objection worth naming directly: doesn't enforcing a naming convention just add process overhead of its own, one more rule for people to remember and get subtly wrong under deadline pressure? In isolation, yes - any convention that has to be manually remembered and applied correctly every single time will occasionally get applied inconsistently, and a status tag that never gets updated after a file moves from draft to approved is arguably worse than no tag at all, because it actively misleads instead of just being silent. The realistic fix isn't perfect individual discipline; it's making the convention short enough to actually stick, and periodically auditing the handful of files that matter most rather than expecting flawless compliance from everyone at all times.

What makes this genuinely a design decision, and not merely a filing-cabinet housekeeping task, is that the naming scheme actively shapes how a team perceives its own product structure. A convention organized around discrete projects and flows, each with a clear owner and a clear current version, subtly reinforces thinking about the product the same way - as a set of distinct flows with clear boundaries and owners. A convention that's just dates and initials, with no reference to the product's actual structure, reinforces nothing, and the file system ends up telling the team no more about how the product is organized than a pile of scanned receipts would.

This connects to something worth watching for as a team scales past the size where everyone can just remember which file is current through sheer shared context. Below a certain headcount, informal naming survives on tribal knowledge alone - small teams patch over structural gaps with memory and proximity, several people simply knowing the answer without a system enforcing it. Past that threshold, tribal knowledge stops covering the gaps fast enough, and the lack of a real convention, previously invisible because nobody needed it made explicit, becomes suddenly, visibly costly, usually right around the same time as the first serious handoff or the first hire who wasn't there for the shared history.

It's a small, unglamorous fix by any measure, and it will never be the thing a team is proud of shipping or the detail anyone brings up when describing what makes their process good. But it's one of the highest-leverage process changes available to a design team precisely because of where it sits structurally: it removes friction from literally every other task that touches a shared file, which in most teams is nearly all of them. Fix the naming convention once, enforce it consistently, and the payoff isn't a single dramatic improvement - it's a small tax quietly lifted off of almost everything the team does afterward, for as long as the discipline holds.