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

Plus, if a team member gets replaced mid-project, the transition period will be shorter because everybody can pinpoint exactly where a certain file can be found.

Besides the folder structure itself, there's another very important detail: naming files.

Don't be afraid of over-using folders. Rather having more folders than having things thrown allover the place. Make use of them to keep things neat.

Every project will have its own folder on Significa's Google Drive. Make sure there's one for your project already, otherwise, feel free to create it and share it with the remaining team.

Inside the project folder, there will be a few top-level folders, which more often than not are ✏️ Branding, 🎨 Art, and 💻 Interfaces. There might be others, depending on the project scope, but you'll get the point because it works the same for all of them.

A level below, there will always exist a Workfiles and a Deliverables folder. This two sub-folders are mandatory and must be the only couple of children of the top-level folders.

On the majority of cases, the folders inside Worfiles and Deliverables will be the same. After all, any work being done will eventually get delivered.

The number of deeper layers depends on the project characteristics. There's no point in detailing every single sub-folder because it changes from project to project.

Nevertheless, the key point is about using your judgment. Create as many folders as you find necessary. Keep in mind that other people might take over from where you left-off so make sure they'll be able to understand the structure.

Here's an example of how a folder can look like.

Version Folders exist to clear the work files folders of any unnecessary pollution. Re-working on a feature? Duplicate the latest version of the work file, change its version and move the original file the Versioning 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.

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.

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:

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 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 is the Product Name 🤯. That's it.

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

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 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.

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:

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: