Sometimes pen and paper are all you need to create and test a prototype design. But as new prototyping tools have emerged, UX designers can spin up an interactive digital prototype fairly easily.

So, what prototype formats are there, and what are the pros and cons of each? Let’s find out.

Paper prototypes

A paper prototype is what it sounds like – a prototype sketched or printed on a piece of paper.

They’re the simplest version of a prototype and can be helpful during early stage concepts to visualize and test multiple ideas quickly.

Pros:

• Quick and simple to create. 

• Low-lift. Creating a paper prototype doesn’t require any special tools or skills – if you can sketch, you can create a paper prototype.

Cons:

• If you decide to test using a paper prototype, it requires more imagination from your participants. You might have to explain ideas to participants interacting with the prototype.

• You can only test paper prototypes in person, which limits your pool of testers.

Digital prototypes

A digital prototype builds an interactive experience. They’re used during the visual design phase, when you have mockups with colors, fonts, etc. as well as realistic copy, and want to see how your design works in action.

Pros:

• Realistic and shows what the final product will look like.

• Users can interact with the prototype themselves, which gives you more flexibility to run a remote or unmoderated test.

Cons:

• Digital prototypes require a design tool, like Figma or Sketch.

Native prototypes

A native prototype involves coding a model of your app or website. This typically happens near the end of the product design process, after the visual design is ready but before development starts.

Pros:

• Native prototypes look and work like a real product, and participants can test using real devices.

• They’re good for usability testing. Participants can’t tell the difference between a native prototype and a real app or website, so native prototyping allows you to understand a realistic experience and gain useful feedback. 

Cons:

• It takes time to create a native prototype.

• It requires coding skills. You need to know a programming language or involve a developer.

When should you test your prototypes?

Deciding when to test your prototype depends on several factors, like time, budget, resources, and the product or feature you’re designing.

The word prototype might suggest a model of the finished product, but in reality, they don’t need to be perfect. In fact, there are different levels of fidelity.

If you’re in the early stages of the design process, you might create a low- or medium-fidelity prototype. If you’re nearer to the end of this process, you might opt for something with higher fidelity. Fidelity is the level of reality that your prototype has.

Let’s explore these different levels of fidelity in more detail.

Low- and medium-fidelity prototypes

The earlier you can test your prototypes, the better. Low-fidelity prototype testing happens in the earlier stages of the design process with a paper or digital prototype. Use them to generate and share feedback and ideas with stakeholders so you can quickly iterate your designs.

What are you testing at this stage?

• Whether the layout makes sense to your users.

• Experiments in your initial designs.

• The information architecture.

• Basic interactions with the design.

As you take user feedback onboard and improve your design, retest new prototypes using a medium-fidelity prototype. At this stage, you can also add copy.

High-fidelity prototypes

Once you’ve tested and taken in user feedback on your low- and medium-fidelity prototypes, you can move onto creating a high-fidelity prototype. 

This is interactive and closely resembles the final product.

At this stage, you shouldn’t expect huge problems to emerge. Use a high-fidelity prototype as a last step in your design testing process to validate your final design and uncover any hidden usability issues before handing over to the development team.

What are you testing at this stage?

• The overall design direction.

• The copy, menu links, and information architecture.

• User flows: Can users find their way when completing a task?

• UI components, e.g. drop-down menus, pop-ups.

• Graphic and visual elements, e.g. image quality, text readability.

Live data prototypes

A live data prototype uses data or APIs to create dynamic experiences. It’s much like the final product, so you might use it if you wanted to test software solutions in real-life environments and conditions.

Building a live data prototype is more involved than a low- or high-fidelity prototype, as you’ll need a developer. But it can be a useful way to learn how your product performs with users in the wild and generate data about how the final product will work. And if the test goes well, you’re already on your way to production-quality software.

Feasibility prototypes

A feasibility prototype focuses on a key feature, technology, or component of the product. You might opt for this type of prototype if you wanted to test something considered high-risk, like a specific feature innovation.

The aim with a feasibility prototype is to establish evidence that the feature, technology, or component will work. You might use it in the early stages of the development process in order to assess and reduce future risks.