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

Origami Studio, Figma and others

In the spirit of crafting the right prototype it is important to look at various UX prototyping tools so as to understand which tool might be best for the prototype you need at any one moment, for some given purpose.

With Protopie one of our first major uses of it was to to craft a prototype which put a collection of different software projects together as one single experience. This allowed our development teams to walk through it and gain a clearer idea of how their piece of the puzzle fitted into the bigger picture. This proved so successful that these walk-throughs became a regularly scheduled event.

If your purpose is to show a product manager quickly what a new screen or feature might lookalike, then Figma is probably a much more appropriate tool.

Origami Studio has the big advantage of being free and it is powerful in some very interesting ways. Its underlying mental model is much closer to Protopie than it is Adobe XD or Figma, but the programming concepts are not the easiest to grasp. I don’t see any way to run the same Origami prototype on two devices at the same time, but it does allow much more the user to craft their own experience rather than follow a script.

Other tools (Azure, UX Pin, for example) try to meet the need of bringing design closer to developers rather than closer to users – they can be used for user testing, but their strengths lie more in the linkage from design to development.

Viewing variables within Components

The variable debugger doesn't work when the variable that needs to be viewed is inside a component. There are two relatively easy ways to deal with this.

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.

Moving between Figma and Protopie

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.

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.

Receive and Assign hazard

Receiving a message, and then assigning a value and then writing a conditional based on that value is that something that is quite a normal, conceptual pattern – but in Protopie it will often not work as expected. This is because responses to Protopie triggers all happen simultaneously and not in the order written.

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.

Why use Protopie?

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

Put code inside components

Sending a message to another scene

Use Components

Moving between Figma and Protopie

Why use Protopie?

Check if Protopie Connect is present

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

info@peoplecentereddesign.org

© 2026 David Gilmore