Prototype. Even the word sounds foreign and kind of high tech, evoking images of NASA scientists tinkering away at miniature Mars Rovers and Silicon Valley whiz kids pouring over their newest social media toys.
So as prototype production week approached at the Reese News Lab, so did a looming sense of dread. How would we be able to create a functioning prototype for a digital news product if none of us were a) NASA scientists or b) Silicon Valley whiz kids? To put this in perspective, I spent half of last week watching YouTube videos just to figure out how to embed a YouTube video.
We needed to build a prototype to test the viability of a news product that would distribute stories and visuals generated by from kids around the world in the form of a digital postcard. The content of these postcards would be collected by NGOs working in proximity to the children and then packaged—along with photos, video, audio or other multimedia—into a postcard and emailed to classrooms, subscribers and families across the globe. Subscribers would receive 2-3 postcards per month, touching on everything from international news, to cultural events, to everyday activities in underrepresented geographic areas.
When the time finally arrived to get started on prototypes, something funny happened. The lab’s leaders suggested—practically encouraged—that we create something much simpler than the Java-coded, remote control-activated Mars Rover-cum-social media aggregator I had envisioned.
They suggested a paper prototype.
At first, this suggestion, though certainly welcome, struck me as a little simplistic. Why would we want to start off with something not just basic, but so basic? Didn’t we want to have end-users testing with something closer to our finished product?
We plunged ahead anyway. We created paper postcards with simple layouts and a range of content.
Then, five tries into creating a paper prototype, it hit me: We have no idea what our finished product will look like. And while we ultimately aim to create a digital product, building something physical allowed us to easily tweak, change, add, trash and ultimate create something that, which seemingly user-friendly, may not even hold up in testing.
Because we are interested in testing fundamental questions like: Do people prefer longer or shorter postcards? How much—if any—editing is necessary? What kinds of stories do people like to read? What kind of visuals are best?, it didn’t make sense to invest in creating a fully functioning digital version. With a paper prototype, we can easily make changes, trash things that don’t work, and receive quick feedback from peers. Although we will ultimately need to transition to digital, paper provides the flexibility we need and allows us to delay aesthetic detail and instead focus on the basics.
And, on the other side of the equation, having a physical product also made it easier to receive quick feedback from users. By interacting with the product in its most stripped-down incarnation, our peers in the lab were able to give feedback on the most basic elements, some of which may have gone unnoticed if we immediately launched into digital.
So what’s the take away? Paper is good. Basic is better. And a prototype is supposed to change—it’s the first version of your product—so don’t worry about creating something that looks like your finished product.