3 tricks to make your design files accessible to your colleagues
As designers we often start a new design file without any thought and let it grow however it will. This can lead to problems for others who have to work with our file, but we can help this with a some simple methods.
In this article I explore the three most important aspects fo making your design files easy and enjoyable to work with: naming, versioning and organisation.
Although I focus on sketch files, most of the ideas are applicable for any type of design file. However some ideas might not work as well if your tool does not support pages.
Naming
Finding a good name for your file is crucial to communicate it’s content. However, if you stick to a simple naming convention you should have no trouble with this.
What worked well for me is combining the project name and the platform / application, which give you an easy to understand name. Starting with the project is helpful because it lets you sort your files by project. This also means you will separate each application into an individual file which is always a good idea.
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)
- Gradients 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.)
- 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.
- 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.
User flow
I have found it most useful to separate my designs into sections, mostly feature related, and give every feature a unique number. For example, my first page after the wireframe page could be 01 Onboarding.
On this page I have an artboard showing the user flow for the given feature. I use a standardised, simplified wireframe like style to show how the user moves through the screens in this section. I recommend creating a library with elements to quickly create user flows. The benefit of having this in the beginning of every section is that one can quickly grasp what this feature is about and how the screens behave. This is very helpful when explaining something to a stakeholder, but also for a developer working with your files.
Every screen in the user flow gets a unique number. The login screen in our example would maybe be 01.2.0 because it is part of 01 Onboarding and within this it is the second part (part one being the intro slides) and the first screen of this part.
The wrong user or password error page could be 01.2.1 and so on. This makes it much easier to reference screens when talking about them via Skype or in tickets.
Screen Designs
Below the user flow page, there should be a subpage for every feature of the section with the actual designs. While you cannot create real subpages in tools like Sketch, you can visually do so by prefixing the page name with the ↳ character.
◆ Styleguide
◆ Wireframes
01 Onboarding
↳ Intro
↳ Login & Register
I find this visually much more organised than showing the actual screen numbers and on some subpages, like Login & Register, you might have multiple sub-features with different numbers.
Layers
One level deeper, inside your pages and artboards, there is another important aspect of organisation: your layers. You should make sure to always keep your layers clean and name them sensibly.
Clean Up Your Layers
To keep your file clean, make sure to remove all empty as well as unnecessary layers. While it is fine to have multiple images in a group to test out which one works best, once the best one is found all others should be deleted. The same holds true for any other element. You shouldn’t have hidden layers in your file when you save it.
Additionally it makes sense to combine paths whenever possible, group layers that belong together and sort layers by their vertical appearance in the design. This makes it just so much easier to find what you are looking for in the layer panel.
Naming Layers
Picking sensible names for your layers is equally important. Automatically created names like Rectangle 10 or Oval Copy are just not very helpful. If you compose a visual element, like a button, from multiple layers, you should group them and name the group.
Finding names for your layers is pretty easy, just make sure you use one language (preferably the language everybody in your team speaks) and name the layers for their function. This means a profile picture layer is named profile picture and not Mary (even though your screen might shows your persona called Mary).
A nice touch is to add emoticons to your layers, to easily identify important layers, e.g. 🌄 profile picture. You can easily bring up the emojicon picker by pressing ctrl + cmd + space. Don't overdo it though.
Symbols
One extremely effective instrument for organising your file are symbols in sketch (some other tools have similar mechanics).
Whenever you have a reusable object or complex object it makes sense to create a symbol from it. For example if you create a symbol for a list item, you can later update the text color and it will change for all instances of the symbol.
Symbols are reusable components that share a common design, but can have some flexible parts.
Sometimes you might want to have some flexibility to it, for example you might want some list items to have an arrow on the right and others not. To make this possible, you need to nest a symbol of the arrow into the symbol of the list item. Now whenever you place the list item symbol in your file you will see a dropdown on the right sidebar in sketch and you can select none to hide the arrow.
You can also edit images and text in this sidebar. However, sometimes an image or text should not be changed. To hide any item from the sidebar, simply lock it in the symbol.
One very important part of creating good symbols is naming the layers correctly. There are two reasons for this.
Firstly when you have two different button symbols and they both have a text layer named label, you can switch the symbols via the dropdown and the overwrite text will be kept.
Secondly the names of your layers are used for the labels in the sidebar. This is especially important when nesting symbols.
I like to use a visual clue to denote symbols as children, e.g. ↳ label. When nesting complex symbols into a symbol I rename then e.g. ◆ list item so you have a visual indicator where a new item starts.
Libraries
Libraries are a convenient way in many design tools to share symbols across multiple files or projects. However, it does make the whole editing flow more complicated, so I would recommend to use libraries with care. The following use cases definitely suggest themselves for libraries:
- Wireframes, which can have the same visual aesthetic in every project.
- User flows similarly to wireframes can use the same visual language across different projects.
- Icons can be shared when they are neutral or shared across a companies projects.
- Design systems, which are of course the prime example for libraries. If you work on a product which exists on different platforms extracting shared elements like buttons into a library can be very helpful.
While this article probably doesn’t cover all aspects, I have been working with the outlined ideas over the last years and had very good experiences, so try it out and let me know your thoughts.
