Learn the right way to prototype

Prototype one feature at a time

Keep things focused. You don't want to prototype your whole product immediately. You want to prototype parts of it and test them individually. Test if the signup flow is easy to follow, if the checkout process is simple enough and if the landing page is easy to understand. All these should be separate prototypes.

This is not a strict rule but a guideline to follow. Don't feel you have to prototype everything. When you design you should focus on 1-2 problems to solve, otherwise you will probably get lost.

Start by picking one or more user goals/tasks you want to create a solution for and test.

For example:

  • Create a landing page to communicate how the product works
  • Create a signup flow for people to register
  • Create a checkout flow for people to pay for the product

Don't be afraid to be dirty


"How mature and real should my prototype look like?"

This is the question every beginner struggles with. I also struggled with it for a long-time but the answer was simple:

"There is no right or wrong. It only depends on what you want to test and validate."

Below I describe the two most common scenarios you will have to deal with.

Are you redesigning or building a product from scratch?

Then you should better keep it hacky and dirty. Dirty because your worst enemy at this point is perfection. You shouldn't care if your design is pixel perfect or if it looks beautiful. This is for later. What you should care about at this point, is if the user flow is easy to follow, and if the screen content and layout are easy to interpret from users.

By keeping your prototype dirty, you can move fast, tweak things and stay focused on defining the solution. Here is an example prototype a fellow indie maker I help created.


You can interact with the prototype below by clicking on its buttons.

Same happens if you are trying to create a website like a landing page not just an app. At first you want to focus on the content and only the content. You don't care about the colours or the animations. You want to test and validate if the way you describe your product is good and clear enough. Once you get this right you will proceed to the visual details.

Are focused on making visual improvements or evolving a dirty prototype you've made?

In this case you can jump into the code and just design things in code because it could be actually faster this way. At this point you have tested and already know how the user flow will be like, what content, interactions and layout your screen will have and its just about making it look visually better and more mature. If you prefer doing it in Framer though it's also fine. Both ways work.

Here is an example of a mature prototype in Framer.


You can interact with the prototype below by clicking on the to-do items.

Don't try to be proud of your prototypes. Instead share them as early as possible.


When we create "dirty" prototypes (aka low-fidelity) most of the times we feel a bit ashamed of them. We know that they are not "finalized" or "ready" and we struggle with sharing them with other people.

Be aware that this is a mental trap. It's all about reminding yourself that you are not testing the visual beauty of your prototype. You test the content, the user flow and the overall approach. It's just a matter of staying focused on what matters. The less things you design, the faster you move.

Don't replicate the production experience


When I was introduced to prototyping this was the biggest mistake I did. I was trying to replicate everything the production app had in order to make my prototype look as real as possible.

I wanted all the UI elements in the screen to be clickable, and pixel-perfect and the data to be fetched from the API. I wanted to follow all the design guidelines and I was trying to achieve perfection. And I failed big time.

Perfection is the enemy of prototyping.

Make real only what needs to be real and forget about the rest. Your prototypes have to be dirty and not look for perfection. This is a feature not a bug. This is what allows you to move fast.

Don't maintain your prototypes unless if it's absolutely necessary

I've heard from some fellow indie makers that they design in code instead of using a design tool cause they don't want to maintain design files and waste time. They are right and I had the exact same issue in the past.

I used to think of my prototypes as something that I have to maintain and update as I update my product. To keep my prototypes up-to-date with what's on production.

But truth is that we don't need to. Prototypes are sketches. What do you do with sketches? You grab a paper, you sketch something, you take notes and once you do your job you throw in in the trash. That's what you should do with your prototypes as well most of the times! Don't care about maintaining them or making them look too real. They are just a sketch in your process.

The only source of truth is the product on production and that's the only thing you need to maintain!