How we organize project files so the team can find anything in seconds (and onboarding takes minutes, not days)

The cost of bad file management

Bad file management is invisible until it isn't. The things that go wrong are all common enough that most teams have experienced at least one:

The designer sent the wrong version of the homepage to the client, because the file naming didn't distinguish V2 from V4. The developer can't find the original source file for an icon that needs editing, because the asset was saved to someone's personal desktop and nobody else has it. A new teammate spent their first week asking "where's this?" in every channel, because the folder structure didn't make sense without a tour guide. Someone rebuilt work that already existed because they couldn't find it and gave up looking.

Each of these costs time, sometimes client trust, occasionally money. Individually they look like small operational glitches. Collectively they're the largest source of quiet friction on a lot of teams.

The fix isn't complicated, but it does have to be deliberate. File management is infrastructure. When it's done well, nobody thinks about it. When it's done badly, everyone loses time every day.

This article covers the three-layer system we use at SUFFIX and the specific folder structure, naming convention, and permission defaults that make it work.

The three-layer system

Layer 1: Storage (where files live)

The first rule: one source of truth. Every file the team needs has one canonical location. Not duplicated to personal desktops, not forked across three different cloud providers, not living in email attachments.

At SUFFIX, that source of truth is Google Drive. Every team member can access it from any device, whether they're at the office or working remotely. Files get shared by link, not by attachment. When the file updates, the link still points to the current version. Nobody ends up with an outdated local copy of something that matters.

Google Drive isn't the only valid choice. OneDrive and SharePoint work well for teams in the Microsoft 365 ecosystem. Dropbox Business works for teams that prefer that interface. The choice matters less than the commitment: pick one, use it consistently, and don't let files leak to personal drives.

The failure mode to watch: "I saved a quick copy on my desktop to work faster." That copy is now a time bomb. Either it becomes the canonical version without anyone announcing it, or it diverges from the real file in ways that cause confusion later. Work on the file where it lives, not in a local copy.

Layer 2: Organization (folder structure and naming)

Once files live in one place, the question becomes: how do you find them fast?

We organize files top-down by client or brand, then by project, then by work type.

Top-level folders: one per client or brand. Everything related to that client lives underneath.

Project-level folders: within each client folder, one folder per project or engagement. Enough so that projects don't bleed into each other, but not so many that the hierarchy becomes navigation overhead.

Work-type folders: within each project, a consistent set of subfolders. The structure we use:
- Artwork: Finished, production-ready design assets. What ships to the client or gets implemented.
- Preview: Files used to present to clients for review. Can be work-in-progress.
- Source: Original, editable source files. The working files designers and developers edit from.
- Document: Supporting project documentation (briefs, meeting summaries, scope docs, planning).
- Presentation: Slide decks and meeting materials.

This structure reflects the real workflow of a digital project, from brief through handoff. Anyone on the team can open a client-project folder and immediately know where to look for what they need.

Naming convention

Consistent naming is where most file systems fall apart. Our rule: ProjectName - WorkType - mm/dd/yy

Examples:
- ProjectName - Meeting Summary - 10/01/26
- ProjectName - Plan Presentation - 11/02/26
- ProjectName - Website Design-Home-Desktop HD - 12/03/26
- ProjectName - Wireframe - 01/04/27

Three parts: what project, what kind of work, and when it was last updated. No more, no less.

We use mm/dd/yy because most of our projects run on monthly cycles, so the month is the most useful primary sort dimension when files live together in a folder. Teams working on longer engagements might prefer yyyy-mm-dd for cleaner chronological sorting. The specific date format matters less than consistency: the whole team uses the same format.

This convention has a side benefit that compounds over time. A consistent naming pattern means the team doesn't have to open files to figure out what they are. It also means new teammates and freelancers can understand the project structure at a glance, without asking. That reduces onboarding time from days to hours and reduces the risk of opening the wrong version.

Layer 3: Access (permissions)

Storage and organization solve findability. Access controls solve security and collaboration boundaries.

Every shared platform has the same three-tier model: View, Comment, Edit.
- View: The recipient can open the file but not change anything or add comments. Best for reference documents and final deliverables where you don't want feedback inside the file itself.
- Commen: The recipient can add comments without changing the file. Best for work in review where you want specific, threaded feedback without risking accidental edits.
- Edit: The recipient can modify the file directly. Best for work the team is genuinely collaborating on.

The defaults we use at SUFFIX:
- Internal team → Edit on source files they're actively working on, View or Comment on final deliverables and files owned by other teammates.
- Clients → View on deliverables, Comment on items currently up for review. Never Edit on source files, even when they ask.
- Freelancers and contractors → Edit on folders for their active projects only. No access to anything outside their engagement scope.
- Archived projects → View only for everyone, to prevent accidental edits to historical work.

The principle: default to the least access that lets the person do their job. Upgrade when needed. It's easier to grant edit access later than to undo damage from accidentally edited source files.

Confidential documents

Some files need stricter handling than the default permissions provide. Contracts, pricing documents, unreleased product information, pre-launch marketing assets, and anything covered by NDA.

Our rule for confidential files:
- Stored in a restricted folder with a clearly labeled name (e.g. Confidential - [Project Name]).
- Access limited to the specific people who need it, not the general team folder permission.
- Explicit sharing rather than inherited permissions from parent folders.
- Regular audits of who has access, especially after team changes.

The cost of over-restricting is mild (a couple of "can you give me access?" requests). The cost of under-restricting confidential information is large (contract breaches, leaks, reputation damage). Err on the restrictive side.

The file lifecycle

Files go through stages, and the management system needs rules for each transition.

- Active: Files on projects the team is currently working on. Full access for the project team. Fast findability is the priority.
- Completed: Files from projects that have shipped. Still accessible for reference and future work, but moved out of the active namespace so the active folder doesn't bloat. Move these to an Archive subfolder or a dedicated Archive drive.
- Archived: Files from projects that closed months or years ago. Accessible on request but not cluttering active searches. Usually View-only for the team, with Edit restricted to a small group.
- Deleted: Files with no ongoing value: duplicates, outdated drafts that don't inform anything, content that's been superseded. Periodic cleanups remove these to keep storage costs sane and reduce noise.

Define the rules for each transition upfront. Without rules, everything stays "active" forever, and the active folder becomes a graveyard that slows everyone down.

Common failure modes

Recognizing these patterns is half the battle:

- Files on personal desktops: Nothing critical should live somewhere only one person can access. If it's important enough to keep, it belongs on the shared drive.
- Inconsistent naming: Some files named clearly, some named "Untitled Copy 3," some named "final-FINAL-v2." Search stops working. Team members can't guess where things are.
- Shared drives with no structure: 800 files dumped at the root. Technically accessible. Practically unfindable.
- Over-permissive sharing: Client has edit access to source files, interns can modify shipped deliverables, freelancers can see unrelated client folders. A permissions review catches this.
- Under-permissive sharing: Nobody can access anything without pinging the owner. The owner becomes a bottleneck for work they're not even doing.
- Never archiving: Active folders accumulate five years of completed projects. Search gets slower. Navigation gets harder. Storage costs climb.
- Never cleaning up: Duplicate files, outdated drafts, and abandoned test folders pile up. Everyone's time spent scrolling past irrelevant content compounds.

Most of these are solvable with a 30-minute audit and a standing cleanup rhythm.

The onboarding test

A useful measure of whether a file system is actually working: can a new teammate find what they need without asking?

Give a new hire or freelancer the drive URL, no tour, and ask them to locate three specific files in their first day: a client brief, a source design file, and a meeting summary from last month. If they can find all three in under 15 minutes, the system works. If they can't, the system is failing.

This test reveals issues that the existing team has worked around: implicit knowledge about where things live, undocumented exceptions, folders named in ways that make sense only to the original creator. Those gaps cost the new person time and cost the team's senior members time when they have to explain.

Running this test when you hire someone new, and updating the structure based on what they struggled with, keeps the system honest.

The compounding benefit

File management isn't glamorous work. It doesn't feel strategic. But the compounding effect over months is substantial.

A well-organized file system reduces the friction on every piece of work the team does. Handoffs get cleaner because the receiving party can find context without hunting. Onboarding accelerates because institutional knowledge is encoded in structure, not in senior heads. Client communication gets sharper because you're sending the right version every time. And the team spends less mental bandwidth on operational overhead, which means more on the work that actually matters.

The three-layer system above is specific enough to copy and flexible enough to adapt. Start with the folder structure and naming convention, add the permission defaults, commit to the cleanup rhythm, and the rest compounds from there.