Lessons Learned

While the development of the Nature Explorer is reaching an end and I am getting ready for the final project presentation, it would be beneficial to look back and identify what this experience has taught me. Starting from the very first post at the beginning of February about ILMD definitions to the very last one concerning the collaborative effort of designing for educational games, I will try to identify the learning experiences that were gained and their applicability in other design situations.

ILMD understanding

My idea of interactive multimedia for learning has not changed much since the beginning of the project. Maybe to my extensive experience developing educational software has helped me have a pretty good idea about interactivity, multimedia, and learning and their interplay. Also, theories about interaction design from the human-computer interaction side have helped me a lot to comprehend the design and development process, especially the importance of iteration and rapid prototyping. Nature Explorer was just another case where these tools allowed me to be productive right away and get feedback from peers and testing at the early stages of design, informing my redesigned prototypes.

Problem or technology first?

In this next phase I came to realize the importance of problem identification as a priority in instructional technology. Coming from a technology background I was inclined to try and find useful applications from existing and/or novel technologies. Thus, it came natural to me to think in terms of cool technologies that could be exploited for learning purposes; the Kinect was one of the first things that came to mind. Although such technologies play an important motivational role in instructional design, they could very easily guide someone astray during the important problem identification phase. Through the followed process I learned to focus on identifying actual instructional challenges and opportunities for applying computer-assisted instruction. I do recognize though, that depending on the domain you are working for you may need to wear different hats (MAE's favorite expression) to address different problems.

We have a problem, and now what...?

My interest about informal learning led me, one way or another, to the  Price House Nature Center, a volunteer-run museum which was "waiting" for my assistance. The unique needs of the space imposed some design guidelines that came right to mind after my first meeting with the Associate Director; the system should be extremely easy to use, require no instructions, and should be  durable to withstand kids' abuse! Normally I would have started right away to test my ideas (which I almost did) first on paper and then with actual prototypes. The requirement to do some precedent study and actually try to align the client's needs with some solid learning objectives were extremely helpful in providing a foundation on which I could build my instructional approach. Overall, the application evolved to be an instructional tool of informal learning instead of a fun scavenger hunt game with some potential flares of learning!

Are all the phases relevant?

The fours phases of instruction, although implicitly integrated in most of my previous educational software endeavors, were useful in forcing me think in terms of specific learning goals to be met. Despite the fact that not all of them seemed pertinent for the informal type of learning of the Nature Explorer (it was hard to see the role of practice and assessment at the beginning), they started to fall in place as soon as I started working in depth on the desired learning outcomes. Those four stages provide a framework when thinking about the objectives of any type of educational software. Similarly, the role of motivation was equally important in leveraging all these design elements that are considered engaging by children (e.g., role play, physical motion, social play, free exploration, etc.) and producing a fun learning experience. This was imperative even more in the context of this space where curiosity, challenge, and fantasy can be fostered in a way to promote discovery learning... and this is what NE is trying to achieve.

(Play)testing makes you better!

The best way to get valuable feedback in interaction design is to test with actual users, and that what I did in the next stage of the project. This is even more the case when developing learning software, where the role of testing is double: identify usability problems but also the learning effectiveness of the tool under development. Since these two aspects are intertwined it is hard to identify the latter disconnected from the former; i.e., problems in using the software prevent users from using it effectively and thus achieving the desired learning outcomes. Playtesting allowed me to identify some serious design flaws (e.g., how to scan a code, or how to identify one in the museum space) that I could not have predicted and would have, most probably, hindered the learning process. If the time allowed I would have preferred to play test a second, more polished prototype and give emphasis to learning assessment this time.

Usability remedy

The results of the playtesting have eventually paid off by revealing the weaknesses of the system mainly in supporting children in their learning process. As a designer enacting multiple roles you are doomed to make assumptions about how the tool is going to be used; this is even more the case if you don't have the necessary support from other experts (for more details see my previous post). Usability problems that were identified helped me understand the points where users needed elaborate explanations and/or some scaffolding in order to build a mental model of the system, in order to be able to follow its progress smoothly. Additionally, feedback from the instructors and peers was another source of potential issues that I decided to address to prevent future interaction glitches.

Transferring knowledge

One of the most important aspects of every learning experience is how to transfer the acquired knowledge to other domains and experiences. Firstly, the most significant gain was the unique experience of working for such an informal space where there are seemingly not enough guidelines on what needs to be achieved. Learning goals were quite ill-defined and I had to create the instructional objectives based on my understanding on the space's needs.
This was an interesting design challenge which can be widely applied in other domains where clients think they know what they want, but you still have to elicit their actual needs. 

Secondly, due to the space's irregular visit schedule and the sensitivity of the audience's age it was not feasible to observe and discuss about "users' needs" in a meaningful way. Although normally this is the case in user study techniques like contextual inquiry where you have to be temporarily integrated in the environment in order to understand the current work practice, there are instances where this is not feasible (e.g., working with private and secure data) and you have to find workarounds. Working for such a young target group gave me the opportunity to devise alternative methods to understand their needs (e.g., the playtesting session). 

Finally, the lack of available (domain and content) experts or their inability to respond promptly to my requests forced me to take over some roles in order to facilitate development. This is often the case when designing in the real world, where clients might not always appreciate the importance of such experts and the designer has to bear some of this burden.

Overall, working for such an open-ended project, with loosely-defined needs, "inarticulate" users, and non-existent instructional objectives was a great opportunity for me to test my -instructional and interactive- design abilities. I had to impose some design guidelines and constraints based on my understanding of the problem and test my assumptions during an iterative, rapid prototyping process. The challenge might have been unique in this situation, but the resulting process was an invaluable tool for future design experiences.

Communicating Educational Game Design

Coordinating Tasks

Building educational games involves the collaboration of an interdisciplinary team consisting of the game designer(s), the graphic designer(s), the domain expert(s), and the pedagogy expert(s). For the purposes of the Nature Explorer I had to undertake some roles while also communicating design decisions with other members of the team to develop a final product that would be appropriate for the client but also effective for its learning objectives. This was no trivial task since different stakeholders have different priorities in designing an educational game; my main concern was to have a technologically perfect product that can withstand children use but also be entertaining to keep their interest, while other parties were more concerned of the content and its appropriateness for the target audience.

Although I did try to accommodate what I believed to be of interest to 10-year old kids, there was no way I could have done this as effectively as an educator. Also, finding the appropriate informative hints that would make sense to the knowledge level of potential young museum visitors was another task that I wanted to offload to someone considered a content expert. Unfortunately, the volunteered-based nature of the museum, acting as the client, had no resources at hand to provide this information promptly. Instead, they have assigned someone as a contact person to coordinate compiling the material (basically the text), also assuming it would be in the right tone and style. As far as I know, the "content experts" in this case were parents who were visiting the museum and often volunteered to help with its activities. This fact made it impossible to either have a timely response by everyone but also to get a consistent style in the content according to my guidelines.

As a consequence the client had to provide most of the content after realizing that the delegates were not as efficient as expected! Even in this case the content did not conform to the constraints and principles imposed by the game design. More specifically, some hints were too generic to provide any meaningful help to the players (e.g., I am a reptile). Also, the hints had to be of specific nature so that they could be easily sketched in a way that can communicate the illustrated message meaningfully (e.g., My young are called "kits"). Even more, a necessary constraint imposed by the required expandability of the system (i.e., the museum should be able to add more animals easily) the hints had to be the same between the two levels, which was not the case with most of the provided content. These conflicts necessitated my intervention in content-writing and a new cycle of edits and reviews by the museum person acting as domain expert.

At the same time this person was acting as the educator who had the capacity to format the content appropriately. She has also been giving some useful advice on the level of knowledge that kids are supposed to have at this age, which has also been affecting graphic design representation. As an example, I was instructed that the mountains should be more rounded instead of being pointy with snowed peaks, because this is how the Appalachian mountains are. Some other advice included the use of specific wording that was supposed to be keen to children; however, after further review and use of such wording in the prototype it was revealed that this was not such a common word in children's dictionary (e.g., 'tree cookie' to reveal a slice of tree trunk). Such incidents revealed the need to have a dedicated pedagogy expert who knows exactly the culture and cognitive abilities of the 4-10 years old children in the area.

Intercontinental Collaboration

During the decision and content negotiation process I had to work with the animator in order to produce some initial sketches for the prototype. Since he was located in Athens, Greece it was quite hard to coordinate our time schedule and work at the same time. Consequently, we had to arrange some online meetings where things were explained and clarified about graphic design needs. To avoid any miscommunication of intentions most of the content was drafted on the fly and had to be approved by me before proceeding to the final designs. His drawings were based on my guidelines both for the layout of the interface, but also as far as the habitats and hints specifics are concerned. For the former I had to setup an interface wireframe which he used as a guide to draw the sketches in the right proportions (see image below).

The wireframe used for sketching the interface elements.

The latter involved a much more complicated process, since more considerations had to be taken into account. Firstly, the comments about specific characteristics of the habitats had to be accommodated by the designer (e.g., comments like the one about the mountains' shape mentioned above). Also, it was necessary that the attributes of each habitat were drawn in such a way that there was adequate space to place the animal within context (e.g., have the squirrel appear on a tree branch). Another equally important concern was to draw the environment in such a perspective that all animals would appear in a natural size and still preserve the habitat's characteristics. This proved very challenging especially for the 'underground' where animals had to appear in holes and caves, while also maintaining a view of the surroundings. The following figure provides a draft which was a result of many previous attempts to tackle the problem; the skunk's home appears as transparent while the fox' cave has an outwards view.

The 'underground' habitat which hosts the fox and the skunk.

Secondly, animals had to be accurately designed without sacrificing their playful and cartoon character; this demanded thorough research about the animal and its more prominent characteristics which were also described in the hints. What was even harder was to draw specific hints that could be meaningful in guiding players to visually comprehend the hint, without giving away the actual animal. To avoid such incidents, I had to come up with an initial list describing the hint visualization that was then reviewed and negotiated with the animator. An excerpt from the table provided to the animator is displayed below for the owl and the skunk. The resulting sketch drafts, that represent those hints after our discussions, are shown in the following image.

Owl	I am bird living at night.	I like to eat insects and mice.	I have a wide face and really big eyes.	I am a wise bird!
	night sky (already have it)	a plate with a mouse and a fly	a wide female face with big eyes	a pile of books
Skunk	I have stripes in my fur.	I eat bugs, mice, birds, eggs, berries, and nuts.	I can spray liquid to blind my predators.	I use my smell to scare others away.
	a fur (coat) with B&W stripes	a plate with a mouse, eggs, and nuts	a spray in a dog's face	a really bad smell and someone with a disgusted face

Overall, the coordination of the different parties was a laborious and time consuming task that demanded timely coordination of content creation and provision. Unfortunately, time constraints did not allow a second playtesting for evaluating the effectiveness of these negotiated outcomes of educational game design in communicating the message to players[1]. However, we hope that the outcome will pay off by engaging the children in a fun and engaging exploration of the Nature Center!

---

[1] Winn & Heeter (2006). Resolving conflicts in educational game design through playtesting. Innovate 3(2).