GDD710 Week 7: Version Control

Image credit: Bimata Prathama

Thursday 5th November.

This week marked the start of the second rapid ideation challenge. Before I dive into the reflections, I’d like to take a moment to celebrate my Partner in this activity, Astrid. Our matched enthusiasm levels, work ethics, and learning objectives have made us an effective team. For readers outside of Falmouth University, you can find Astrid’s blog here.

I had come from the previous rapid ideation challenge with a new-found sense of confidence in my ability to attend multiple perspectives in my ideation process, and in my ability to deliver a non-linear wireframe within a two week time period. This time around, I wanted to push those learnings further.

My first new objective was to produce an artefact of higher fidelity, with more attention to UI and stylistic decisions. I think, to a certain extent, I underestimated my abilities in the last challenge. Despite losing momentum part way through the design phase, I still completed my artefact with an evening to spare.

I wanted to address that momentum loss as well. As discussed in my week 6 entry, project milestones with timescale estimations should help me stay more directed in my work.

My third and final objective was to implement a form of version control. Doing so would allow for a papertrail of my artefact’s development, and it would make collaboration a bit more streamlined.

I have created SMART goals for these learning objectives:

  1. I will produce a high-fidelity prototype for a mobile app or game, so that I can demonstrate my product design process in my portfolio. I will deliver two artefacts: one wireframe in the first week of RI2 to map the user jouney, and one high-fidelity model in the second week, with focus on stylistic and aesthetic considerations. To help me complete this goal I will collaborate with a coursemate with professional graphic design knowledge, who can guide me on the production of aesthetically pleasing assets.
  2. To ensure that my product design process maintains a steady velocity, I will outline design milestones for the wireframe and prototype, and set reasonable timescales. I will do this between completing ideation and starting design work, so that milestones can be appropriate for the project scope, and my design work will have clearly defined objectives. I will agree the milestones and timescales with my project partner and record them in a Trello board.
  3. To manage my (and my partner’s) contributions to the project, I will implement a form of version control. The version control system (VCS) will be agreed upon before any ideation takes place, and any required setup will be completed before the first ideation session.

Sunday 8th November.

Following a similar approach to the last RI challenge, I separated the project into phases. This time, I had three phases; ideation, wireframing, and polished design.

Rather than invest time into multiple ideation methods as I did in RI1, we opted to use the method that I had found most valuable; opposite thinking (Board of Innovation). Accounting for our seven-hour time difference, we scheduled a two-hour call to complete the ideation process and write up a brief product specification for the artefact.

I’ve mentioned in my previous posts that I champion the opposite thinking strategy for its ability to force me into attending other perspectives. Collaborating with another designer inherently brought an even wider variety of perspectives to the table, and the three-step process gave us a means of exploring them methodically.

We each contributed four starting (assumption) statements and one opposite statement for every assumption. This brought us to a total of 16 opposite statements, giving plenty of ground for the generation of solution statements (app or game ideas). Considering the two-hour window we had available, we felt it important to constrain the exercise to a timebox of a 90 minutes, leaving 30 minutes for the specification write-up.

Here’s where I found the activity to be particularly valuable. Timeboxing ideation and product specification simulated the work that I might engage in as a creative professional. It also helped to keep the activity directed and deliberate.

I could now confidently lead a productive and constrained ideation workshop in a professional environment. If I can continue to set objectives with time limits, I expect that I’ll have met my second SMART goal by the end of RI2.

Tuesday 10th November.

Astrid and I have found version control to be a point of deliberation in this project.

For a short while at the beginning of our collaboration, we considered using Github for version control. However, because design files (as in Adobe XD) are binary blobs, no useful diff would be derivable from the changes between commits, and merging branches would be a manual process of piecing changes together into a new ‘master’ file.

In essence, Github would only serve as cloud storage for our iterations. If we had more time, we may have been able to find a plugin that connected Github and a prototyping tool to visualise design changes between commits. Given the limited scope of RI2, we felt the most appropriate solution was to use Miro whilst wireframing, so we could collaborate in real-time. When we move into the hi-fidelity design phase, we will store our XD files in a shared Dropbox folder or Google drive. Taking inspiration from University of Virginia Library, we’ll use a simple and consistent nomenclature to denote when iteration was created, and who produced it.

By nature of us living seven timezones apart, our study hours have had little overlap. Entering the project, I thought this might have been challenging to work around. Surprisingly, we have found that our opposing waking hours have allowed for an effective successional work structure. At the end of each evening, I leave a message for Astrid as a quick handover, so that she can pick up where I left off. Mutual respect for each other’s time and being proactive in communation is pivotal in our collaboration.

Following Guidance from a hubspot article on working with teams in different timezones, we’re particularly attentive to communication around timescales (Pamela Bump, 2020). We made it clear to one another when we would be working and would be available to discuss the project. We would specify a timezone whenever we mentioned a time, avoiding miscommunication. Likewise, any milestones we set were recorded in a joint trello board, with specific dates, helping us to effectively organise our shares of the work.


Board of Innovation. ‘Opposite Thinking’. Available at: [accessed 22/12/2020].

BUMP, P. 2020. ‘9 Tips for Working With Teams in Different Timezones’. HubSpot. Available at: [accessed 22/12/2020].

University of Virginia Library. ‘Organizing Files: File Naming and Version Control’. Available at: [accessed 22/12/2020].

Published by Josh 'Skoob' Brough

Experience enthusiast. UX/UI designer. Father to (little) one. Currently studying MA User Experience Design at Falmouth University. Here’s the chronicle.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: