Prototypologies – Prototyping Museum Interactives

According to lore, Inuit cultures have over 50 words for snow. While that legendary factoid conjures images of imperialistic anthropologists in khaki, we understand the sentiment it attempts to convey: intimate connections spawn vocabulary.

“Prototype” is our “snow.” We use prototyping to test everything from experience to mechanics, we build them out of whatever gets the job done quickly and effectively—from art supplies to leftover AV parts.

We recently partnered with the Royal Ontario Museum in Toronto to create two interactives for their exhibit Out of the Depths: The Blue Whale Story. One focuses on blue whale genetics, the other is an adventure game about how they eat and the dangers they face day to day.

In order to distill some pretty complex marine science, build consensus among stakeholders with varied levels of expertise, and ensure the experience was actually fun, we got our “prototype on,” and we wanted to share some lessons from the project.

Go back to the basics: Paper and tape

When creating interactives from scratch, it is important to test design concepts at scale as early as possible. Designing and critiquing at scale goes a long way in getting a team on the same page before the project gets too in-the-weeds. This alignment is especially important if the project will be using hardware that has already been chosen–in other words, when the hardware dictates feasibility of design concepts and not the other way around. For the genetics interactive we created for the Museum, the screen dimensions became our stake in the ground around which we based all decisions about scale.

Good for:

• A sense of scale (the model was accurate to the screens that would be used)
• A sense of visual density
• Ability to explore options for primary interaction modes

Get physical: Live Action Role Playing (LARPing)

LARPing is a cultural phenomenon that occurs when groups of enthusiasts get together to reenact (or enact) a narrative complete with props and costumes. Think Warhammer, Orcs, Renaissance Faires, etc. We cannot claim to be dedicated enough to be active members of any LARPing communities, and, sadly, we did not have costumes. But, for this project, acting things out was key in creating rules and restrictions that strike a balance between being intuitive and challenging. Discussing game parameters over static comps left us feeling unclear about how scenarios in the game would play out, so we decided to walk through the scenarios step-by-step together. We discovered that developing, testing, and refining these rules was best done by doing, not just talking.

Good for:

• Differentiating core gameplay components (the whale would surface to breathe) from flourishes and extra features (a detailed animation when the whale surfaces), allowing us to selectively incorporate enhancements
• Developing the narrative arc and overall rhythm of the experience
• Identifying assumptions and reaching alignment among the internal team about how the game would work before presenting our ideas to our client partners

Keep iterating: The quick dive demo

A quick software build can demonstrate features that we couldn’t convey effectively through notecard simulations. While our game walkthrough highlighted, in detail, each component of the gameplay, it was less successful in suggesting how the individual features would gel into one cohesive experience. So building a no-frills demo helped us resolve how a user would control and steer the whale. This tool was essential for getting stakeholders to understand how individual pieces of gameplay (from assets to controls) would come together.

Good for:

• Seeing parts come together as a whole
• Conveying a general sense of motion
• Demonstrating the role of controls
• Giving stakeholders an early opportunity to actually play

Hardware matters, too: DIY Control Board

A goal from the outset of this project was to incorporate the simplicity and excitement of vintage arcade games into an experience tailored to the context and feel of the exhibition. To accomplish this, determining the the appropriate game controls was key. The control mechanisms also needed to work within the Museum’s existing technical parameters and be sturdy enough to endure dawn-to-dusk button-mashing. We needed to make sure the inputs were working on each of these levels, and needed to test them in an easy-to-build simulated environment. So, using the button model we would use for the actual installation, we built a prototype control board from a tangerine crate.

Good for:

• Developing gameplay with actual physical controls allowed our early testers to give better feedback
• Transportable and quick to set up, which is great for spontaneous testing
• Testing the workability (and durability!) of hardware
• Making recommendations about what additional instructions might be helpful

Conclusion: Fail early and often

Just as the word “snow” falls short in conveying the nuances of ice, slush, and fluff, “prototype” alone cannot express the possibilities when it comes to nimble testing. Prototypes take many forms, and each variation provides different insights, but there isn’t a single prototype that can test all design challenges. A paper prototype probably isn’t the right medium to evaluate a color palette, and an animation on an iPad won’t tell you anything about the durability of arcade buttons. But even unsuccessful prototypes provide valuable lessons in why and how they failed, and they start valuable conversations among those who build and test them.