How I keep a project file organized.

Everything About One Piece in One Place

I spent a decade watching junior designers obsess over “perfect” digital ecosystems—expensive cloud-based software suites that promised to automate their creativity into submission. They treat organization like a holy ritual, a way to cleanse the soul of any messy, human error. But after twenty years of moving between my own studio and high-volume production lines, I’ve realized that those sterile systems are often just a way to hide from the actual work. I don’t care about “optimized workflows” or the latest productivity hacks; what I care about is the trail of breadcrumbs that leads back to a decision. When people ask me how I keep a project file, they usually expect a lecture on folder hierarchies, but they aren’t prepared for the truth: my system is built around preserving the friction.

I’m not here to sell you a subscription to a new piece of software or a rigid template that will break the moment a client changes their mind. Instead, I want to show you a method born from the sawdust and the failed prototypes sitting in the corner of my shop. I’ll share how I document the near-misses—those specific, messy digital snapshots of the paths we almost took. This isn’t about being neat; it’s about ensuring that when you reach a dead end, you actually know why you turned around.

The Ghost of Decisions Past How I Keep a Project File

The Ghost of Decisions Past How I Keep a Project File

My physical studio is a graveyard of failed joinery and warped plywood, each piece a tangible reminder of a choice I didn’t make. I try to bring that same honesty to my digital workspace. Most people treat digital file naming conventions as a chore—a way to tidy up before the client sees the work. But for me, the folder structure isn’t about tidiness; it’s about preserving the friction. I don’t just want the final CAD model; I want the version from Tuesday afternoon where the leg taper looked ridiculous, tucked away in a subfolder labeled ‘The Ugly Phase.’

If I only saved the winners, I’d lose the logic of the process. I find that managing project specifications becomes much easier when you can actually see the evolution of a constraint. I keep a running log of the “why” behind every pivot, essentially creating a trail of breadcrumbs through the technical drawings. It’s not about following some rigid set of project documentation best practices to satisfy an auditor; it’s about making sure that when I look back in six months, I don’t mistake my own evolution for a mistake.

Digital File Naming Conventions Preserving the Paths Not Taken

Digital File Naming Conventions Preserving the Paths Not Taken.

I used to think a clean file name was just about being tidy, a way to satisfy some internal auditor. But after twenty years of moving between my own studio and high-volume production lines, I’ve realized that digital file naming conventions are actually about preserving a trail of breadcrumbs. If I name a file `Chair_Final_v2.dwg`, I’ve committed a crime against my future self. I’ve effectively murdered the context. Instead, I lean into a more granular, almost forensic approach to organizing technical drawings. I want to see the evolution: `2024_Oak_Stool_Joint_Detail_REJECTED_too_thin.dwg`.

It sounds obsessive, and perhaps it is. But when a client asks six months later why we didn’t go with the tapered leg, I don’t want to be digging through a mental fog of “I think we decided that was too expensive.” I want to find the specific file that holds the ghost of that decision. By treating my folder structure as a living history rather than a static archive, I’m not just managing data; I’m protecting the logic of the design process itself.

Managing Project Specifications Where the Pivot Points Live

Managing Project Specifications Where the Pivot Points Live

When it comes to managing project specifications, I’ve learned that the “truth” of a design is rarely found in the final CAD model. The real story lives in the messy delta between what the client asked for and what the material actually allowed. I treat my specification folders less like a rigid document control system and more like a forensic log. I don’t just save the final dimensions for a walnut sideboard; I keep the spec sheet where we debated the thickness of the grain, right next to the one where we almost switched to oak.

If you only archive the successes, you’re essentially lobotomizing your own creative process. I make a point of archiving project correspondence—those frantic, late-night email chains where a structural failure forced a complete pivot—because those are the moments where the design actually happens. By prioritizing this kind of project record keeping, I’m not just organizing technical drawings; I’m preserving the intellectual friction that prevents me from making the same mistake twice. It’s about documenting the struggle, not just the solution.

Document Control Systems Capturing the Nearly Abandoned Ideas

I’ve learned that a clean folder is often a dishonest one. In my studio, I treat my version of document control systems less like a strict filing cabinet and more like a forensic archive. When I’m organizing technical drawings, I don’t just keep the “Final_V2_Approved” files; I keep the versions where the joinery was too expensive or the wood grain wouldn’t hold the curve. There is a specific kind of anxiety that comes with deleting a file that felt “wrong,” but I’ve found that the most vital part of project record keeping is preserving the evidence of the struggle.

If I can’t look back and see exactly why a certain radius was abandoned, I feel like I’m designing in a vacuum. I make it a point to include a “dead-end” subfolder in every new project. It’s where I tuck away the sketches and specs that failed the reality test. It’s not about clutter; it’s about honoring the pivot points. By archiving those near-misses, I ensure that I never make the same mistake twice—or worse, that I don’t accidentally circle back to a bad idea thinking it’s a fresh revelation.

Organizing Technical Drawings the Anatomy of a Final Choice

When it comes to organizing technical drawings, I’ve learned that a clean CAD file is often a lie. If you only look at the final assembly, you’re seeing a victory lap, not the race. I make it a point to keep my folders structured so that the “final” drawing sits right next to the three iterations that failed because a joint was too weak or a chamfer was too aggressive. It isn’t just about version control; it’s about preserving the logic of the evolution. If I can’t look back and see exactly why we moved from a mortise-and-tenon to a dowel, I haven’t really documented the project—I’ve just filed a result.

Following rigid project documentation best practices can feel stifling when you’re in the flow, but it’s the only way to survive a mid-production crisis. I keep a sub-folder specifically for “rejected geometries.” When a manufacturer calls to say a radius is impossible to machine, I don’t want to hunt through my brain; I want to pull up the exact drawing that nearly made the cut. It turns my archive from a graveyard of mistakes into a living map of intent.

Archiving Project Correspondence Saving the Arguments That Won

There is a specific kind of madness that occurs in a long email thread—the kind where a manufacturer insists a joint won’t hold, or a client pushes for a finish that I know will peel in six months. Most people view these exchanges as clutter to be deleted once the contract is signed. I see them as the connective tissue of the design. When I am archiving project correspondence, I am not just saving a paper trail for legal protection; I am preserving the heat of the argument. I want to remember exactly why we fought for that specific radius or why we eventually conceded to a different grade of walnut.

If you rely solely on formal project documentation best practices, you might end up with a sterile history of what was decided, but you’ll lose the “why.” I make it a point to export the most pivotal debates into a single, searchable PDF. It keeps the reasoning intact. Without that context, a finished chair is just an object; with it, the chair becomes a series of hard-won victories over a thousand better-sounding, but ultimately inferior, ideas.

Project Record Keeping Honoring the Tension of the Process

I’ve always felt that a finished chair or a polished table is a bit of a lie. It presents itself as a singular, inevitable truth, hiding the friction that actually birthed it. This is why I treat project record keeping not as a bureaucratic chore, but as a way to honor that tension. When I look back at a completed job, I don’t just want the final CAD files; I want to see the scars of the process. I want to see the moment the joinery failed in the simulation or where the material cost forced a radical rethink of the silhouette.

If you only save the “correct” versions, you’re essentially lobotomizing the history of your own creativity. By following my own version of project documentation best practices, I ensure that the struggle remains visible. It’s about documenting the resistance—the way the wood grain fought the CNC path or how a specific upholstery tension changed the entire profile of a lounge chair. To me, the record is the only place where the design and the struggle exist in the same room.

The Value of the Near-Miss

A project file shouldn’t just be a graveyard of what worked; it needs to be a map of the wreckage. If I only save the final CAD model and the approved spec, I’ve lost the most vital part of the design—the tension of the decision that almost went the other way.

Jonathan Marin

The Weight of the Archive

Looking back through these folders, I realize that my filing system isn’t really about organization in the clinical sense; it’s about preserving the friction. By keeping the discarded technical drawings, the failed naming conventions, and those heated email threads where we nearly pivoted to a different joinery method, I am essentially building a map of my own hesitation. A project file shouldn’t just be a repository for the final, polished CAD model or the approved spec sheet. It needs to be a ledger of the near-misses—the specific, documented moments where the design almost veered into something else entirely. Without that context, a finished piece of furniture is just an object, stripped of the struggle that gave it its shape.

In the end, we tend to treat our digital archives as graveyards for dead ideas, but I’ve come to see them as something much more vital. They are the evidence of our intentionality. When I look at a shelf of rejected prototypes in my studio, or a folder of “obsolete” iterations on my drive, I don’t see failure; I see the scaffolding of a decision. Don’t just file away your successes. File away the tension, the arguments, and the paths you almost took. Because when you sit down to start the next project, it is the ghost of those abandoned choices that will ultimately teach you how to make a better one.

About Jonathan Marin

The interesting part of a finished object is the decision that nearly went the other way.