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.

Distinctive initial variable values

It can sometimes be very helpful to use -99 and "null" for the initial values for your number and text variables.

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.

Use Variables

Variables are very powerful simplifying tool and they do not seem to have any impact on Protopie's performance.

Playing with time

A message sent to the current scene will be received by the object that sent it. But a message sent to Protopie Studio (Connect) will not be received by the pie that sent it. B ut what if there is nothing out there to respond to it?

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.

Working with Components

Check if your other pie is present

When building a connected system it can be valuable to know if the other pies are loaded into Connect or not – for examples so you don't get stuck waiting for a message that will never be sent.

Using the wrong mental model for Protopie

Most prototyping tools for designers use the frame-by-frame, or multiple dartboards model. But Protopie is much closer to a developer's object-oriented model of an application UI.

Rough, Rapid, Right

Put code inside components

The wrong variable type

Viewing variables within Components

Check if your other pie is present

Sending a message to another scene

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

info@peoplecentereddesign.org

© 2026 David Gilmore