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