I’ve also been doing lots of research into how the gaming industry and movie industry do rapid prototyping and idea validation, and noticing the similarities and differences between how they they do it, and how we do it.

Here are the 5 things that I learned from my research, and that I wish someone had told me about app prototyping 5 years ago:

1- Most prototypes SHOULD fail

The goal of prototyping is to find out what works, and what doesn’t, and to avoid the costs of executing what wouldn’t work.

You fail fast and cheap early, to avoid failing slowly and expensively.

If you’re prototyping only a few ideas that you “know” should succeed, then you’re either not coming up with enough ideas, or you’re too attached to a few ideas and you want to prove that they work.

On the other hand, if you’re prototyping lots of ideas, and most of them fail, you know that you’re exploring enough creative directions before settling on one.

And you will likely learn more from the prototypes that fail than from the ones that succeed.

2- You should pre-totype before you pro-totype

Movie directors and game designers probably use their imaginations much more than app designers. Before any scene is designed, they close their eyes and simulate the whole experience from beginning to end in their heads first. They then iterate on those scenes many times in their imagination, until they feel right, and only then, they start sketching, storyboarding, and prototyping.

Before you start prototyping any app, close your eyes for a few minutes, and imagine, as clearly as possible, each step of your app as you user interacts with it. Simulate the full user experience in your head first, and iterate on it as many times as needed until you know you’ve reached a point of user delight.

Only then, you should start prototyping.

And there should be no surprises when you’re creating the prototype, because you’ve already seen it all in your head, before you sat down to do it.

The more you pre-totype, the less you need to pro-totype.

3- Steal like a designer

Great ideas are built up on previous great ideas. Creativity doesn’t work in vacuum, and nothing is truly original.

I’ve written before about how I keep a design swipe file of app screens, to draw inspiration from when I am designing something new. I even created a collection of reusable screens based on the most popular app designs in Keynote and PowerPoint format.

My very first step after defining the idea I want to implement, is to gather as much inspiration from previous apps and experiences, and create various mood boards for layouts, interactions, specific features, color palettes,…

I then go through all those inspiration boards, and I start taking notes about what I like about every one of them.

By collecting and studying those inspirations, I am turning my brain into a melting pot with the best work that have already been done, and pointing it into specific creative directions to come up with similar ideas.

Make sure you’re gathering enough inspirations, otherwise you’d be plagiarizing, not stealing!

This lesson draws inspriation from Austin Kleon’s Steal Like An Artist.

4- Limit the time you spend on each prototype

Prototyping follows the 80/20 rule: 80% of the prototype required to validate an idea or answer a question is created in 20% of the time (often a week or less). Adding more time beyond that point often leads to diminishing returns on your time.

A polished prototype should never be your goal early on. Making lots of prototypes should be.

Once you feel your prototype is “good enough” to validate an idea or answer a question, stop, and make another one.

5- NEVER skip prototyping

It’s easy, especially when you’ve done something many times, to believe that you already know the outcome of a specific step, and to skip it. Because I’ve already prototyped lots of apps, sometimes I believe that I have a clear idea in my head about how the app should be designed, and skip prototyping to start production right away.

Oftentimes, I am wrong.

It doesn’t matter how many apps you’ve already prototyped, you should never skip prototyping your future ideas.

Prototyping isn’t just about testing how an idea works, it’s also about figuring out what the REAL idea is.

The first idea in your head is likely a messenger, pointing the way a much better idea that you can only reach through prototyping and iterations.

And sometimes you need to shoot the messenger, to reach the king.

You then share those requirement documents with your team, have discussions about them, and based on their feedback and comments, you go back and modify some parts of the design, take new screenshots, paste them in place of the old ones, and rewrite the corresponding parts of the documents to reflect those new changes.

And you rinse and repeat until everyone signs off on those requirements, or until you realize it’s actually easy for an angry fist to punch through an LCD monitor.

That workflow accurately describes how I spent 50% of my time working as a product manager at Microsoft 10 years ago.

It was agonizing!

And I used to think that there was no way around it, until I left in 2007 and started consulting with startups and creating my own products.

That’s when I realized that I could create product requirements 10x faster 100% more enjoyably.

How did I do it?

I replaced requirement documents with videos!