One of my favorite stories about prototyping comes from James Dyson’s auto-biography “Against the odds”. When Dyson became frustrated with his Hoover vacuum, he got the idea of using a cyclonic filter to replace the bag. Late night in his kitchen, he created a prototype using an old vacuum cleaner, cardboard and duct tape. The new filter sucked the dirt from the floor and pushed into the air. The prototype “worked”!

5,126 prototypes later, Dyson had the perfect vacuum.

What Dyson did was inspiring because he assembled a proof of concept quickly, without getting distracted by the detail. He didn’t think about how to collect the dust, how the vacuum would move, or whether a hose connection will work. He wanted to answer one question: “will it pick up dust?”

I receive at least one email a week asking if live data can be used to prototype with Keynotopia, and my answer always is “Why do you need live data?”.

By definition, a prototype is an early “fake” version of your product, and in my experience, fake data always does the job. If you need to show a list of friends, create a random list of names and faces. If you are retrieving a collection of popular dishes, copy the top 10 dishes from your favorite recipe site. And if you already have an API that pulls in live data, do a couple of API calls and hardcode the results into your prototype.

I’ve created dozens of prototypes over the past couple of years, and I’ve always found it possible to do without live data, at least in the idea validation stage.

I think of prototyping as magic: the goal is to create the illusion, and if the illusion works, why waste so much time figuring out how to actually pull a large rabbit out of a small hat?

My prototyping mantra is to first get it done, then get it right. The momentum of having the first prototype soon propels you to create more and better prototypes. Later on, integrate live data when you start coding. But don’t get distracted by the detail too early.