Files come and go as we hash out a product. Today's wireframe is tomorrow's archive fodder, and last month's PSDs are nostalgia at best. Trouble is, when dealing with hundreds of files across dozens of clients, keeping track of which file is which is a job in itself. You know the situation — when you need that one you were working  on yesterday, where'd it go?! I swear it was on my desktop!

In creating Foundation for Apps (zurb.com/blog — Brandon's recent post), our upcoming framework that focuses on helping designers make app-like experiences, we've had to rethink how we name things. The range between semantic, generic, useful and intuitive is narrow. We also began to wonder about our process for naming files in general. After all, finding our source files is as important as a product's code and images.

Naming conventions are critical for smooth workflows. Spending time finding your own files — let alone someone else's — is a costly time-waster. Standards help people work together, and make it easy easy to find what you need weeks or months after you create (and forget, but suddenly need) them. In this lesson we'll explore what's in a name.

What makes a bad filename

To understand what's helpful, we also have to look at what's teeth-gnashingly awful. A bad name:

1. Doesn't give any hint as to what its file is about.
2. Is indistinguishable from other files.

For example:

• DSC12345.jpg — From a camera, apparently.
• cat.gif — Do you have any idea how vague that is?
• index.html — Necessary, yes, but that could apply to anything.

Good names follow a few guidelines

The rules we follow are simple. Good names are:

1. Indicative — They describe their contents, even if the contents change.
2. Searchable — You can find them with the search tools at your disposal.
3. Scannable — You can pick out the right files at a glance.
4. Unobtrusive — You can easily apply them to your workflow.
5. Understandable — You don't have to guess what they mean.

Here's a framework to develop your own file naming system.

1. Use a "segment" system.

Segments are keywords that put files into a larger context. Each filename uses two, maybe three, parts such as:

• A client name
• A project name
• The project's phase
• A date

For example:

• Acme - catalog redesign - spec.doc
• Acme - catalog redesign - order form.graffle
• Acme - catalog redesign - order form.psd

Dates for all occasions

Why name files with dates when they already have created/modified metadata? A "date" may also refer to its

• Catalog redesign - spec - Autumn 2014.doc

Order top-down

Segments' order is important. Think top-down — from client to project to phase. For example, one client may have many projects, but it's a rare project that has many clients as time goes on.

• Clientname - projectname.ext
• Projectname - phasename.ext

The beauty of this system lies in its interoperability — a fancy way of saying you can keep reusing the same parts.

• Acme - redesign 2014 - mockup1.html
• Acme - redesign 2014 - interface.ai
• Redesign 2014 - mood board.psd
• Redesign 2014 - specs — catapults.html
• Acme - specs — anvils.html

2. Use folders wisely.

Folders (directories, what have you) are terrific natural segments. In fact, folders can take the place of top-level segments. For example, if these files were in a folder called "Acme," then they don't need to say so.

• Catalog redesign - spec.doc
• Catalog redesign - order form.graffle
• Catalog redesign - order form.psd

3. Whatever you do, do it daily.

The more you use your system, the more useful you and other people will find it to be. You'll also invent shortcuts, favorite keywords, and other tricks as you go. Each new file is an iteration in your naming system.

In Foundation

We often use similar processes when building sites with Foundation. The "stylesheets" folder, for example, is standard issue in part because Sass creates "stylesheets" for us — but also because everyone at ZURB expects it. We count on standard names in our products so that everyone's web files can assume their links are correct without thinking. (Of course, we test frequently).

Try it now

1. Pick a project file on your computer. Any file.
2. Prefix it a keyword based on the project.
3. Then find five other files in the same project that are not in the same folder.
4. Put the keyword in those files' names.
5. Search your computer for that keyword, and suddenly you have a list of project files.

---