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.
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.
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.
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.
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.
About the author – Joanie Thompson
Joanie Thompson is a Producer at BlueCadet. She values curiosity and the creative process. Joanie shepherds projects from beginning to end, helping the team create final products that showcase superior storytelling and thoughtful technology.
At Bluecadet, Joanie has worked on projects for clients including the New York Public Library, Princeton University, The Presidio Trust, and the National World War II Museum. From blue whales to college admission, her projects have covered a wide range of subject matter and have been created with a diverse array of technologies.