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.

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.

parseJson gives no error message

parseJson is.a very useful and powerful function, but it doesn't do all you might expect of it (yet, hopefully).

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.

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.

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

Sending and receiving mismatched messages

You can send messages in different ways, but Protopie requires you to receive them in the matching way. A common (and easy) mistake is to send a message to a 'parent' while wanting to receive it from the current scene.

Rough, Rapid, Right

Use Variables

Keep trigger and response names visible

Sending a message to another scene

Arrays and multiple parameters

Put code inside components

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

info@peoplecentereddesign.org

© 2026 David Gilmore