Tuesday, October 13, 2015

The Prototype Stereotype

It’s a sunny day in Santa Cruz, and Alice is showing Bob her new app:

Alice: This is Frosttly, my new on-demand delivery service for cupcakes. 

Bob: Cool! How does it work?

Alice: It’s based on the Uber and Google Maps APIs. Whenever, you press this button, it texts one of our Cupcake Delivery Specialists your current location and summons an Uber so they can bring you cupcakes. 

Bob: Wait; there’s got to be more to it than that. 

Alice: Naturally, this is just a prototype. The final version will integrate directly into the order system for a specialized cupcake kitchen, and will feature sophisticated order tracking and highly optimized routing of deliveries. It’s fully functioning though. Go ahead; try it. 

Bob presses the button, and hears Alice’s phone vibrate in the other room 

Bob: Wow, it works! I can’t wait to get my cupcakes.

If you’ve ever been to a hackathon, you might have seen plenty of conversations like this. Elsewhere, Billy is showing Alyssa his prototype of a new dessert: he poured confectioners sugar over an antique dinnerware set to create something light and fluffy with a rustic feel (the final version will also have chocolate and goji berries). Billy’s concoction is much closer to a final product than Alice’s cupcake service without cupcakes, and may have even taken more work than her handful of lines of code. Yet still I’d be surprised if I saw anyone calling a pile of sugar a prototype dessert. What makes one a prototype but not the other? The resolution is simple: there’s no such thing as a prototype app.

A few years ago, my working definition of a prototype was simple; you build enough of your plan to get a sense of what the final version looks like and show you could build the whole thing. The prototype of my app for playing arbitrary card games was a screen where you could drag-and-drop rectangles. The prototype of my game mod used hand-crafted assembly to make changes. This breaks down when you stop to think: what aspect exactly are you trying to figure out?

Some people walk into Jesse Schell’s Game Design class expecting an easy time, and are shocked to find themselves pulling multiple all-nighters for a class where getting a 100% on everything is only enough for a B. But those that persevere find themselves with new worldviews on everything from sleep to applied probability theory, and learn why there’s no such thing as a prototype app. As Schell states in his book “The Art of Game Design,” a prototype is defined not by the product it steps towards, but by the question it’s intended to answer. And depending on the question, the form of the prototype can be very surprising.

So, what’s a prototype for Tetris? You mean: something to figure out how the blocks mechanic works in practice? Get a friend to cut some shapes out of paper and start sliding them down a grid. It might not make for the best Tetris experience, but it takes about 15 minutes to get going, and it’s enough to start getting a feel for how the shapes work together.

The team for the game “Prince of Persia: Sands of Time” wanted to figure out how the acrobatics in the game would work. Their prototype was just a few animations of different moves, plus a bit of imagination.

Designing the gameplay for a new first-person shooter? Try flashlight tag. Designing the atmosphere? The prototype is also called “concept art.”

And for hardware? Nintendo showed us the difference between design and technological prototypes in 2005 when they unveiled the slick look of the Wii while having modified Gamecubes running behind their demo booths

It gets even more interesting once you leave the realm of games. Jeff Hawkins of Palm prototyped the user experience of the Palm Pilot by carrying around a block of wood in his shirt pocket. He would frequently take it out to “check his schedule” or “look up a contact.” Whenever someone suggested a new feature in a meeting, he would take it out and ask them where it would fit. Meanwhile, I told a friend at an assistive robotics startup, that, while their current project does serve the purpose of a technological prototype, he could build a prototype to test the value proposition much faster by simply going to his grandparents’ house and pretending to be a robot.

Prototypes and MVPs

Like everything else in Lean Startup, the idea of a “minimum viable product” has been passed around the Valley in a game of telephone until its meaning is perhaps less than that of the three words stuck together.

A minimum viable product is a very special kind of prototype, one that tests the two key factors behind a startup’s success, what Eric Ries calls the value hypothesis and the growth hypothesis. Typically, this constrains the MVP to more resemble the actual product, but not necessarily. In 2008, Dropbox hit a key milestone on the path to their MVP when they released a video demonstrating their product. Tens of thousands joined the waiting list. So actually, the minimum viable product was the video itself: they had already proven that lots of people (growth hypothesis) want what they’re building (value hypothesis).

Similarly, the MVP doesn’t need to work internally at all like the final product. Lean Startup contains a couple examples of this: the ingredient-delivery and meal-planning service “Food on the Table” started with the CEO making deliveries to one woman, and didn’t even try to add automation until forced to. Alice’s app may not be a technical prototype of anything other than the ability to send texts, but if she can do enough behind-the-curtain work to get real users and see how they respond, it’s enough for a perfectly fine MVP.

Unpacking the Confusion

Prototypes for design questions, engineering challenges, usability, market. Demos for users, investors, the press. Why do people seem to want to combine them all into one mythical “prototype?” To show they can build it? Surely they realize that, for a typical web app, the answer to “Can I make this?” is usually “Yes” if not “Yes, but why?” And why is it weird to prototype an RPG game’s combat system with pen and paper, when many of them are just digitized versions of physical predecessors?

I think it’s simply a case of a more general phenomenon. The best way to learn to play a song may first involve drills with nary a bar from the final piece. The charity that makes you feel great and does a lot of good may actually be two charities. When you learn to identify what things you want, it’s often best to get them separately. So let’s lay rest to the idea of a prototype app. Forget about about prototyping your product as a whole. Find the underlying questions, and answer them.


Thanks to Jonathan Paulson, Amy Quispe, Nancy Hua, Michael Poon, and Melody Guan for comments on earlier drafts of this post.

Liked this post?


Related Articles

1 comment: