This blog post does not follow a specific reflective style as there are no interventions that I feel require a full on reflection. Instead it is a reflective approach to the notable events of the week. You can find the first reflection on RI2 here.
We decided on our discord to have a blog feedback group and I was paired up with Katerina. We were originally paired up in week 6 but with the end of rapid ideation we only had time for our first feedback session during Week 7.
I am grateful to my peers for being so invested in wanting to help each other and it was a great way to get a bit of feedback. Katerina and I read each other’s blogs and prepared some feedback which we decided to share over a short video call so that it could be a more informal chat.
Katerina told me that research side of my self directed study was coming through strongly which was a relief and encouraged me to tidy up my referencing and focus on creating more obvious links between my thoughts and resulting conclusions or actions. It was very helpful to get this insight and I will definitely keep this in mind going forwards, paying special attention to how I communicate my decisions as illuminating the process is one of the core functions of this CRJ.
It has been a recurring theme of this middle portion of the module that I am coming up against some time management troubles. I am frustrated that I am not completing the writing within the weeks of the activities I am writing about, however I have been diligent with taking notes and capturing the most important information in the moment so that the rewrite is more a question of incorporating structure and sense into the blogposts than anything else.
Regardless, this is still work which I am currently focusing on getting better at managing. To do this I have started including CRJ checkpoints throughout projects as I find that the once a week reminder via the course isn’t usually enough for me to cover everything I have reflected over the week and I would like to compartmentalise my posts as much as possible.
Week 7 looked at version control which is a way of managing and tracking changes within a project. With it you can test new code, fix any issues and merge it back with the master code without anything breaking and with all the steps of the branching, debugging and merging being visible. It started out as a practice in engineering teams but has since spread out to other parts of the product lifecycle (UXPin 2022).
The learning content for the week seemed to be a bit lopsided towards the Game Development side of the cohort as it focused on Github which is a system that does not lend itself very well to Figma or UX practice. It is very code development based which is not a skillset necessarily required of UX practitioners.
That being said, version control in general is useful. I know from personal experience that you need to be able to test ideas without breaking the original file as well as whenever possible engage in non-destructive editing so that you can regain your original information whenever necessary. You never know what the client you are working for will want from you or if they will want to take an idea a few steps backwards. Without ever being very aware of it, on my local computer I created a versioning system of my design files so that I could always go back and find previous ideas or development.
The industry is also responding to the demand and more and more versioning systems for UX design are starting to pop up. Design+Code have created a short list of a few solutions that can be found here.
In my practice I am focusing on Figma and I have found out that it has the ability to name and save a “moment” in your design that you can then scroll back to whenever you want in their version history feature (Figma 2023). Figma is already at its core a collaborative tool so the ability to go into a file and scroll back in it’s history to study how the development evolved is huge and can save a lot of complexity when you get asked to backtrack in your decisions (Lawrence 2022).
Versioning can also mean having different version of the same product for all the different members in a team. For instance having one version for the engineers that has only a few updates from the previous iteration so that they can work steadily towards the end product without getting alarmed at the amount of changes, one future facing version for the higher ups so that they can visualise what it will look like at the end, one version for user testing that focuses on just one feature and so forth. This is marrying the idea of collaboration and versioning within a UX practice well and is definitely possible on Figma with the “pages” feature (Wong 2023).