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.

Use overridable variables in components

By using an overridable variable in your components you can have many instances of the component in your scene, but with different values for the same variable.

Put code inside components

Protopie code can get complex and hard to follow surprisingly quickly. Putting as much code as possible within your components can keep your main scenes simpler and cleaner.

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.

Origami Studio, Figma and others

How do these other popular platforms compare?

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.

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?

Use Variables

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

Use Components

It will often seem as though it will be faster to use individual elements than to use components, but in the end the time saving almost always goes the other way.

Use Variables

Origami Studio, Figma and others

Check if your other pie is present

Keep trigger and response names visible

Sending and receiving mismatched messages

Sending a message to another scene

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

info@peoplecentereddesign.org

© 2026 David Gilmore