Process Documents

Asset Management

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

The folder structure in place must be carried to every single project. We must make sure everybody is able to drill-down the folders at ease.

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

🔗 Read more about naming files at Naming Conventions.
Go to Naming Conventions

Naming Folders

Folder Naming has a set of a few simple rules:Words must be capitalised
- Words must be separated with spaces
- Besides the top-level ones (✏️ Branding, 💻 Interfaces, 🎨 Art, etc...) do not use emojis
- Do not change the top-level folders emojis.

🗒 Side Note
Don't hold back on spontaneously calling a client if you reckon it suits the situation. Better make things clear with a silly call than risking left things unresolved.

Using Folders

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.

The Folders

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.

Top-level folders

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.

2nd level folders

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.

🗒 Side Note
A Deliverable isn't necessarily a piece of work that gets shared with the client. An illustration is a deliverable form the illustrator to the Designer or the Developer.

Other layers

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.

Versioning Folder

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.

Always keep the most up to date file in the root folder

Naming Conventions

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:


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:

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: