Presenting the IT University experience
Subjecting your designs for other humans than yourself is always an enlightening experience. As I described in the post about the cake dispenser, you learn a lot by seeing somebody else try out your designs. You seldom have foreseen every emergent behavior. This was also the case with our final project.
We had worked on finishing the installation in good time, so that we would be able to test it with somebody else than ourselves. However when it was time to test we experienced a couple of breakdowns. The computer that was running the Unity program was unable to show it in fullscreen, and the connection to the pencil was unreliable, meaning that it sometimes would stop working without warning. Nonetheless, we decided to show the installation to a couple of our co-students, and in spite of bugs and breakdowns we did learn something. We saw that the testers were in doubt whether their actions actually was recorded as input. An insight that lead to the addition of augmented feedback as explained in the previous post. However the missing functionality made it hard to test it any further and we decided to spend our time making sure the system would work reliably for the presentation.
After having spent almost four weeks on developing our project presentation day arrived. A representative from Yoke was present to see and give feedback to our proposed designs. When it was our turn to present, we gave a short explanation of the concept and let our two lecturers Laurens and Jonas as well as the representative from Yoke try out the installation.
Immediately we saw some confusion. What were the rules, who was supposed to do what and to what result? We explained that one would be using the keyboard to type, one would be drawing and one would communicate to the others using the microphone. Immediately Laurens started shouting commands into the microphone and the other two got to work as well. While a bit hesitant at first Jonas and the representative from Yoke increased their speed and eventually they were typing and drawing wildly. After about a minute or two they finished the game, and started to give comments on the experience.
The Yoke representative explained that his hesitance in the beginning was caused by him being unsure what to type on the keyboard. Seemingly the functional feedforward (Wensveen, Djajadiningrat & Overbeeke 2004) of keyboard and screen signified that he was supposed to write something specific. During the design process, we had discussed the possibility of covering the letters on the keyboard as they were not significant in this context. We had not followed up on that idea, but it might have helped in terms of removing focus on the specificity of the individual keys.
Jonas said that he had a similar concern with the pencil, as he was unsure what to draw and which effect it had on the system. His movements were recorded, which could be seen through the augmented feedback, but was he doing it right or wrong?
It became clear to us that the our test persons were simply not aware of which effect they had on the system. While we had tried to augment the feedback to make sure that the users would clearly see that their actions were affecting the element on the screen, we had forgot an important aspect. Couplings.
Couplings is a concept from the Interaction Frogger framework by Wensveen, Djajadiningrat and Overbeeke (2004). The authors present six aspects from the natural world as couplings: Time, location, direction, dynamics, modality and expression. The couplings between the drawing and the typing action to the functional feedback on the screen was simply too weak. The typing and drawing actions are only coupled to the on screen reaction in time. This leaves little information for the users to evaluate the consequences of their actions. It is further complicated by the fact that it may be hard to single out your effects on the system as the other players are acting simultaneously.
According to Wensveen, Djajadiningrat and Overbeeke (2004) this lack of information can be mitigated through providing sufficient feedback and feedforward, which was our intent by adding augmented feedback to the screen. However it was not enough to make the connection clear.
Lack of information results in the users creating a wrong mental model of the system, which makes him or her unable to act appropriately (Norman 1988). This information is part of the system image, that is how the system presents itself to the user. Having designed the system, we possess the conceptual model on which the system is built, which makes is hard to assess which mental models the system image evokes in others.
Sociality & engagement
Laurens highlighted the social aspect of the installation. As he took the microphone, he was able to command the actions of the other two users. That the person would give actual commands to the other users was not something we had planned for. Making arbitrary sounds had been sufficient to make the system react, but as with the pencil and the keyboard, the inherent feedforward of the microphone might have been implying a focus on specificity that was not intended. However by talking directly to the other players and not to the system he enhanced the social aspect of the game.
An appropriate challenge, a feeling of control and sociality have been shown to increase the engagement with a game (Rozendaal, Braat & Wensveen 2010). Distributing game controls among players have furthermore been shown to significantly increase the experienced sociality while decreasing the feeling of control (Rozendaal, Braat & Wensveen 2010). To mitigate the loss of control through distributed controls, the player can assume a role of leadership, to regain some of this feeling.
While it is hard to say exactly how the installation was experienced, one can speculate that Laurens assumed a position of leadership in which he gained some feeling of control. Working together towards a common goal have likely created some sense of sociality. However being in a conforming position, and lacking control because of the confusing system image, have probably inhibited the feeling of engagement in both Jonas and the representative from Yoke. From a spectators point of view Laurens surely seemed most engaged in the installation. In all the interactions there are no real challenge. The tasks themselves are trivial and does not require any more skill than pressing a button or waving around a pencil or making sounds.
Following this theory, the experience have probably been little engaging for the “designer” and “developer” role, and only slightly more for the “manager” limited by a lack of challenge and control.
Looking back on the process, we might have spent too long time on deciding on the function of the installation to be able to really explore how we would communicate that function to the user. The installation contains a complex narrative about IT-projects and the feeling of creating those, that is not really unfolded.
A key takeaway is naturally to finish with sufficient time to test it on real people in the real context. Many of the points that I have made in this posts would be fruitful to use as basis for another iteration on the interaction.
Norman, D. A. (1988). The psychology of everyday things. Basic books.
Rozendaal, M. C., Braat, B. A., & Wensveen, S. A. (2010). Exploring sociality and engagement in play through game-control distribution. Ai & Society, 25(2), 193–201.
Wensveen, S. A., Djajadiningrat, J. P., & Overbeeke, C. J. (2004, August). Interaction frogger: a design framework to couple action and function through feedback and feedforward. In Proceedings of the 5th conference on Designing interactive systems: processes, practices, methods, and techniques (pp. 177–184). ACM.