A Primer on UX Prototyping, Part 2: The 3 Kinds of Prototypes

There are three kinds of UX prototypes: clickable, front-end, and full stack. Each one serves a different purpose, requires a different level of investment, and gives you a different quality of insight. Picking the right one depends on where you are in the design process, what you need to learn, and how much time and budget you have to work with.

In Part 1 of this series, we covered what prototypes are and why they matter. Now let's get into the three kinds so you can pick the best one for your project.

Think of prototype types like recipes. They each have their own ingredients, but they often complement or build on one another. And just like recipes, it's essential to pick the right one for the right situation. You wouldn't serve caviar at a last-minute backyard BBQ, and you wouldn't throw together a bag of chips for a dinner party with close friends. The same logic applies when you're deciding which prototype to build.

What Are the 3 Kinds of UX Prototypes?

The three kinds of UX prototypes are:

1. Clickable prototype -- a low-fidelity mockup users can click through to experience basic functionality
2. Front-end prototype -- a coded, higher-fidelity prototype that shows dynamic features using placeholder data
3. Full stack prototype -- a fully functional product from the user's perspective, with intentional technical limitations that prevent it from scaling

What Is a Clickable Prototype?

A clickable prototype is a mockup that allows users to click through the design and see some of the product's basic functionality, though not all of it.

When should you use a clickable prototype?

Use a clickable prototype when you've already validated the problem or challenge at hand and you want to quickly test whether one or multiple solutions will solve it. Most product designers reach for a clickable prototype when they want to see how users respond to their idea before spending serious time and resources building the real thing, or when they want to test multiple concepts without building full-fledged versions of each one.

What are the pros and cons of a clickable prototype?

Primary pro: Clickable prototypes require the least amount of time and budget to create.

Primary cons:

• The functionality is limited, so the feedback and insights your team receives may be limited too. Since you won't be able to see the user's entire experience, you may see different results once they use the real product.
• Clickable prototypes are lower fidelity (less refined) and more conceptual, which can make it difficult for a user or stakeholder to understand how the full-featured product will look and work.

Time needed: As little as a few days, up to 1-2 weeks

What tools and roles do you need for a clickable prototype?

Helpful tools:

• InVision (InVision also released a prototyping tool that integrates with Sketch called Craft)
• Axure
• Proto.io
• Adobe Experience Design CC

Roles required:

• An information architect to map out all the data and core interactions you want to display
• A UX designer to design how those interactions will flow together and create wireframes for each screen
• A visual designer (optional) to add colour, typography, and other design elements that establish the product's look and feel
• A team member to set up the finished design in a UX prototyping tool -- this task doesn't usually require a special skill set, so anyone involved in the project can do it

Remember that a prototype is a temporary learning tool. Invest enough resources to draw meaningful conclusions and gain buy-in, but not so much that you feel reluctant to abandon it if you decide to go in another direction.

What's the secret ingredient for a successful clickable prototype?

Pair sketching. It's a collaborative design approach that brings together at least two stakeholders (designer + another designer, developer, user, subject matter expert, client, or other stakeholder) to join forces on a product sketch. It helps the team share knowledge, gather more ideas, and iterate quickly to find the best solution.

What Is a Front-End Prototype?

A front-end prototype is a more robust prototype built with code so it actually functions and shows you how users interact with some of your product's more dynamic features. It uses placeholder data instead of real data.

When should you use a front-end prototype?

Use a front-end prototype when you've already tested a clickable prototype and you're ready to take the next step, or if you have more time and resources to invest in an initial prototype.

What are the pros and cons of a front-end prototype?

Primary pros:

• The low-fidelity nature of a clickable prototype often means users need guidance to understand how to use it, or they try to interact with features that don't exist. With a front-end prototype, they can be more independent and explorative. That gives researchers and designers far more interesting information because they can see how people will actually use the product on their own.
• This prototype also feels more real, as it could be the final presentation-layer code that will be used when the product ships.

Primary cons:

• A front-end prototype is built with code, so it takes more time and budget to create.
• Because the prototype is more realistic and requires more resources to create, it's easy to get attached to the solution, which can make it harder to evaluate its effectiveness objectively.

Time needed: About 4-6 weeks

What tools and roles do you need for a front-end prototype?

Helpful tools:

Front-end frameworks are useful for rapid development because they provide boilerplate elements that can be repeated throughout the prototype, such as simple URL structures, headers, footers, buttons, etc. Look for a front-end, opinionated framework that takes a stance on how certain elements should be handled and provides default options that will save you time and effort. Some favourites include:

• Angular 1 and 2
• Ember
• Bootstrap
• Foundation
• jQuery

Roles required:

• An information architect to map out all the data and core interactions you want to display
• A UX designer to design how those interactions will flow together and create wireframes for each screen
• A visual designer (optional) to add colour, typography, and other design elements that establish the product's look and feel
• A front-end developer to code the visual mockup into an HTML/CSS site or app that users can see and interact with (Note: this person doesn't need to specialise in JavaScript, because it's not necessary to fully develop the interactive functionality of your product during the prototyping phase)

What's the secret ingredient for a successful front-end prototype?

Let go of the perfectionist mindset and focus on fast insights. Your main goal is to learn quickly, so when it comes to UX prototyping, shortcuts are ok. Your code can be messy, your design doesn't need to be perfect, and the interactions don't have to be fully fleshed out. Everything just needs to work well enough for users to prove or disprove your hypothesis.

What Is a Full Stack Prototype?

A full stack prototype is a fully coded and functional product from a user's perspective. However, behind the scenes it still has some technical limitations that purposely prevent it from scaling into a full-fledged product.

When should you use a full stack prototype?

Use a full stack prototype when you have enough data to support your hypothesis or validate the challenge at hand, and you're ready to invest significant time and budget into testing it.

What are the pros and cons of a full stack prototype?

Primary pros:

With other kinds of prototypes, researchers and designers must rely on user feedback (what people say) to figure out if their solution is effective. They can gauge "idle interest," but it's impossible to know how users would actually act. With a full stack prototype, you can see real user behaviour (what people actually do) and assess whether they're truly getting value from your product because they can interact with it as they would in real life. No guessing. No interpreting. Just watching.

Primary cons:

• You're betting a lot of time and budget that your proposed solution will be effective. If you're wrong, you will have wasted a significant amount of resources.
• A full stack prototype has more working features than a clickable or front-end prototype, so you have to define a lot of the edge cases and nuances of the product ahead of time and build things in a way that makes them harder to change later on.

Time needed: About 2-3 months

What tools and roles do you need for a full stack prototype?

Helpful tools:

You can build your full stack prototype using the same coding language and tools you would use to build the final product, or leverage tools that provide greater scalability, reliability, and speed, such as:

• Heroku for easy hosting and deployments
• Ruby on Rails for a full-stack framework
• GitHub for code sharing and collaboration

Roles required:

• An information architect to map out all the data and core interactions you want to display
• A UX designer to design how those interactions will flow together and create wireframes for each screen
• A visual designer (optional) to add colour, typography, and other design elements that establish the product's look and feel
• A front-end developer to code the visual mockup into an HTML/CSS site or app that users can see and interact with, AND a back-end developer who can make the product work and integrate it with other databases and systems, OR a full stack developer who can handle both tasks

What's the secret ingredient for a successful full stack prototype?

Two things: forgo automation and secondary features, and avoid premature optimisation.

Forgo automation and secondary features

Taking a manual, minimalistic approach lets you test your hypothesis as quickly and inexpensively as possible, while still gauging usability and interest in your product.

For example, instead of automating features in your full stack prototype, consider ways your team could complete the process manually behind the scenes while making it seem automated to your users. Many products pull in a bunch of data, analyse it, and deliver reports to their users. Ideally, this process would be automated. But does it have to be in your prototype? Nope. Instead, you could have the user import or add their data, then show them a screen that says, "Your report will arrive in your inbox in the next 12 hours." It seems like magic is happening behind the scenes, when in reality your team could be manually completing the process on the back end.

The same thinking applies to secondary features. If your product delivers a PDF to its users, you could add a button to the prototype that says "Download PDF" and see how many people click it. When they click, a message could appear that says, "We're currently working on this feature and will contact you when it's available." That way, you can test how much interest there is in the feature without spending time and budget developing it now.

Avoid premature optimisation

Many developers naturally look for ways to optimise their code to make it faster, more scalable, and better overall. Normally, that's a desirable quality. But during the prototyping phase, it actually causes more problems than it solves. Premature optimisation slows down the process, makes the product harder to change later, and increases the likelihood that you'll feel more attached to the proposed solution.

Although it feels counterintuitive, don't try to solve problems that don't exist yet. Don't waste time prototyping less important features that won't add value for your users or existing features you can simply replicate. Don't make the code or design any fancier than it needs to be. With each task, ask yourself, "Will this work help us test our hypothesis quickly?" If the answer is no, move on and invest your time elsewhere.

Let's Get Cooking

Like a chef looking through their favourite cookbook, product designers have several options to choose from as they begin prototyping. Picking the right recipe depends on your situation, goals, resources, and time.

No matter which kind you decide is most appropriate for your project, think like a chef and treat prototyping as the test run before you make the final product. It may turn out perfectly and give you more confidence when you start cooking for real guests. Or, you might notice that the recipe needs a little more of one spice, a little less of another, or a completely different approach altogether. Either way, the exercise is invaluable for cooking up success.

If you're looking for advice or help with UX prototyping, let's chat. Whether you want to validate a concept, get buy-in, or take the first step toward making your idea come to life, we can help you navigate the process and uncover the insights you need to move forward.

Frequently Asked Questions

What is the difference between a clickable prototype and a front-end prototype? A clickable prototype is a low-fidelity mockup that lets users click through a design to see basic functionality. It requires no code. A front-end prototype is built with code and shows more dynamic, realistic interactions, but still uses placeholder data instead of real data.

How do I know which type of UX prototype to use? Start with a clickable prototype if you're in early-stage concept testing and want fast, cheap answers. Move to a front-end prototype if you need to test more dynamic interactions and have more time to invest. Use a full stack prototype only when you have strong evidence to support your hypothesis and you're ready to commit significant time and budget.

How long does it take to build a UX prototype? A clickable prototype can take as little as a few days up to two weeks. A front-end prototype typically takes about four to six weeks. A full stack prototype usually takes two to three months.

Do you need a developer to build a UX prototype? For a clickable prototype, no. Tools like InVision, Axure, and Proto.io let designers