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

Good Prototyping Practice

The inherent contradiction ...

IDEO’s 3R prototyping principles from the late 1990s still apply – “Right, Rough, Rapid” but in the UX and UI space they are easily misunderstood.

My experience, over many years, is that there is an inherent contradiction in these 3Rs. To get something Right seems to exclude being Rough. And Rapid always seems like a challenge.

The first part go good practice is to understand that Right does not the right and final design – rather it refers to the idea that a prototype should be Right for its intended purpose.

Many people use artboard-based prototyping tools very successfully because their primary purpose is to show a colleague what the UI looks like and how it behaves. But such an approach breaks down if one’s purpose is user testing.

Right for user testing requires something that may not be visually perfect, but which enables the user to see the whole promise and explore it in context.

One may also need a prototype to be Right in terms of implementation and to help people explore the speed at which interactions need to happen.

Why Protopie?

My enthusiasm for Protopie stems from the user testing aspect – most of my content here assumes that we are building prototypes to help get better feedback from users. In the context of healthcare apps for clinical use, this means enabling users to collaborate with each other as they would in real work, instead of asking them to look at their UI without anyone else involved.

Also, Protopie’s components and libraries enable one to move Rapidly without building things from scratch. And they also enable one to move gradually from very Rough to very refined – focussing on interactions and experience first and visual details later.

Moving between Figma and Protopie

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.

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.

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.

Rough, Rapid, Right

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.

Origami Studio, Figma and others

How do these other popular platforms compare?

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.

parseJson gives no error message

Receive and Assign hazard

Sending and receiving mismatched messages

Keep trigger and response names visible

Rough, Rapid, Right

Distinctive initial variable values

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

info@peoplecentereddesign.org

© 2026 David Gilmore