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.

Moving between Figma and Protopie

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.

How to inspect variables inside a component

Even all-Scenes variables are not accessible inside a component. And this can lead to hard to find errors when a variable with the same name is used in a component, but its value is not sync'd with the scenes.

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.

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.

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.

Working with Components

Playing with time

Use Variables

Origami Studio, Figma and others

Why use Protopie?

How to inspect variables inside a component

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

info@peoplecentereddesign.org

© 2026 David Gilmore