Managing design files seems to be the bane of every designer’s existence. The image below has been floating around the internet for a while, and it never fails to make me chuckle when I happen upon it.
Every designer I’ve ever met, myself included, has had some crazy method of naming files and storing file versions. And trust me, it is not pretty. When a designer is working in isolation, it’s usually not a problem. The “real final” is usually delivered to the client as a different file type, and it’s easy enough to drop the accompanying RAW file into the same folder. Never mind the absolutely desolate wasteland that constitutes the rest of that designer’s hard drive, or God forbid, desktop.
Our design team has grown a lot in 2016, from just me; to me and Liz, a Copywriter/Designer; and now, the two of us plus a new Designer. As a team, we’ve had to figure out how to save, send, version, and control files—files that several people need to access, change, and update on a weekly, and sometimes daily, basis. To no one’s surprise, this posed quite a challenge.
My first exposure to file versioning was through development best practices. In short, developers use a system called Git to control and manage their file versions, especially when working across a team of developers with varying levels of experience and skill. Git allows developers to make “copies” of files to a local computer when they’re resolving an issue or fixing a bug. Using the local copy, they can experiment with solutions or, perhaps more accurately, break everything and put it back together, without endangering any live files. Our developers here at Gauge use a popular online tool called GitHub for this purpose.
While controlling file versions is a common problem for both designers and developers, the design industry offers very few solutions. I recently heard about a design team in Toronto using a service called Folio for Mac, which uses GitLab, a competitor of GitHub, to manage files. Folio allows designers to have a central repository for their files. Then everyone on the design team can download, edit, and upload changes as they’re needed.
We considered using Folio, but it posed a few challenges to our team. It’s a paid service, and the cost isn’t feasible for us as a small team.Furthermore, we need to be able to share the files across both our design team and our development team. Buying, installing, and onboarding about 12 people onto Folio wasn’t really something we wanted to do.
With the suggestion of one of our developers, we gave GitHub a shot. The only thing I can say is, I wish we had done it sooner. Here’s how it works for us.
Set Up
- Our company already has an organization on GitHub, so we made a second organization called Gauge-Design. Right now we don’t need to make it private, but we may eventually.
- We set up a repository for each of our clients, using a camel case naming convention. So the repo for Big Data Corp would be titled as BigDataCorp. We were also able to use InVision sync folders as premade directories for repos; when we publish a change to InVision, we can automatically create a commit at the same time. This does create one issue, which I’ll get to at the end of this post.
- After we set up the necessary repos, our team downloaded the GitHub Desktop App for Mac, and then created individual GitHub accounts. The accounts were added to our Gauge-Design team. Once we did this, our team was able to go in and clone whichever repos they need locally, and save the folders wherever they wish. We suggested using a GitHub top level folder immediately underneath their User account for ease of access and consistency.
Using GitHub
Setting it up was the easy part; using GitHub, and using it consistently, has proven to be the challenge. This diagram illustrates how we have our repos set up.
In a traditional development workflow, Git may be set up to use branches for various features, staging environments, and live sites. While this works great for development teams, our design projects often have numerous moving parts that can’t be tracked quite as easily.
For this example, I’ve set up a master with three branches. We use the master for hosting only “master approved files;” files that have either been approved by the client or have been published in some way. That hosts the files we copy to our computers, so we need to make sure those are 100% accurate with no discrepancies. Then we set up secondary branches for each individual project or campaign. This helps us keep track of which projects we’re making changes to and how much editing is being done to those files.
For shorter projects, which may only last a week or two, the branch is a fairly impermanent way to set up a shared workspace for those files. Once it’s done, everything gets merged back into the Master and away we go. Other longer projects, with ongoing aspects like blog posts or social media images, have more permanent branches. The branch concept works really well for the way our workflow is set up.
The Issues
Of course any new system or workflow adjustment is bound to have faults. This is no exception. We’ve noticed two hang-ups that, if we were able to solve, would make GitHub the perfect file sharing tool.
- GitHub is not and should not be treated like a large storage server, ala Google Drive. We tried to create a repo for our shared asset library, but after trying to sync a stock photo folder (about 18 GBs worth of photos), we decided to use our company Google Drive folder instead. Each repo has a max size of around 1 GB, which means we’ll likely need to archive work fairly often to keep space open. The storage limits make the process a bit more high-maintenance than we’d like.
- While using InVision sync folders as root directories for repos is awesome, again the file sizes begin to bite us in the butt. InVision also has max file sizes, and large projects can slow down sync times considerably. We work around this by creating two client folders for each client who has actual InVision work. While a pain, it does streamline workflow for various parts of the team, and works to minimize overall folder size and bandwidth for faster syncing.
Wrapping Up
While GitHub has its faults and potential hangups, I must say that having a standardized way to manage, share, and version our design files has given me great peace of mind surrounding our design process. At the end of the day, our design process exists to serve our clients and their customers. We can’t do that effectively if our files are all over the place. We can’t effectively manage workflow amongst several designers if we can’t accurately track changes and the reasons behind those changes. And most importantly, we can’t make well informed, judicial decisions in our work if our storage is sloppy or the files are unavailable when we need them most. I’m confident that this is just one step on the journey to help us serve our clients more effectively.
