As user experience designers, we have become increasingly relied upon to deliver the building blocks for the solutions we are designing. No longer is it acceptable to simply throw things over the fence. Professionally, we all have to work together in maximizing the efficiency of the team.
At Universal Mind, we’ve been experimenting with breaking down the wall between our design & development teams. This shift in methodology has been championed by our Lead UX Technologist, Kellen Styler. The focus on leaner, more consistent delivery of assets and design resources is proving to be a huge boost to our team productivity as well as morale. In this post I will be discussing my findings and experience in dealing with Git (with SourceTree) as a UX Designer and some advantages it brings to the table. Specifically, I will be discussing an experience which has leveraged Git, Sourcetree, and BitBucket.
Why Use Git?
Git is intended to be leveraged as a revision control system that manages changes to a set of data over time. For developers, this is usually plain text (code).
But as designers, we are working primarily with binary files (images). Binary files have some limitations in regards to tracking changes between files. While it is limited in it’s ability to show state changes between multiple commits, it is powerful due to the ability to ‘check out’ or ‘roll back’ to previous versions of your files. The designer also has the ability to make annotations and comments with each commit, which is very useful for archival purposes and project lifecycle management. Assuming a project is dormant for a long period of time, a new team of designers can start right where the other team left off with little to no on-boarding or file management. They simply download the repository and are off to the races!
As designers our lifeblood is working design files: Prototypes, Interaction Models, Photos, and an assortment of Photoshop, Fireworks, and Illustrator documents. If one of these becomes corrupted, or your local machine decides to die on you, or someone inadvertently wipes everything from that fancy cloud folder ~ what would you do without a backup? The beautiful thing about leveraging Git with your workflow is that there will always be a remote copy out there you can snag. Of course, it’s always recommended to have an adequate local backup solution. Coupling Git with your local Time Machine provides you with a veritable PRISM.
Git eliminated a veritable cornucopia of file sharing and cloud sharing services that our design teams used to get project assets and files back and forth. The designers and developers know where assets should be placed and where to find the files they need. This eliminates waste in workflows (Hey man, where is that firstname.lastname@example.org file I needed?!). There is also a higher level of transparency into the speed and progress of the team on an hourly level.
Potentially Intimidating Setup
Designer’s who have never opened their Terminal app may become intimidated with some of the installation. Creating repositories via Terminal can be a little more advanced than most people would probably feel comfortable with. Thankfully I was familiar with Git and terminal commands due to my time at SEP.
Keep Things Tidy
What Git & SourceTree do is allow you to manage your commits and pulls from the remote. You can exclude certain files from floating back to the remote (which will keep junk out of the mix and the master repository tidy).
Prolong HUGE Binary Files
Plan on pushing a 1GB .psd file to the remote repository? It will be really slow, or occasionally time out on you. Just remember that you can work locally on those big files, and push them at the very end of the project when you’re rolling off and want to archive all of your work. This also will make anyone attempting to pull the remote down to their machine happy that they don’t have to deal with a bloated repository.
It’s true. Git adds more process to your workflow, but in my opinion the benefits outweigh the time spent committing. This type of version control takes discipline and may not fit every person’s individual workflow, and some of our team less involved in day to day interactions with developers and engineers have found it tedious.
Well, what are you waiting for? Go out and get your first repository setup and get to work!
Resources for thee: