Reflective Statement Interaction and Play
Over the course of this paper I’ve learnt about the importance of low-fidelity prototyping and testing, having clear design goals embedded into your design process and how the group development process can influence a project outcome.
I’ve learnt in this project to test your idea in the most minimal form as early as possible, to challenge your assumptions about your design and to help direct the direction of your design process.
Initially, the prototype we planned to create focused on the interaction of multiple tents communicating with each other through the use of the XBee wireless communication modules. We planned to prove that communication between the separate tents was possible. Although we came across tutorials proving this was possible, and explaining how it could be implemented (Codebender_cc., n.d; Lightfoot, 2016; Patchu101., n.d), we still chose to focus our energy on developing a prototype of this inter-tent communication. Coming up against technical issues with electrical components forced us to consider alternative prototypes with the sparse time we had left before deadline. The main prototype we generated ending up being a simple fabric model of the tent and a strip of LED lights, that encouraged us to consider more about the potential user interaction itself when play testing.
Considering play testing should ideally begin 20% into the project cycle using the most minimal form of the game design as possible (Salen & Zimmerman, 2010), I think we should have cranked out a simpler, low-fidelity prototype of this earlier on in our design process.
Testing the prototype 90% into the project cycle and with a relatively polished tent model, we gained a lot of insight on the actual interaction between the users and the tents themselves. If we had focused our prototyping on the most basic, low-fidelity form of prototyping straight away, such as a folded paper tent with our smart phones simulating the light display, this would have allowed for the more playful and explorative design approach Rogers, Sharp & Preece (2011) explain as being crucial to the early stages of interaction design.
In terms of the future directions of the project, the members within our group have slightly varying priorities. Personally, considering future directions for the project is less about the design possibilities for our project and more about methodological approaches.
Currently, our methodology revolves around the two external parties, Nordisk and Splore. Nordisk influences our design of the physical, functional elements of the project, and Splore influences how we design the user experience.
Nordisk has given us an open framework to work from, with their products as reference points to guide what we design and a meeting to present our final prototypes. Designing the tents based in the context of the Splore festival has allowed us to define the user group we are designing for and the kind of environment the interactive experience will take place in. They have also given us regular feedback on our progress and an opportunity to test an installation at their festival next year.
The flaw in using these two parties to guide the direction of our project, is how little it pushes us to explore and play in our iterative design process. Salen & Zimmerman (2010) explain that the iterative design cycle process involving “prototyping, playtesting, evaluation, and refinement” allows for the playful nature necessary to achieve game design goals. We have almost completed one of these cycles in our project, however, while trying to make refinement to our concept, we are struggling because we don’t have any of our own key design goals to refer back to. At the moment, we are relying on the feedback and priorities of the above external parties to define the decisions we make about our design. What I would propose, is introducing some of our own key design goals to refer back to in further design cycles. These could be along the lines of “design an interactive experience that creates a sense of connectedness among attendees at a music festival” or “use lighting displays to guide festival attendees’ emotional state during a festival”. Having these goals to refer back to would help guide our design method and open a door to explore design concepts further during design cycles.
Coming into the formed group part-way through the semester has proven challenging for me in this project. It’s meant I have been inadvertently excluded from the group’s relied upon communication platform (Facebook, which I don’t use) and that I’ve had take initiative to create individual responsibilities and focus for myself as a team member. Tuckman (1965) suggests that the sequence teams develop involves the stages of “Forming, Storming, Norming, Performing and Adjourning”. Based on the Tuckman’s description of these stages, I can see that the point I joined the group was during their norming phase, where “Ingroup feeling and cohesiveness develop; new standards evolve and new roles are adopted”. The group had already worked their way through the initial stages of forming, where imbalanced expectations and approaches were evened out and the team had a clear set of goals and defined individual roles. This meant my involvement in this process was slightly lagged, and gave me a sense of isolation and unclear expectations. I found my expectations and goals were not as aligned with the groups throughout the project. For example, I was focused on finishing our prototype to a high, thoroughly tested standard by the end of the paper this semester, whereas the rest of the group had aimed to reach this stage after the end of this semester, when presenting to Nordisk, because they had agreed that was a higher priority as a group prior to my joining.
Experiences this atypical group formation process, has shown me how important engaging in every stage of group development (Tuckman, 1965) together is for a group to gain balanced expectations and a sense of cohesion that leads to a high team performance level.
In conclusion, based on my learnings working on this project, I will place priority on testing low-fidelity prototypes early on, defining clear goals to inform my design decisions, and being aware of the group development process my team is following in future projects.
References:
Codebender_cc. (n.d). Instructable: “How to Use XBee Modules As Transmitter & Receiver - Arduino Tutorial”. Received from URL: http://www.instructables.com/id/How-to-Use-XBee-Modules-As-Transmitter-Receiver-Ar/
Lightfoot, J. (July, 2016). “Get Started with Xbee - A Beginner’s Tutorial”. Retrieved from URL: https://spin.atomicobject.com/2016/07/18/xbee-tutorial/
Patchu101. (n.d). Instructable: “Xbee Mesh Network Construction”. Retrieved from URL: http://www.instructables.com/id/XBee-Mesh-Network-Construction/
Rogers, Y., Sharp, H., & Preece, J. (2011). Interaction design: beyond human-computer interaction. John Wiley & Sons.
Salen, K., & Zimmerman, E. (2010). Rules of play: game design fundamentals. Cambridge, Mass.: The MIT Press.
Tuckman, B. W. (1965). Developmental sequence in small groups. Psychological bulletin, 63(6), 384.
