A Basic Document Storage Structure

A simple folder structure for storing project documents and support files

Last time I proposed this directory structure I was tortured, put onto a rocket and launched into the Sun (I survived, a little crispy, but alive).

Why is the folder structure I use so radical? Probably because it looks too simplistic to work. But I assure you, I have been using this structure for years now with great success (even on large projects).

Now, without further ado, here is the folder structure:



Hard to believe, but that’s all that’s really needed. The simplicity is driven by two factors; one, you can’t find anything anyway when you use a convoluted/deep directory structure, and secondly, its habits which make this approach work.

I can see some of you gesturing to the head-torturer, indicating your desire to use the iron maiden, but bare with me whilst I explain.

One question which may come to mind is do you name the top level folder after the client or do you name it after the project? The temptation, and I have seen this done, is to create a structure like this: Client Name->Project Name. For example; you would have the folder Acme, and under that you would have Blue Widgets and Hyper Widgets (nb. these would be two different projects belonging to the client called Acme).



A consistent hierarchical structure like this makes sense doesn’t it? Well, it does if you want to place the information you constantly need to access an extra click away. So which is it? Most of the time I use the client’s name. The reality is most clients will only have one project done with you, perhaps with maintenance being carried out on it in future. Flat structure is what it’s all about.

(Archive) - I have a ‘never delete’ policy. To a certain extent, it’s more about me not wanting to waste time trying to figure out if something should or should not be deleted. Back in 1993 when I had a 106 megabyte hard drive, storage capacity was an issue, it isn’t any more. The (Archive) folder is the key to making the folder structure work. Old versions of documents and support files get dumped here, this prevents the Documents and Media Dev folders from getting cluttered. As a general rule; if in doubt, back it up.

Documents - funnily enough, this is where your Word documents go. You put any kind of support documentation in here, be it PDFs, an Excel spreadsheet, or a Visio wireframe. I generally set the folder to show the most recently modified files first. You tend to work with the most recently created files the majority of the time. It’s important to move super-seeded documents into the (Archive) directory, otherwise the Documents folder can become unwieldy, especially on big projects.

Media Dev - this contains any imagery or multimedia content related to the project (e.g. logos, Photoshop files, Flash animations, videos, etc).

“Yeah, but the project has millions of documents” I hear you say. True, it does happen. But that’s what F3/Search was designed for. You are going to need to find older documents by keyword anyway. Plus there’s nothing wrong with having sub-folders if you really feel the need (e.g. Acme\Documents\User Manual).



At the end of the day, its pretty easy to decide which folder things go into, your files are either going to be a document of some sort, or a image/video. A quick note on file naming. Your company probably already has a system of some form, the only thing which I have to offer is recommending that you append a revision number on the end of documents. For example, spec_acme_rev_02.doc as opposed to just plain old spec_acme.doc. You may already have the revision number contained inside the document, but a person would have to open up the file in order to see it.