What is an interactive prototype?

In the book 'Design Engineering Handbook' a nice description of an interactive prototype is provided:

"Finally, there is the interactive prototype, which simulates the end experience. Interactive prototypes are built in code and incorporate mock or production data. Their purpose is to solidify the interaction design, validate solutions, and uncover any edge cases that the other methods might not catch."

Interactive prototypes are built in code and use a mix of dummy content and real content. An interactive prototype tries to resemble the actual end product as closely as possible. That means it doesn't necessarily have to work technically, but it should feel like the user is already testing the end product. For example, it should be possible to fill out a form, even if the results are not yet saved in a database.

The benefits of an interactive prototype

“A prototype is worth a thousand meetings.”

This is the saying at IDEO, the globally renowned design and consulting firm. Explaining how something should work in text or even with pictures is challenging. There are often misunderstandings, such as what someone means by a header, hero, a list, or a menu. And what exactly happens when a user clicks somewhere? Many of these uncertainties are resolved when an interactive prototype is created. It immediately shows how (and if) something works.

Therefore, at IDEO, they ensure they enter the prototype phase as quickly as possible. As Scott Belsky describes in his book 'Making Ideas Happen':

"When team members have an idea for how something might look or function, they’ll simply have a prototype built and start tinkering—despite what stage of the design process they are in. IDEO’s rapid prototyping practices are part of a clever strategy to overcome some of the biggest boundaries to making ideas happen."

By starting to build prototypes in the early stages, you can overcome certain roadblocks that you can debate for a long time. By designing and building prototypes quickly and iteratively, you address problems in the early stages that are easier and cheaper to solve at that point in the process.

This is also endorsed by David Heimeier Hansson, co-founder of the successful company 37 Signals:

"But we don’t do the bulk of our design work with or in Figma when developing Basecamp or HEY for the web. That’s all done directly in HTML and CSS, as it should be. Because no matter how good Figma is, it’s an intermediary abstraction, like Photoshop before it. If you’re working with the web, you’ll work faster without such an abstraction layer in the design process filtering the collaboration between programmer and designer."

Figma (or Sketch, Adobe XD, or Photoshop) is a useful design tool for creating sketches. But ultimately, it is an extra layer of abstraction between the user and the end product. Robin Rendle makes a similar argument when he suggests that Figma is not your final product, and therefore, it's less important how something looks in Figma:

"But Figma will always be out of sync with the front-​end, and that’s okay. We have to pick and choose which parts of the front-​end we should make a mirror-​image of. Do we need all the form styles? Nah, just what most designers need each day to get their work done. The hard truth is this; your Figma docs should be treated like a sketch on the back of a napkin."

Everything you do in Figma is to quickly explore something. It doesn't need to be a 1-to-1 match with the actual end product. For that, you have the interactive prototype, as Shasmi Brinn points out:

"The biggest benefit is that a functional prototype speaks everyone’s language: engineers, designers, end users, everyone, we all understand web functions presented in a browser. It taps into mental models we all already share. And if the team is confused by the prototype, well, that is critical user feedback right away!"

When you create and use an interactive prototype, everyone speaks the same language because we are now used to how websites and web applications work. An interactive prototype immediately resonates with designers, users, and developers. It, therefore, promotes more synergy between designers and developers. The transition from design to development is smoother, better, and faster.

How to create an interactive prototype?

This can be done in various ways, but when it comes to websites or web applications, the foundation should always be HTML and CSS because it comes closest to the final product. Assuming this, there are multiple options.

For example, I know of a government agency where designers exclusively create prototypes in HTML and CSS. Components are used directly from their Design System.

I create demo pages in a Storybook environment myself. Storybook is an open-source application that allows you to show what a component, like a button, should look like. You can immediately view the code and adjust arguments to generate different variants. This is ideal for developers who want to work with your Design System.

Creating demo pages in Storybook has the advantage that I can use the available components directly and fill any 'gaps' with HTML and CSS code. Having said that, I am quite experienced with HTML and CSS, so this is not a big problem for me.

However, this is not suitable for every designer. For less technically inclined designers, there are intermediate solutions like UXPin. You can integrate UXPin with a Storybook or Github environment, allowing you to load real (HTML and CSS) components. These components can be used in a prototype with a Graphical User Interface (GUI), as you are accustomed to from Figma or Sketch. It's also possible to build certain logic, such as conditions. For example, if the user chooses Option A, then show form field X.

But can't you create a prototype with Figma, Sketch, Penpot, Adobe XD?

This is partly true. With programs like Figma, you can create a flow that allows you to place images in the correct order depending on which part the user clicks. But they are still images. It's a step away from a realistic end product, namely a website or application built with HTML and CSS.

Also, Figma uses its own way to display fonts on a screen. This is not the same as a browser like Chrome, Firefox, or Edge, which makes it less similar to the end product.

Your experiences with interactive prototypes.

I'm curious about your experiences. Are you a designer who also builds interactive prototypes, or are you a designer who wouldn't touch code for anything? Let me know by leaving a comment below.