Designers who Git. It’s worth it!
My experience with incorporating GIT in my design workflow
In todays tech world, developers can’t imagine writing even one line of code without using Git. And that’s because it gives control and provides all the features needed to accommodate hundreds of possible workflows. With Git you can maintain multiple versions of a file, conduct multiple experiments and yet preserve a clean “latest” version of your work. It lets you roll back your changes when needed, and you can even rewrite past files when you need to.
As a Designer, I come from a core UX background and although I had some coding experience during my University years if someone told me that I would write a post about how git can help designers collaborate better with developers I would probably laugh. But things change, our work environment changes and so our workflows should change. I guess.
The story
So let me tell you my case on how I got to open the terminal and git pushed Sketch files for my fellow developers.
From the very early days of my career as a Digital Product Designer I was part of full-stack teams including back-end developers, front-end developers and designers. It was a time where the “Should designers learn how to code” philosophical question was at its peak!
A small side note in that matter: I would say yes they should to some extend but it’s purely subjective and has to do with the vision that a person has for his/her career and where do they see themselves in 5 years ahead. I for example, wanted to be more involved with the front end team and be able to communicate better with the developers, understand their pains and have a clearer understanding of the limits and constrains of the medium that I am designing for. That’s why I invested some time and became familiar with front end frameworks such as BEM and less/sass CSS languages.
Anyway! Back to our story! So one day, while having a casual chat with some developer friends in a coffee break at work, at some point the conversation turned to work related stuff and out of the blue one stops and says to me: “Designers should learn git as well! It’s way easier for us to get the files from a repo rather than from Google drive or Dropbox and open them in Zeplin”. And there it hit me! With a little help from my developer friends (props to Dimos and Thanasis for their patience with me) we set up a repository in Bitbucket along with some git 101 lessons and there you go! My first commit and push! :)
After my first commit, we agreed to change our design handoff process in order to test if the GIT workflow could work. I can’t say it was easy since every time I looked at the blackness of the terminal that waits for someone to command it, makes me cmd+Q it!
Lessons learned so far
Sketch + Git = ❤
After doing this, I saw the developers more engaged with the designs and more willing to git pull them than before. Also I noticed that they were excited about teaching a team member a new skill that is entirely out of his knowledge and comfort zone in oder to smoothen a part of the process which amplified the team spirit.
Although GIT is a system for version control and it’s made primarily for the core part of a developer’s workflow, it can work well with both code (text) and UI assets (resource files) such as .sketch or .psd files. Sure, Git is built primarily for pushing/committing 100KB .php files and uploading a big .psd or .sketch file may some times take forever. You can avoid a painfully long upload by integrating Git Large File Storage. So there you go, problem sovled! :)
Structure and commits
You have to come up with a structure in order to make it easy for your fellow developers to find your files easy. When you are designing variations of a page or whatever make a branch in order to divide the path. This will create a branch which is an independent path of revisions and changes.
When committing, write a title and a description with the changes you made. Never commit without that, unless you want your fellow developers throwing all kinds of things at you! Just kidding, but you should have at least a title! It’s quite a standard as they told me, so now you know!
How come it’s not common?
I believe there are three main answers to this question.
1 - which I consider to be a misconception, is that git is too “complex” for designers. Sure, git is not a trivial tool to get used to. Junior developers also need a bit of practice before getting familiar with it. But understanding the core functionality of git does not require a degree in computer science nor years of programming experience. You just need a developer friend to show you some tricks and invest some time to study and practice.
2 - which I think is the case, is that the Design community has not yet gotten into the habit and the culture of using git. It took years for developers to make git a standard. In the same way, the Design community needs to demystify git and this will take some time.
3- which as we move forward wont be relevant any more, is that git is primarily designed for code, i.e. text files, rather than designs, i.e. sketch files and psd’s. There is some truth in that, but here is a great tool tackling that issue called Abstract and here is a great post about it! :)
Conclusion
I believe that the ways designers and developers work together have undergone a lot of changes and are still evolving each year. By building more bridges for collaboration and communication we can have an impact on how those two fields can work together.
I hope more designers will try to explore Git and incorporate it into their process. I am not saying that it will solve all their problems. Maybe for some teams there are no problems at all in their workflow! But who knows, we might even discover new ways on how to think about the team workflow.
One thing is certain though, that we are just beginning to solidify our steps in the software development mix and if we don’t try new ways to approach anything from a design solution to a workflow we can’t know if they work!
