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.

Why use Protopie?

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

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.

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

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.

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.

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.

Origami Studio, Figma and others

How do these other popular platforms compare?

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.

How to inspect variables inside a component

Sending messages to two places

Use Variables

The wrong variable type

Origami Studio, Figma and others

Why use Protopie?

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

info@peoplecentereddesign.org

© 2026 David Gilmore