Handbook

Naming Conventions

Working with a multi-disciplinary team across projects requires organization in every detail. Each team member gives their own contribution to a tidy project folder.

Keeping folders neat, with a consistent structure and correctly named files, will speed-up hand-offs and work interchange between team members.

On top of that, if a team member gets replaced mid-project, the transition period will be shorter because everybody can pinpoint exactly where a certain file is.

"🔗Read more about organising folders at Folder Structure.Go to Folder Structure

Why keep naming consistent

Keeping names consistent throughout all files and work files' layers is paramount.

First and foremost, if all names are consistently given, it will become much easier to find files wherever they are. Together with a correct folder structure, finding files becomes a breeze.

Also, did you ever sent a file via Slack or email and then tried to find it back again? Demoralizing pain, we must say. That's because you can't remember the darn name.

Second, for versioning sake. Versioning design files has been a pain ever since William Addison Dwiggins designed his first book back in 1922. Back in the day, we bet his ultimate work file was named Book-Final-Final-Final-v154-Final-SuperFinal.ironpressYou've been here, didn't you?. To avoid this sort of shenanigans, naming conventions were invented.

Third, inevitably someone else will end up working on your file. If it is not for your sanity, at least for their's, keep things named properly.

Don't be this guy:

Fourth, and last, naming files randomly and share it with clients is a big fat NO-EFFIN-WAY! It demonstrates a lack of professionalism and pride for your work that doesn't suit our culture.

Naming files

By files, it means every file, from working documents to exports and deliverables. Everything must be named consistently and it must follow the same pattern.

Every file must be named according to the following sequence:

[Order].[ProductName]-[PlatformName]-[FeatureName]—[Version]

We'll break down each element for you but before doing so, just some quick notes:

  • File names must not contain spaces;
  • Everything must be PascalCase;
  • Each element must be separated with a single hyphen;
  • Order must be followed by a dot;
  • Version number must be preceded by double hyphens;

Order

Order is not mandatory. It simply suits the purpose of keeping files within a certain order which might make sense given the project structure.

Use it in case it makes sense always followed but a dot (.), no space before nor after.

ProductName

ProductName is the Product Name 🤯. That's it.

Keep it PascalCase at all times without any spaces before, in the middle nor after.

PlatformName

PlatformName is the sub-set of the Product you're working on. It can be a MarketingWebsite, a UserApp, a WebApp, etc...

Once again, keep it PascalCase without any space before, in the middle nor after.

FeatureName

FeatureName is not mandatory because it might not be relevant at smaller project.

On bigger project though, where work files might be broken down by features, it will be important to name those files accordingly.

Version

Just be careful to keep it sequential and separated by two hyphens instead of the usual single hyphen. Version should be written in the following form:

v[number]. Keep it together.

Naming layers

Naming layers don't necessarily follow a strict set of rules. Especially when dealing with Sketch, it can get trickier with symbols. With that in mind, as long as elements are named in a semantically correct fashion, we're cool with it. As long as if someone is able to open a work file and figure out which element is which, it works.

However, just keep in mind assets will be exported from your file, most likely. Therefore it might make sense to name those assets based on the file naming structure.

Nevertheless, here's a good example of well named layers and a good Sketch file organisation: