GDD730 – Module 2: Week 12: Fin

Twelve weeks ago, I met four strangers to form a team. We all had different backgrounds, interests, and schedules but were united by a passion for UX Design and an appetite to learn. I am so proud of what the team has achieved with the Transend platform in a relatively short space of time. Our achievements are not only visible in pitch and Prototype but all the supporting work. They are a great bunch, and I hope that I will stay in touch with the team throughout the course and beyond.

Figure 2: Team images from the Pitch Deck
Figure 1: Transend Porotype in Figma

Final Retrospective

I have reflected on this experience retrospectively and aligning my assertions with the project delivery cycle.


What went well:  The formation happened relatively quickly despite juggling five schedules. Elements of the structure, processes and tools were agreed upon upfront. We took time to get to know each team member on a more personal level, which helped us form our working relationships. Scott states that you need to understand each person’s motives, ambition, and current circumstances so they can be placed in the right role, leading to growth. (Scott, 2017).

What didn’t go well: I think for the rapid ideation, we could have been better prepared. In my opinion, if we had been each attended the kick meeting with one idea, we would have discussed more possibilities for our Prototype. Slick et al. states that both novice and experienced designers can fixate on a particular idea without considering a range of alternatives (Slick et al., 2014). Although over time, we had a range of ideas based on two themes, I think team members did fixate on a single idea. We spent too long discussing the concept before committing to it.

What could we do better:

For Rapid ideation in future, I will be better prepared with at least one idea or one article for inspiration at the outset.

In future, I would impose a time limit to collectively or individually agree upon a concept.


What went well: We agreed to plan using agile principles utilising the Kanban board. Each week we planned in the team elements of the course content. The Project Manager (PM) and Tutor ensured that the team were conscious of the interim and final deadlines.

What didn’t go well: I felt that planning should have been prioritised in the initial stages. As I was not in the role of PM I chose to step back , and allow our elected PM use this experience to develop their skills in this area. Although, as a team, we started to create tasks in Trello post week six, no estimation was applied.

What could we do better: On reflection, I should have shared my experience and made recommendations to the PM. It would have benefited the team overall such as utilising tools like Trello from the outset.

In my next project, I will utilise my professional experience and create a road Map, product backlog, and User Stories. I also intend to apply estimation to the tasks, so there is a comparative sizing. 


What went well: I think that as a team, we managed to do wide-ranging research. That went beyond the platform and covered social factors, including the impact of the pandemic, compactor analysis.

What didn’t go well: One of the challenges we faced was trying to create our Problem Statement; I think this is different when you are trying to come up with something fun to enhance peoples experience rather than trying to address a problem.

Filsan, my follow Researcher, developed an interview, and I developed a questionnaire building on that work to try and understand our users. As this was a new field for me, I did not follow my instincts regarding including additional questioning about whether users would be interested in our app and the remix playback elements.

What could we do better:

Get someone independent from the team or external to review research and challenge the rationale.

Next time I research, I will create broader questions to try to understand the user rather than structuring something that is biased to the hypothesis. 


What went well: I thought that the concept user journey and product design were compelling.

What didn’t go well: There was some confusion regarding who was responsible for the design elements. When Matt and I, who are less experienced designers, tried to contribute, it resulted in some throw away work, as I think there was a clash of styles. It was not clear which elements of the wireframes to include in the final design.

What could we do better:

I would priorities the Design System as the earlier this is in place, the more able, the wider team are to contribute to developing the Prototype.

I would encourage feedback and rework rather than a complete redesign.

Mark up the wireframe screens for inclusion in the Prototype.

In addition to reviewing assignment content, I would engage with the course tutors at the outset to understand the deliverables and their expectations. 

Planning Document – A spanner in the works 

Figure 3: A model framework of the effects of stress on performance (Salas et al., 2017)

We had collectively overlooked the level of work required for the Pitch Planning document artefact, which came to light in our final team meeting. The additional work placed the team under stress; Cox defies stress as environment or social stimuli, which can cause cognitive or behavioural effects that lead to task performance decrements (Cox, 1978). Stokes and Kite found that stress occurred when “stressors are perceived as exceeding one’s resources” ( Stokes and Kite, 2001).

Filsan and I volunteered to take the lead on this document. Once the initial draft was near completion, we agreed to share it with the team for review and input. The course leader reviewed the document and provided lengthily and detailed feedback.
As a team, we all had to pull together to tackle the feedback and divide it based on the areas that we were closest to.

During the final stages of producing the Pitch Plan artefact, communication became an issue, firstly, as everyone was in a rushed to edit the document. Secondly, I was working in London in a workshop, so I did not have access to Slack. Ineffective communication is one of the issues highlighted in Sala’s framework of stress affecting performance. In my opinion, at this stage, we would have benefited from WhatsApp or possibly a team call (Salas et al., 2017).

I was so impressed with how everyone in the team pulled together to turn around the Pitch Planning document. My contribution was to create the document structure detail a significant portion of the content, which the team to then built on and refined. If a similar situation arose in future, I would invest more time in handover and explaining my rationale and ensuring communication was maintained and accessible for the whole team.


Silk, E.M., Daly, S.R., Jablokow, K., Yilmaz, S. and Berg, M.N., 2014. The design problem framework: Using adaption-innovation theory to construct design problem statements.

Scott, K., 2017. Understand What Motivates Each Person on Your Team. Leader to Leader2017(86), pp.34-40.

Salas, E, Rico, R, & Passmore, J 2017, The Wiley Blackwell Handbook of the Psychology of Team Working and Collaborative Processes, John Wiley & Sons, Incorporated, Hoboken. Available from: ProQuest Ebook Central. [24 August 2021].

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 )

Google photo

You are commenting using your Google 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: