3 tricks to make your design files accessible to your colleagues
By: Lukas Oppermann
Tags: Collaboration, Design Process, Process, Design, File Management

You can adjust this convention to your needs but always consider if this convention works with the following situations:

The file might be shared and stored out of context (e.g. not in the project folder)

There might be different design aspects to the project that require individual files

There might be multiple different projects by the same client

The important takeaway is to specify the project as well as the application in the file name.

Versioning

With the naming convention figured out, we can move on to one of the most important aspects: versioning.

How often did you accidentally delete something you needed later on, had a corrupted file and lost days worth of work or, cluttered your file with variations and potential features which you wanted to keep, just in case. Versioning can solve all of those problems if done right.

Version Control System

One fairly new concept for designers is the use of a version control system (vcs). While you could have always used git (I actually did and it works quite well), it is a bit of a hassle and can feel rather daunting. Luckily services like Abstract or Folio promise to solve this with a visual representation of your file as well as integration into design tools which lets you quickly commit a saved change to the vcs. The benefit of using a vcs is that you only have one file and the vcs only stores the changes. Also, since the services are online, you get an automatic backup in case you mac dies.

Furthermore a vcs allows you to branch out, meaning you create a separate version that lives side-by-side with your original version ( master branch). You can develop an idea and if successful, merged it into the master branch. You can work on separate branches at the same time, so you might have one where you develop a new feature and another one for fixing some issues in between. Once you get the hang of this style of working it can be very handy.

Date and Name

A convention I have seen a lot, especially in agencies, is to prefix or suffix files with a date, e.g. YYYYMMDD_project_name or project_name_YYYYMMDD . This has the benefit of being sortable by day (although you can do this by using the last modified date), and you can never lose more than one day of work.

However, this approach has some annoying problems which is why I would not recommend it.

One problem is that losing a whole day of work might be quite a lot. To prevent this you than start to appending a version number again, so you have a date and sometimes a version number. If you have to hack a naming convention it is normally a red flag and means there is an issue with the convention.

Another problem arises with the opposite, you just fix a typo: If you create a new version, people are going to be confused because they cannot see the visual difference in the two versions. However if you save the file with the old name you will have a file with a date in the name, which does not align with the last modified date.

Date Labeled Pages

A slightly different, but exponentially worse version on using the date, is to label the pages or layers within the document with a date. Apart from the aforementioned problems, this approach has some additional issues:

Duplicating a page every day means your file grow extremely fast, leading to slow opening and processing times.

If your file gets corrupted or deleted, you will lose everything you ever worked on, because you only have this one file.

Using symbols and other mechanics will become unmanageable, because you need to keep the symbols of multiple iterations in this file.

Using pages as versions means you can not use pages to separate screens or sections without creating a giant mess. Congrats, you just made you file’s structure worse.

The short summary: Don’t even think about this approach, it is horrible.

Name and Continuous Number

The by far best versioning convention (apart from using a vcs) is to suffix your file with a continuous number. Personally I prefer a dot-separated number ##.# so my file name would be projectManager_mac_01.7.sketch . But you also use integers, I would just recommend to use a leading zero, so that the files are sorted properly and 20 follows 19 and not 2 . Should you regularly exceed 99 versions, use two leading zeros.

The benefit of this approach is that you can version as often or as little as you need. Sometimes you might create 8 versions in a day, or work on the same version for an entire week, when not much changes. This approach does not mess with your files structure, file size or naming convention. To create a new version, I recommend to copy the current file into a history or versions folder in your project before adding the new version number, so that you always only have the current version in your projects root folder.

Collaborating on a file

The only way for multiple people to work on the same file simultaneously, is to use a vcs. Everybody has their own branch and you merge changes into master.

However if people work on a file at different times and a vcs is not an option, the most sensible solution is to suffix the version with a short form of the persons name. Before you start working create a new version and add your suffix, this way you have no chance of ever overwriting somebody else’s work. We used this approach a lot when I worked for an infographics agency and never had any issues. With this approach, my file would be named projectManager_mac_01.7_lo.sketch .

Organising files

The most important part to make your files easy to use is of course the structure within the file itself. Over time I have developed some methods I find particularly helpful. However, depending on the project I sometimes skip some, especially on very small projects.

Styleguide

A simple style guide makes sense for every project. This guide is supposed to define the main design decisions that have been made, so that anybody who works with the file can quickly see which rules to follow.

I recommend to label the first page in your file “Styleguide” and create separate artboards to show:

Colors that may be used (excluding one-time use colors)

that may be used (excluding one-time use colors) Gradients that are used regularly

that are used regularly Typefaces and specific fonts (e.g. “Gotham HTF Bold”) as well as the most common sizes (Title, H1, H2, H3, paragraph, etc.)

and specific fonts (e.g. “Gotham HTF Bold”) as well as the most common sizes (Title, H1, H2, H3, paragraph, etc.) Sizes/Scale that should be used: I prefer to define a modular scale and use only sizes within this scale. The artboard should show all sizes.

that should be used: I prefer to define a modular scale and use only sizes within this scale. The artboard should show all sizes. Icon Style that is used. Either a defined icon set or how to create icons, if icons are hand drawn.

Wireframes

When creating an application or a complex feature, it is always a good idea to create a wireframe first and discuss them with your team, to avoid wasting effort on designing something that can’t be build or does not match project requirements.

While designing you will refer back to the wireframes frequently to make sure your design fulfills all requirements, the wireframe is like a user story for designers. I find it best to keep the wireframes in the same file. I recommend to use the second page of your file for the wireframes, as it guides people into following screens.

A wireframe in your file makes it much easier for a new designer to understand the file and what you are working on.

Designs

Now we finally get to the meat of your file, the designs.

There are a myriad of ways to structure your pages but I found the following quite pleasing and good to work with.