Prototypes Are Disposable

During product discovery, we create prototypes to answer questions. Questions like: what size should the product be to fit nicely into our target user’s grip? Should our shopping cart software split the checkout process into multiple pages? Would our users find value in a version of our app ported to Android tablets?

Since the goal is to answer questions, we build prototypes as quickly and cheaply as possible. A prototype is not a carefully-engineered artifact, meant to stand the test of time. Instead, prototypes are disposable, to be thrown away once their purpose has been fulfilled.

Throw away failures and successes #

A completed prototype might be considered a failure (or “falsified”) for any number of reasons. The designer may feel that the design is not sufficiently useable and doesn’t see any obvious tweaks to improve it. The engineer got it working using metaphorical duct tape and bailing wire, but doesn’t see a technical approach workable over the long term. Or, most commonly, a user test reveals that users can’t understand the prototype, or shrug their shoulders when asked whether they would use it or buy it.

All of these cases mean our prototype has reached a dead end. Such falsified prototypes are discarded, and we go back to the drawing board with more understanding of the problem space, the technology, and our users’ needs.

But less obvious is why we discard successful prototypes. (By “successful” I mean “validated,” a topic for a future post.) Here’s why even successful prototypes are disposable.

The successful prototype, like all our other prototypes, was built fast and cheap. It was never engineered for use on a large scale. If it’s a mobile app prototype, it was probably made only to work on one phone device, screen size, an OS version. If it’s a web app prototype, it probably hasn’t had any attention given to database performance, security, or test coverage. If it’s a physical product, the prototype may be 3D printed but the finished product needs to be mass-produced via injection molding.

The destiny for a validated prototype is to become a template, a working specification used to build the finished product. (I’ll explain this part of the process in a future post.)

Once we cut free of the expectation that a prototype should be engineered like a finished product, we have far more freedom and speed during the prototyping process. Being able to build faster and cheaper means testing more ideas, which means a better end product.

Real-world example: Tetryon #

Tetryon is an iPhone game created by Miranda Collins and me in 2009. Our goal was to create a simple but challenging puzzle/strategy game inspired by classic board games like Go and Chess, and video games like Tetris and Klax.

One early prototype we created was intended to answer the question: how big do the game pieces need to be in order to make them easy and fun to “grab” with your finger? Bigger would make them easier to grab, but smaller would allow for more pieces onscreen and therefore more interesting gameplay.

We created a tiny prototype using a playfield of a grid of lines, and a sprite borrowed from another game as a game piece. I got the prototype running on my phone and we were able to try the sprite at different sizes to see which one felt best.

This disposable prototype did need to be real enough to run on the target device, but it didn’t need to look good, have game mechanics, or do anything other than let you drag around the game piece. It didn’t even need to run on anyone’s phone other than mine. This was a fast, cheap way we could answer the question about game piece size, and required only a few hours of work.

We spent months and hundreds of iterations on another disposable prototype designed to answer a different set of quetsions. Written in Python, this prototype ran on a desktop computer with a game window exactly the size of the iPhone screen. Python is a higher-level programming language, and one I was more familiar with. This allowed us to iterate on ideas much faster than the iOS’s native language, Objective C.

(left) Early prototype written in Python running on a desktop computer. (right) The finished game running on an iPhone.

We used the Python prototype to explore the art style, build out the game mechanics, and have our friends playtest the game. We answered questions like: Which of our ideas for game mechanics are the most fun? Can users figure out the mechanics via trial and error, or should we spell everything out in the tutorials? How quickly should the difficulty level ramp up on early levels to keep players engaged, and not bored or frustrated? These questions required a high-fidelity prototype, but it did not require that it run on our target device.

Once we had locked in most of the gameplay and art with the prototype, we transitioned out of product discovery and into building the finished product. We used the Python prototype as working specification to create a brand new codebase in Objective C on the iOS platform. This from-scratch rewrite took about two weeks, and afterward we discarded the Python codebase.

Prototypes are not products #

In software, late-stage prototypes often look very real. This is great for testing our hypotheses, but it creates a pitfall: our product development team and other stakeholders can mistake a prototype for a finished product. “Great,” says the boss, seeing a demo of your high-fidelity, fully-functional prototype operating against production data. “Let’s ship it next week!”

No matter how real it looks, the prototype exists to answer a question. It was never intended for, or engineered for, wide use. For a company with a large existing userbase, trying to launch a prototype usually results in public failure. The engineering team will be forced to rebuild the prototype as a production-ready product under unreasonable time pressure, and the customer service team will be forced into damage control.

Brand-new startups can launch prototypes as if they were finished products, because they have no existing users. Even in this case, though, I recommend using a method for metering incoming users, such as invite-only private alpha, or a signup / waiting list beta.

Conclusion #

Let go of the expectation that prototypes need to be designed and engineered at the level of a finished product. It will allow your team to iterate more quickly toward finding a truly great product opportunity. Build each prototype fast and cheap, and plan to throw it away when its purpose has been fulfilled.