Having a great folder structure for your logo package makes it easy for you and your client to quickly find the right logo, but it is only the first step in creating a perfectly organized and easy to use package. Perhaps even more important is what you name each individual logo file.
It takes a lot of time to prepare a proper logo package. Sometimes I make dozens or even 100+ different logo files for a single package. Naming all of these different versions can be a big pain in the ass if you don’t have a proper naming convention, or if you use a different convention for every project. You probably also worry that with 100+ files your client won’t have the slightest clue what to do with them in the first place.
So, how do you name the logo files in your package? How do you make it as easy as possible for your client to identify the right file for their needs?
Luckily it’s pretty easy! If you read part 1 of this two part post about logo package organization, I lay out the first component of proper organization, which is a super meaningful and intuitive folder structure. Check it out part 1 you missed the post.
If you’re caught up, all you have to do is name your files using the same hierarchy as the folder structure. It’s that simple! The only extra step is to prepend the client’s name or abbreviation. It goes like this:
Let’s use the same example we used in the folder structure post to illustrate this naming convention in action. To recap, the client in the example wanted to have a vendor make them a banner stand. The vendor needed a logo with specific qualities for the banner. The logo needed to be:
- a full logo with the logo mark and logotype combined;
- full color;
- in a high resolution file format;
- for printing.
The only piece we are missing in order to name our logo file is a name for our fictional client. How about Fictional Client? Their abbreviation will be FCL.
Ok, so lets see how this plays out:
When the file naming convention mimics the folder structure that is being navigated through, it helps to reinforce the meaning and proper use of the logo. It follows the same hierarchy, so it’s less likely that your client is going to get confused about the logo’s application. It also means that if the logo file somehow ends up on it’s own outside of your original folders, we don’t need to see the folder structure to know exactly how the logo should be used.
There you have it. With a clearly organized logo package folder structure and a concise naming convention anyone who uses your logo package should be able to quickly and easily find the exact logo they need, every time.
You may have noticed that my examples use dashes between every word. Spaces are usually frowned upon when naming files because they can lead to weirdness with development. I prefer to use dashes instead of underscores because if I need to rename something, I can just double click on the word between the dashes to select it. If you use underscores, the file browser interprets the whole file name as one long word and your back to manual highlighting. That’s my two cents anyway.
Even though you know how to name your logo files, you shouldn’t have to go through and manually type out their names one by one.
What a pain in the ass. Check out Logo Package Express. It automatically names every file in your package perfectly with your client’s name and everything. Learn more.