Addressing Usability Problems

After completing the playtesting in the actual museum with real visitors (kids), we had to redesign the system to address the problems found. In this report I include a list of the most serious flaws identified and the way they have been tackled. I also include some design decisions that had to be taken based on feedback from instructors and peers. For a detailed list of these usability problems please see the previous post.

#1 How do I scan?

Neither the camera not the actual way of scanning was obvious to none of the participants in the playtesting. To address this issue we are using two ways: on the hardware level and on the software level. For the hardware the intention is to place the camera in an obvious place with a clear label "scan here", but also use some glass in a distance where children can place the tagged label on. In software level we have included an image depicting clearly the way to hold the code in front of the camera.

#2 When do I scan?

This was another frequently-occurring problem where children needed some prompt to start scanning. Again, a virtual helper will be available in the system that will prompt users whenever there is a need to scan a label. The mockup at the moment includes a mouse holding a label which says "scan now" (what more obvious!) Similar prompts appear throughout the game as a means to make always clear what is the current state of the system and provide meaningful feedback on the user's actions. The messages appear at the right of the screen and are not always visible so as not to distract the player's attentions while interacting or reading other information.

#3 Icons... which icons?

An important observation during playtesting which was also pointed out during the pin up sessions what that visual hints were not obvious. To remedy that problem we have made those small images animated, starting exactly at the point of the textual hint and traveling to their final destination (at the top of the image) while passing by the notes counter and increasing it by one. This ensures three things: a) that the meaning of each icon is clear, b) that the icon is visible at ll times and is not lost in the image, and c) that there is a clear connection between hints and notes taken. The drawback is that the icons do not appear in the context of the environment, but we consider this to be a trivial issue after reviewing the nature of the hints (few of them can actually make sense in the environment without the animal).

#4 Where are the labels?

Many kids could not find the tags placed near animal exhibits. This will be easily addressed when designing the labels so as they are big enough and standing at an obvious point. Also, there could be an indication of a code-enabled label in the front side, which will make those labels distinguishable from other labels that might already reside in the museum. A potential design could be like the one depicted here, where the label is standing on a properly cut cork with the animal image and name in front and a thumbnail of the QR code above the picture. This will make the labels recognizable from a distance with minimal effort. However, a full-scale code will exist on the back of the label to make to extremely easy to scan without demanding too much accuracy (the larger the code the easier for the software to recognize the encoded message).

Challenges

However, implementing these features is not without cost. Having a dedicated space for instructions consumes valuable space, but we think that this pays off by making the intentions of the system clear, which is fundamental for the user experience. The labels are fairly easy to be designed as an obvious part of the game, but then the question is if we are leading the player in choosing animals, instead of actually thinking of the animal to look for! Actually this was observed during the playtesting, when children were asking us where are the labels hidden. However, speaking with the client I was told that making the animals that are part of the game obvious is a requirement, despite my reluctance due to making the game fairly easy and with less educational value for the reason explained above.

The biggest challenge was the animated icons and how they would allow future expansion of the system by the museum. A special technique had to be devised in the software for animating those elements while also keeping them accessible on the hard disk. This allows someone to edit them or add new ones using, however, a template with dimension characteristics. There is no way for the system to reject of accept images based on their specifications, so extra care should be taken when updating the content (similarly to doing so with textual information).