Skip to content

UX Prototyping & Protopie

  • Principles
    • Educational
    • Figma Integration
  • Patterns, Pitfalls, Ploys
    • Patterns
    • Pitfalls
    • Ploys
  • More …
    • People-Centered Design
    • Thinking about AI
  • Principles
    • Educational
    • Figma Integration
  • Patterns, Pitfalls, Ploys
    • Patterns
    • Pitfalls
    • Ploys
  • More …
    • People-Centered Design
    • Thinking about AI

Moving between Figma and Protopie

Figma and Protopie are different

Figma is a UI visual design tool that enables you to demonstrate your output as a prototype, whereas Protopie is a prototyping (programming) tool that can make things that look very real.

Whereas Figma requires the user to draw out all versions of the UI in tight detail before the prototype can be put together, Protopie lets you (expects you to) start with programming the behaviours in the UI.

When you import Figma elements into Protopie it is great to get all the rich visual detail that Figma encourages. but it also means (in most cases) that you have imported vastly more than is actually needed. In Protopie you don’t need to draw every version of a component … instead you just need to ensure that you have all the required elements whose size, shape, colour, visibility, etc can then all be programmed as needed to produce all your Figma variants.

Likewise whereas in Figma you need a different frame for every screen that is visually different (and all frames must be drawn out), in Protopie a scene is often best used for a single coherent piece of functionality. A single scene in ProtoPie might include numerous scenes in Figma.

Furthermore, autolayout in Figma means that graphical elements that may not be functionally related are often clustered into one container (component) in order to take advantage of auto layout.  But in Protopie you want to group together things that are functionally related.

Sending and receiving mismatched messages

You can send messages in different ways, but Protopie requires you to receive them in the matching way. A common (and easy) mistake is to send a message to a 'parent' while wanting to receive it from the current scene.

Origami Studio, Figma and others

How do these other popular platforms compare?

The wrong variable type

This pitfall is not a big deal, but it can waste you time as you try to track down why your variable seems to have the wrong value (or no value). It can also bite you in a formula where your variable is of the wrong type for the formula.

Why use Protopie?

There are many prototyping tools out there, so what makes Protopie special – how is it different?

Working with Components

Sending a message to another scene

This is a very easy mistake to make – sending a message to be picked up by a component, but one that you have in fact placed into a different scene. Although you can send to a different pie, you can't send to a different scene.

Keep trigger and response names visible

It is very important to annotate your code with what it is actually doing, but keeping the trigger and response names helps someone new to the project (or you in three month's time.

Sending messages to two places

Whilst it is important to be careful in sending messages to the right places, it is also very powerful to send a message to two different places at the same time (or maybe with a small delay).

Keep trigger and response names visible

Good Prototyping Practice

Use Variables

parseJson gives no error message

Use Components

Viewing variables within Components

  • Welcome
  • What’s New?
  • About
  • Welcome
  • What’s New?
  • About

info@peoplecentereddesign.org

© 2026 David Gilmore