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.

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).

Use Variables

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

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 Protopie Connect is present

If you are building a prototype that depends upon Protopie Connect then it is a good idea to start by checking if Connect is actually present.

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.

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.

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.

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.

Put code inside components

Check if your other pie is present

Use Variables

Sending a message to another scene

Use Components

Arrays and multiple parameters

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

info@peoplecentereddesign.org

© 2026 David Gilmore