it’s not a bug, it’s a design file

From experience, changes within design files have been a nightmare, usually down to two words… “client changes”

Ever experienced.. sending e-mails, comparing word documents and using other bizarre working methods in order to document changes on finalised digital product design files?

This shouldn’t happen in the world of work; but when dealing with bespoke service agencies, companies tend to interact with clients in this way under the adage of client amends, this is often when stakeholders join the project at the final stages of the build & suddenly have an abstract way of making change requests, after finally understanding what they need as a finished piece of work due to either ignoring the original designs or even worse waiting for a functioning website or app to then make changes on.

Officially this is why designers, developers and product managers should be exclusively using version control to keep control of design files and codebases.

Anyone involved with designing or building a digital product should be using a version control system, it’s not as though we are in some exclusive club, but in order to track the changes that are happening in the timeline of the product build, this is the structured method of making and creating; and if the agency is worth it’s salt it shouldn’t accept design changes post build but should have a watertight contract to back up the creative process; protecting the budget and professionalism of both parties.

Version control in an ideal world would encapsulate design and code simultaneously on a visual timeline, with a budget counter that shows how long everything has taken, but that’s not what it is built for, even the most complicated project management tools have failed to merge (excuse the unintended pun) GIT controls into a project timeline; knowing that doing this, would create the need for project managers and other administrative staff to understand version control. Alas, version control moves in mysterious ways as U2 once said.

Having a codebase in a repo with combined design files shows the base visual designs that the product was built to, having these plus brand guidelines and assets can sometimes be risky due to leaking intellectual property, but a basic design file is usually fine.

My first sprint of rapid ideation was a joint project and admittedly we didn’t use version control, instead relying on the cloud to relay changes and a Trello board to communicate what we both needed to do in the project.

This did not work and the entire sprint highlighted the need for version control even when using cloud-based design apps such as Figma.

We had an agile methodology that was very open, with daily communication, but I feel that documenting each change in a way of being able to revert back to changes that didn’t sit right would have been a much better method of working.

This may be achieved by adding multiple offline (non-cloud-based) design files to a repo and keeping text updates via the git commit messages.

What I took from my team sprint design experience was that having offered a text prototype for the app originally, the sprint took on momentum very quickly and without smaller milestones to gauge progress; the design file progressed too fast, I feel that due to the nature of a cloud-based design file, a polished look was achieved far too quickly without having a wireframe completed.

Luckily I have set up many a GIT repository in my time as a web developer and I have been lucky enough to work on large team projects where I would take branches of code and merge them back into the master branch. But saying that I have no experience of making a repo for design so moving into sprint 2 with the new theme of cyber I have set up a repository for my design files that I shall keep offline and in a repo with a file to document changes, this future proofs the project and allows for breathing space to add more members whilst keeping the original design file intact and adding in new ones as the design file changes, having a separate wireframe and design file is the best idea thinking about it.

There are a few web safeguards that should be put in play when adding design files to the repository, one to bear in my mind is the naming conventions of files, as you shall be using the terminal to interact with the files it’s best not to have spaces in the name of the design file, so just add in underscores to avoid any complications down the line; I named my main design file ‘main_design_file.xd’ to keep with Linux/Unix naming conventions and to allow for others to do so in the terminal throughout the project lifecycle.

By adding a design file to the repo with the correct naming conventions, you allow for full use of the terminal which is the go-to for interacting with a repo, here I save the main design file to the repository folder and also add in the command $git add. The $git add command moves changes from the working directory to the Git staging area. The staging area is where you prepare a snapshot of a set of changes before committing them to the official history.

On a final note, a GIT repository need not be created in the first instance but it is very good practice to create one at the beginning of a project, as products grow an origin repo shall be team member’s go-to place, so having it from the start helps with that.