For this project, my main role was Project Manager, and as such the bulk of my contributions were organisational. I also drafted and researched the dialogue (which became the informational signs in the final game), created both of our pitch powerpoints, created the design document (transcribed to this page) and designed the mini-games for each of the game areas.
Welcome to Flower Tower! I am Lady, a Coccinella septempunctata and your tour guide today. Follow me as we journey through the different parts of the tulip and explore the inner workings of flowers, learning how they work from the inside!
In this reflective statement I will provide a quick summary of the project, analyse and critique the ideas and methods we used in our project, reflect on my personal feelings and reactions towards them, and discuss the future possibilities I see for the Aotea Project of Things.
Our project started off with several ideas, the favoured one being creating an interactive display that would educate people with the history of Aotea Square, and in particular its Taniwha. We eventually moved away from this theme due to concerns about it controversial nature (for example) and the lack of correspondence from the Iwi that we reached out to, focusing more on the general history, and the Hauora connections – physical, social, spiritual, and mental and emotional – to the area. As our thematic ideas shifted, so did our physical ones. We had been focusing on the idea of having the Hauora pathways (series of interactive installations related to one of the walls of Hauora) lead towards the center of the area (informed by our practical research into the ways Aotea Square is used, which I discussed here), which would hold a central piece – originally the Taniwha. After we made the paths our main focus, we also decided to make the project a collaborative one – instead of making the path artefacts ourselves, we would create a set of guidelines for local artists and interaction designers to follow. We created a website to act as a medium between us and the potential designers and several example artefacts to illustrate our guidelines.
On the whole, I think our ideas have potential, but the methods we used and our execution of them leave much to be desired. Our group followed a rough plan for each week – we would meet and discuss ideas and such in class, work on tasks individually, meet again before the next class and use that class to either present or discuss our ideas to/with an outside source – usually Ben. The main issue we had was that our communication skills were lacking, but each stage of our cycle was problematic for it’s own reasons as well. In our first meeting, discussions were often unbalanced, with quieter members of the group having little opportunity to share ideas without being overruled by the more extroverted ones, or just drowned out entirely. I feel this hurt our project quite a bit – the first and only time I tried to bring up my concerns with the current idea (see here) they were immediately dismissed. Our individual tasks were often ill-defined – during several weeks, half the group would be given a specific goal, while the rest would be told to “just work on whatever” – which left me feeling like I had no real purpose in the group. This was somewhat remedied once we began working on the website and example projects, as our project managers began to make sure every person had a task. Our meetings outside of class were often sparsely attended, with often only two people showing up on time. Aside from causing us to have less face-to-face time to discuss our designs, I believe that our group’s morale began to drop as a result of the lack of motivation displayed. Aside from these, we also had issues with our communication outside of our meetups – we began by using Slack for the first half of our project, but several members experienced issues receiving notifications from the app, partially causing some of the issues described above. When we moved to using Facebook Messenger, we still had a lack of proper communication. With both messaging systems, the main use was coordinating meetings – which often failed – and clarifying requirements for week starters and presentations. Discussions about design decisions were almost exclusive to physical meetups, meaning anyone who did not attend was uninformed. In a study done by Curtis et al. (1988), many of the designers felt that face-to-face communication was vital for a project, and a lack of communication lines between groups that did not directly work with each other “hindered understanding requirements” and “buried the design rationale”. If our group had spent more time working together instead of separately and had proper discussions instead of ones where the most assertive overruled everyone else, we may have iterated our ideas faster and moved on to more successful ones quicker.
Another problem with our method was the lack of early prototyping, and the lack of focus in most of our prototypes. In my research on prototyping I have found that prototypes that fulfil a specific goal or set of goals work best to find problems in a design, that they should be able to generate feedback and insights into the design and they should be iterated early and often (Menold et al., 2017). I have also found that they can cause several problems in the design process, even as they help it along. For example, the sole prototype we made in the first half of the project was a small, physical version of the Taniwha Seesaw idea. It did not have any real purpose other than creating a physical version of what we already had on paper. It was not to scale, and not made of any materials that we wanted to test – we merely wanted to see the water flow from one ‘tank’ (tic tac container) to the other. I believe this is an example of “prototyping [leading] to premature commitment to a design” (Bichelmeyer & Tripp, 1990). Many of our later ‘prototypes’ were more designed as visual aids rather than tools to test an idea or theory, with the exception of our website. Even then, I feel we should have created it earlier and spent more time testing than designing – due to how late in our project we began testing, we only had a small number of testers, and no time to iterate on our designs. I felt that the rushed nature of those designs was quite evident in the feedback we did get, as many people struggled to navigate the site, as well as the fact that the individual pieces created by each member of the group for the site were not fitted together well.
Like I mentioned before, I believe the concept we ended up with has a lot of potential, and I am considering continuing on with the project, with a greater focus on coherency and accessibility for the website. I believe a good method for not only testing the website, but also generating example works would be to ask designers (possibly students from AUT) to access the website and try to create an idea that fits the criteria for one of the paths. Ideas that work well for the project would indicate that the website is successful, while failures would give insight as to what is being miscommunicated.
Bichelmeyer, B., & Tripp, S. (1990). Rapid prototyping: an alternative instructional design strategy. Educational Technology Research and Development, 38(1), 31-44. https://doi.org/10.1007/BF02298246
Curtis, B., Krasner, H., & Iscoe, N. (1988). A field study of the software design process for large systems. Communications of the ACM, 31(11), 1268-1287. https://doi.org/10.1145/50087.50089
Durie, M. (2017, May 18). Maori health models – Te Whare Tapa Whā. Retrieved August 16, 2017, from http://www.health.govt.nz/our-work/populations/maori-health/maori-health-models/maori-health-models-te-whare-tapa-wha
Field, M. (2011, June 10). John Key: ‘I don’t believe in taniwhas’. Retrieved August 21, 2017 from http://www.stuff.co.nz/auckland/5125859/John-Key-I-don-t-believe-in-taniwhas
Menold, J., Jablokow, K., & Simpson, T. (2017). Prototype for x (PFX): a holistic framework for structuring prototyping methods to support engineering design. Design Studies, 50, 70-112. https://doi.org/10.1016/j.destud.2017.03.001