Storyboards and prototypes

This post reflects on constructing a storyboard  and a prototype for a mobile learning outdoors activity as part of the Learning Design Studio for H817 Openness and Innovation in elearning

Imagining – the storyboard
The storyboard is a visual mapping out of the proposed learning activity. Although we were working in a group, we created individual storyboards first. My storyboard grew out of the work done at the research phase, and I also used the personas’ forces to inform the design of activities. I created mine in Linolit, which worked well for the creation but was not easy to output into a format that could be embedded in a website or document, so in the end I took a photo of the screen.

Sukaina_storyboard_pic copy

Storyboard (click for a larger image)
My storyboard spanned three phases and detailed a number of activities. While I was developing this, it became clear that I was designing for two audiences: school groups and day visitors but that the school trips would need activities that spanned beyond the site visit. I therefore developed an approach that had classroom activities either side of the site visit, but that the activities at the site visit could also be done stand-alone using resources available either at the Visitor Centre or through the website. During this time, it was the case studies that I had analysed that provided the greatest influence although I also referred to the personas when thinking would this persona be interested in this activity?

Two team members completed storyboards and three members discussed the storyboards in Google Hangouts and agreed to synthesise the two boards using the Google template provided as there were considerable similarities, adopting the overall approach of a learning activity that spanned classroom and on-site learning. Following this, one team member agreed to construct a team storyboard which would be approved by the whole team in another collaborative meeting. This stage also saw a narrowing of the scope to just myths and legends, rather than a more general all-encompassing approach that might have covered other subjects. The team discussion was a strength here as the team members were able to use the visual aspects of the storyboard to discuss options and differences. The advantage of the collaborative storyboard was its visual display of the learning activities; we could see which activities were cluttered and unclear, and we could move them around, to see what we were expecting participants to do. I could see that the process was important for helping the activity form in our imaginations; for example we placed activities for a given stage in a non-linear way, which intuitively showed that the activities did not need to follow a prescriptive stage and were more fluid.

The storyboard was not without its problems though as in order to fit text into boxes and even into the overall canvas, we may have oversimplified some things and the level of granularity needed for description was not always clear. The storyboard worked at an activity level, but I am not sure how it would work at a course level with the level of collaboration and discussion that was required.

Making it real – creating a prototype

Before we could build a prototype, the team had to decide what features to prototype. The mechanism for this was in developing a features table from the storyboard, extracting features from the storyboard. This provided to be a useful activity, not only for deciding which features were important to prototype but also served as a reality check of whether the activities on the storyboard made sense. The features table comprised a list of items broken down into discrete components such as creating the text instructions for a page, the actual page (say a web page), any media elements associated with that page, and any functions that might need to be built into a web page. There was initial confusion about the task  as it required some understanding of what was meant by a ‘feature’ and also re-translating the original instruction of organising by ‘scene’ (as in a movie or series of screens?) to something that made sense to our project. For this, I split our activity into 4 scenes: scene 1 was activity in the classroom prior to the site visit, scene 2a was activities at the Visitors’ Centre, scene 3 was Activities in the outdoors at the Giant’s Causeway and scene 4 was post-visit activities to create the artifact. Once this organising principle was in place, it became easier to extract the features.

Creating a prototype for an outdoors activity for a mobile learning app was a challenge as we did not have a realistic chance of actually building an app, and we were working in a virtually distributed team. However, putting myself in the learners’ position helps prompted me to suggest that we could develop the website that would serve as the ‘home’ for the activity – where users could go and download the app and the brochure, where users could go to see what stories had been told, where teachers could go and find more information. This at least would serve as an authentic experience for someone deciding whether to partake in the activity, planning the field trip or who wanted to submit their story.

Further in order to prototype the app functionality, we agreed to create PowerPoint presentations of the steps the user would go through to see the augmented reality and the other features about the app.  There was no time to actually develop the app but we were able to create one example of augmented reality which was recorded and uploaded onto the site.

I quickly created this site using Google sites adding holding text into the relevant sections, and then another team member made the powerpoint presentations that demonstrated the some of the screens of the app, showing what functions were available.

prototype

Screenshot from prototype website showing mobile app interface mockup

Constructing the prototype and seeing parts of the possible product come to life was a motivating moment as there was something tangible beyond the discussions, ideas and the storyboard.

Prototypes such as this have their limitations. In this case, the heart of the activity is the mobile app, but without the time or resources to build the app, we could only demonstrate in a presentation how some screens and features of the app might work. This is a limited way to assess whether a mobile learning activity is going to function in the context, where connectivity, speed as well as other environmental variables might be a factor. These aspects might not be picked up in a prototype, and I’d argue for a mobile app, that a beta version would be required for adequate testing in the field.

However, the prototype we built was useful to communicate what the activity might involve for learners and field trip organisers and would be useful for a situation to establish a proof of concept or to get buy-in.  Simple mockups can prevent expensive programming that has to be discarded or (possibly worse) continuing with a problematic product because it is too late or expensive to make changes.

Advertisements