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

Rough, Rapid, Right

A key principle for all protoyping in product design is to be rough, rapid and right.

Rough means not to build anymore than is necessary for the current purpose.

Rapid means moving fast and being prepared to throw the prototype away quickly, once it has achieved its purpose.

Right means ensuring that the rough prototype rapidly built is capable of addressing the unknowns and answering the critical question.

Some purposes of prototyping

  1. Seeing how much can be fitted onto a screen and still be comfortably legible.
  2. Exploring whether users interpret the various interactive elements appropriately.
  3. Demonstrate that a flow (through the application) works and makes sense.
  4. Providing colleagues with an understanding of what ‘Done’ might look and feel like.
  5. Investigating whether users can navigate through the flow and complete their tasks.
  6. Enabling customers to see what new features might really mean in their day-to-day usage.

 

Whichever of these (or numerous other)purposes fits your reasons for building a prototype, this should guide you in terms of what rough, rapid and right might mean for you and this should lead you to see what tool is most appropriate.

Use Variables

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

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.

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.

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.

Origami Studio, Figma and others

How do these other popular platforms compare?

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.

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.

Moving between Figma and Protopie

Origami Studio, Figma and others

Check if Protopie Connect is present

Viewing variables within Components

Playing with time

Why use Protopie?

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

info@peoplecentereddesign.org

© 2026 David Gilmore