A rotating knob. Connected screens. An embedded circular display. One WiFi network, zero engineering team.

This is a prototype. And it changes what prototyping means for consumer electronics design.

Designers Have Always Had to Fake the Hardware Layer

Screen design tools are exceptional at simulating what a display looks like and how a touch interaction flows. What they cannot do is cross the boundary into the physical world.

A rotary knob cannot live in Figma. An embedded circular display cannot sync with a companion screen in real time. Multi-device hardware systems require either a live engineering build or a room full of workarounds.

The result is familiar. Designers present GIFs. Engineers interpret static specs. User testing happens on devices that look nothing like the real product. Everyone waits.

That gap has a cost in speed, in alignment, and in decisions made before anyone has touched the actual product.

Tools like Figma and Framer solve for screen fidelity and interaction flow. They are the right tools for digital product design. But consumer electronics products, appliances, wearables, automotive interfaces, smart home devices, involve physical controls, embedded displays, and multi-device ecosystems that screen-only tools were never designed to handle. The workarounds designers use today (GIF exports, static handoff specs, separate prototype builds per device) are symptoms of a tooling gap that has existed since touchscreen design tools became the industry standard. 

Daniel Keum, Creative Technologist at ProtoPie, built a working oven control panel interface. Three devices communicate in real time: two screens running ProtoPie prototypes and an ESP32 rotary display, a 480x480 circular touchscreen, acting as the central control knob.

Rotate the knob and the circular display cycles through cooking modes

Tap a food category on one screen and the knob responds

Select a cooking parameter on the other screen and the knob acknowledges it

Every interaction crosses the boundary between screen and hardware, live, over WiFi.

The screens in this build are standard phones. They could just as easily be the actual product displays in your engineering lab. The architecture works with virtually any screen or embedded device that can send and receive data.

The Architecture Is Simpler Than It Looks

holds the UI logic: scene transitions, variable tracking, multi-device message routing

the message hub, receives interactions from any device and broadcasts them to the others

sits between ProtoPie Connect and the hardware, translating messages into commands the device understands

The bridge app is where most designers expect to hit a wall. It is not a wall. Daniel generated the entire working script using AI, describing in plain language which messages should go where. No Python expertise. No dedicated engineer.

The same pattern works with any hardware, touchscreen appliance panels, 

, or any embedded screen communicating over WiFi, serial, or Bluetooth.

One Person Built This in Days, Not Months

The software layer, from Figma export to working multi-device prototype, took days.

The physical housing was built from scratch using 3D-printed parts and off-the-shelf hardware to prove the concept without proprietary equipment. For teams at consumer electronics companies that already have product hardware in their lab, that step is not necessary.

In practice: connect your actual product display to ProtoPie Connect through a bridge app and you have a working hardware prototype running on real screens within days. Not weeks waiting for a dev build.

What This Unlocks for Consumer Electronics Design Team

: leadership can interact with a prototype that behaves like the real product, not watch a presentation about it

: physical form factor changes how people interact; testing on real hardware form produces better data

: a working prototype answers interaction questions engineers can observe and measure, removing guesswork

: hardware interaction issues caught in prototyping are far cheaper to fix than those found during engineering

The assembly iterated through four stages:

: orientation, dimensions, screen placement

: structural decisions, identifying failure points

: translating measurements into components

The trickiest challenge: keeping the ESP32's internal components stationary while the outer knob ring rotates. A precisely measured backing plate, aligned from the hardware's own screw points, solved it. A manufacturing detail the prototype surfaced early.

For teams with existing product hardware, this entire phase is already done. The prototype works in the software layer before a single part is printed.

This Is the First Article in a Series Built for Hardware Designers

How to connect ProtoPie to real hardware — the complete ProtoPie Connect and bridge app workflow

LVGL for designers — how to build embedded display UIs from Squareline Studio to Arduino, without writing code from scratch

The complete hardware package — Arduino code, bridge app templates, Squareline Studio project, and 3D print STL files — will be available to download shortly.

Already designing products at the intersection of screens and hardware? 

What is ProtoPie Connect and how does it enable hardware prototyping?

ProtoPie Connect is a message routing layer that lets any device — phone, tablet, embedded display, or physical hardware — participate in a single prototype. It receives interactions from one device and broadcasts them to the others in real time. For consumer electronics design teams, it is the bridge between a screen-based prototype and the physical hardware surrounding it.

Do I need coding experience to connect ProtoPie to physical hardware?

No. The bridge app that translates messages between ProtoPie Connect and hardware can be generated using AI from a plain-language description of which messages should go where. Daniel built the entire working script for this prototype without writing Python from scratch. Basic familiarity with running a script is enough to get started.

What types of hardware devices work with ProtoPie Connect?

Any device that can send and receive messages over WiFi, serial, or Bluetooth can connect through a bridge app. This includes microcontrollers like the ESP32, Raspberry Pi-based displays, custom embedded panels, and most commercial hardware development boards. If the device can communicate, ProtoPie Connect can be its design-side counterpart.

How is this different from prototyping in Figma?

Figma is built for screen-based UI design and works exceptionally well for digital products. It cannot natively communicate with physical hardware, sync across multiple real devices in real time, or respond to inputs from physical controls like rotary knobs or hardware buttons. ProtoPie combined with ProtoPie Connect extends prototyping into the physical layer that Figma cannot reach.

Which consumer electronics products benefit most from this approach?

Any product where the interaction involves both a screen and a physical control. Home appliances with embedded displays, automotive infotainment systems, wearables, smart home hardware, medical devices with physical interfaces, and audio equipment with digital controls are all strong candidates. If a user touches something physical and a screen responds — this workflow is built for it.

See how ProtoPie's creative technologist built a fully working multi-device hardware prototype — real rotating knob, embedded display, real-time sync — without an engineering team.

How ProtoPie Bridged the Gap Between Screen Design and Physical Hardware

What if the bill could just split itself? 

Five people at a table. One scan. The total divides, updates in real time, and clears the moment the last person pays. No calculator, no awkward Venmo math, no "I'll get you next time."

That's the scenario PaySplit demonstrates. But the real story isn't about splitting a bill, it's about 

what becomes testable when a prototype actually behaves like the product it represents.

The best product teams don't just design great experiences. They validate them before a single line of code is written. And that validation is only as good as the fidelity of what's being tested.

The FinTech Prototyping Gap That Kills Good Products in Production

Research across fintech prototyping and consumer app design teams reveals a consistent pattern: the interactions most likely to fail in production are the ones the design team never properly tested. Not because they didn't know how to test them but because their tools couldn't simulate them.

Dynamic data that recalculates in real time

. These are standard scenarios in payment, delivery, and financial apps. They're also scenarios that most prototyping workflows force designers to fake, skip, or explain away during research sessions.

The result is predictable: incomplete test coverage, stakeholders approving flows that haven't been stress-tested, and edge cases that surface after launch rather than before it.

When a prototype can't reflect how users actually behave, you're not de-risking the product. You're deferring the problem.

What Genuine Fidelity Looks Like in Practice

To make this concrete: ProtoPie's Creative Technologist Nina built PaySplit, 

a real-time, multi-device bill splitting experience running across an iPad and four smartphones simultaneously.

The iPad acts as the point of sale. Each person scans a 

 to join the session. The bill splits dynamically as participants join, recalculates automatically for uneven amounts, and updates across every device the moment someone pays.

It's not a simulation of a payment experience. It behaves like one.

That distinction matters for testing. When users interact with something that responds like the real product, what you observe reflects how they'll actually behave. The research is valid. The edge cases surface. The stakeholder presentation is grounded in something real.

The ProtoPie Capabilities That Make This Possible

PaySplit isn't a special build. It's a demonstration of what ProtoPie makes accessible to any design team working on high-stakes, multi-layered products.

 lets devices communicate in real time natively, no server, no external integrations. One device can act as the source of truth, broadcasting live state to every other connected screen simultaneously. For designers, this means multi-party experiences can be tested as they'll actually work before a single handoff to engineering.

Logic and dynamic data, built into the design file.

 run inside ProtoPie — no faked frames, no scripted workarounds. The prototype responds to every state change automatically, which means what you observe in a test session reflects genuine user behavior, not a guided tour through a happy path.

Hardware integration that makes the first interactions real.

 QR scanning, camera access – ProtoPie integrates with device hardware so users enter the experience the way they actually would. That realism matters: when the starting point feels authentic, everything that follows is worth observing.

 Devices joining mid-session, uneven amounts, out-of-sequence interactions... These are handled by design, not explained away during testing. The scenarios most likely to cause problems in production are the ones you can finally test before it gets there.

This is the tooling that closes the gap between "it tested well" and "it shipped well."

High-fidelity prototyping at this level isn't a design team luxury. 

For consumer payment products, the stakes of untested interactions are high. A checkout flow that breaks under real conditions, a split that doesn't calculate correctly for an odd group size, an onboarding step that fails when a user joins late — these aren't hypotheticals. They're the scenarios that drive churn, generate support volume, and require expensive post-launch fixes.

The design teams that catch these issues in prototyping rather than production 

. The prototype becomes the risk management layer, not just the approval tool.

Teams that prototype at this level don't just catch problems earlier. They move faster because they're not rebuilding confidence at every stakeholder review. When the prototype behaves like the product, alignment happens in the session  not across three rounds of revisions after it.

 lets you run moderated sessions directly from the prototype so the research happens inside the same ecosystem where the experience was built, with no context lost in translation.

And for teams working under tight timelines, 

 can get you to a testable, high-fidelity prototype faster without cutting corners on realism. 

The architecture demonstrated in PaySplit — real-time state sync, dynamic calculation, multi-device coordination — is relevant anywhere your product involves more than one screen, more than one user, or data that changes in response to action:

Financial dashboard with live market data

Multi-user onboarding and verification flows

If the experience has to work in the real world, the prototype should too.

ProtoPie Connect is a communication layer that lets multiple devices sync in real time without a server or code. It's the foundation for prototyping multi-device and multi-screen experiences natively inside ProtoPie. 

Can ProtoPie prototype multi-device fintech experiences without code?

Yes. ProtoPie handles real-time state sync, dynamic calculations, and hardware integration — like QR scanning and biometric triggers — entirely within the design file. No development environment required. 

How does ProtoPie support fintech UX testing?

ProtoPie lets designers build prototypes that respond to real user inputs, simulate live data, and coordinate across multiple devices simultaneously. Combined with ProtoPie's built-in user testing feature, research sessions run directly from the prototype — no third-party tools needed. 

What makes ProtoPie different from other prototyping tools for fintech?

Most prototyping tools require designers to fake dynamic scenarios, static frames for every state, workarounds for real-time data, scripted paths instead of real interactions. ProtoPie handles variables, formulas, conditional logic, and multi-device communication natively, so the prototype behaves like the shipped product rather than a simulation of it.

Prototype at the Level Your Product Requires

The question isn't whether high-fidelity prototyping is worth it. For fintech prototyping, payment apps, and any product where user behavior,
real-time data, and multi-device coordination determine success, it's the only way to know what you're shipping before you ship it.

We work directly with product design teams to scope and build prototypes that match the real demands of your product so what gets tested is what gets shipped.

How real-time, no-code fintech prototyping across five devices closes  the gap between design and production — built entirely in ProtoPie.

What If the Bill Could Just Split Itself? Inside a Live Multi-Device Prototype Built Entirely in ProtoPie

 series. Each chapter stands alone — no need to follow in order.

In fintech prototyping, wrong numbers stop the session. A balance that doesn't match between the dashboard and the account detail screen is enough for a participant to flag it, disengage, and shift from testing the product to evaluating the prototype.

A static dashboard, hardcoded, disconnected, no shared state, creates exactly that problem.

This tutorial fixes it. Every balance in Pie Bank is stored in a variable. The dashboard calculates total net worth in real time. Every account scene pulls from the same source. 

Prefer to learn by watching? The full tutorial video walks you through every step in real time.

, or your own FinTech UI with a home dashboard and account scenes

Your dashboard and account screens imported from Figma into ProtoPie

Prefer to explore a finished build first? 

 is available to download at the end of this tutorial.

New to ProtoPie? Start with a free account and follow along as you build.

Step 1: Import Your FinTech Dashboard Scenes and Clean Up After Chapter 1

In Figma, select your dashboard and account frames, open the ProtoPie plugin, choose 

Delete the leftover placeholder dashboard scene from the previous tutorial

Expect the jump interactions that pointed to it to break — you'll rewire them in Step 2

Rename every scene clearly before moving on: 

💡 Vague scene names like "Scene 4" become a problem the moment you're selecting jump targets from a dropdown list. Name them now.

Step 2: Wire the Banking App Navigation Between Dashboard and Account Screens

Each of the three deposit account cards on the home dashboard needs a tap interaction that jumps to its scene. Do this for Checking, Savings, and Visa:

Set the target scene (Checking / Savings / Visa)

💡 Test each jump immediately after wiring it. If a navigation breaks later, you'll know it's a variable issue — not a wiring issue.

Step 3: Build a Scrollable Dashboard with a Fixed Navigation Bar

The dashboard has three layers: header, main content, and a bottom nav bar. The nav stays fixed; everything above it scrolls.

Select the header and main content layers → group them → name the group 

With the Scroll group selected, drag the bottom border up to sit just above the nav bar

Preview. The content scrolls, the nav bar stays put. That's the fixed-nav behavior users expect from a premium finance app,  and what keeps testers navigating naturally without breaking flow.

Step 4: Create the ProtoPie Variable Architecture That Powers the FinTech Dashboard

This is the step that separates a static fintech prototyping exercise from a dashboard that actually behaves like a product.

 at the bottom left of ProtoPie Studio. Create four variables:

Total net worth is a calculated value that only lives on the home screen — it doesn't need to follow the user into account detail scenes.

3 global variables — available across all scenes:

Global variables are the shared memory of your prototype. Any scene can read them — which is exactly what you need when the same balance has to appear on both the dashboard card and the account detail screen.

💡 Variable names can't contain spaces. Use underscores: 

. ProtoPie will flag the error, but better to get it right the first time.

Step 5: Assign Balance Values and Write the Real-Time Net Worth Formula

Set realistic starting values for the three global variables:

For total_net_worth, skip the static value and wire a formula instead:

Visa is excluded intentionally. Credit card debt doesn't contribute to net worth — it's a liability, not an asset. Fintech stakeholders and test participants with a finance background notice when this logic is wrong. Getting it right is the difference between a prototype that earns trust in the room and one that derails into a debate about the numbers.

Before connecting anything to text layers, verify the formula is working:

Green overlays will appear on the canvas with live values

Step 6: Connect ProtoPie Variables to Dashboard Text Layers with a Start Trigger

Variables live in memory. Text layers live on screen. A 

 bridges the two — it fires automatically when the scene loads, before the user sees anything.

Set up the Start trigger on the home scene:

 — this re-fires the trigger every time the user navigates back to the dashboard, keeping values current

 in layer properties (required before it becomes selectable)

Select the total net worth text layer as the target

The dashboard now shows 38000 — but financial apps display formatted currency, not raw numbers. 

Repeat for the three account balance layers — add a Text response for each, mark as Editable, set Formula, apply the same format wrapper with the matching variable name:

💡 Copy the format string after the first use. Retyping 

Step 7: Replicate the Variable Logic Across All Three Account Scenes

The home dashboard is wired. Now replicate the pattern across Checking, Savings, and Visa.

Copy the relevant Text response from the home scene's Start trigger

Paste it into this scene, make the balance text layer 

Once all three scenes are done, run the full preview flow:

Land on the dashboard — confirm all four balances display correctly

Tap into Checking — confirm the balance matches the dashboard card

Tap back — confirm the dashboard still shows the correct values

The numbers match because they come from the same variable. That consistency is what makes this prototype behave like a real app — and what makes it a trustworthy specification for your engineering team.

On the free plan? Everything in this tutorial works within the free tier. When your team is ready for unlimited prototypes and collaboration features:

Tutorial 2 of 4 — FinTech Prototyping with ProtoPie

How to Wire a FinTech Dashboard with Variables and Real Financial Logic in ProtoPie

Most prototype login screens are a shortcut. You tap a button, the screen changes, and everyone agrees to pretend the credentials mattered. The problem isn't aesthetics — i

t's that a faked login produces faked feedback.

 When test participants know the interaction isn't real, their behavior shifts and the data you collect shifts with it.

Conditional logic that validates actual credentials

The result is a login flow indistinguishable from a shipped product, built entirely in ProtoPie, no code required.

More of a read-and-execute type? Use both, the video for context, this guide for the steps you'll want to revisit.

Your login UI imported from Figma or preferred UI tool

A Lottie file for the Face ID animation (

Step 1: Import Your Login UI from Figma and Keep Your Layer Structure Intact

In Figma, open the plugin panel, search for ProtoPie, and launch it. With your full login frame selected, choose 

 rather than Flattened. Scene preserves your layer hierarchy; Flattened collapses everything into a single image, which makes it impossible to interact with individual elements later.

Click Export. Your layers will appear in ProtoPie exactly as structured in Figma.

💡 Before moving on, rename every layer clearly. Vague names like “Rectangle 14” will cost you time the moment you start wiring interactions.

Step 2: Replace Static Input Fields with Ones That Actually Accept Text

This is the step that separates a realistic prototype from a clickable mockup. ProtoPie’s native Input layer accepts real keyboard input – meaning testers type actual text, not simulated content.

 and drag an Input layer onto your canvas. Place it inside your username field group in the layer hierarchy, than match it visually to your design:

Match the background fill to your field background

 if there’s unwanted spacing at the field edge

Copy the hex code from your original text layer and paste it into the Input layer’s placeholder color, than match the font and size

Preview. Click the field and type. Your username input is now live.

Step 3: Mask the Password Field So It Behaves Like a Real App

 and place the copy inside your password field group. Two changes make it a password field:

Text Password masks typed characters as dots automatically, no customer logic needed.

Preview both fields. Username shows typed text, password shows dots. Exactly what users expect – and exactly what makes this prototype credible in a 

Step 4: Create the Dashboard Scene Before Wiring Navigation

Add a new scene in ProtoPie. This will become your dashboard, it can be empty at this stage. The important thing is that it exists as a 

💡Trying to set up a Jump response without a destination scene is the most common sequencing mistake in early ProtoPie builds.

Tutorial 2 covers the full variable architecture →

Step 5: Make the Login Button Navigate to the Dashboard

, targeting your dashboard scene, Set the transition to 

Preview and tap. The scene changes. The button works, but it works regardless of what’s in the inputs. The next steps fix that.

Step 6: Use Variables to Capture What the User Types

 are what give this prototype memory. Without them, the inputs are just visual fields with no connection to the app's logic.

At the bottom left of the ProtoPie interface, add two variables to your login scene. Set both to 

 type, which handles letters, numbers, and special characters.

Bind each variable to its input layer using a formula. Select the username variable, click 

Tutorials

How ProtoPie Bridged the Gap Between Screen Design and Physical Hardware

What If the Bill Could Just Split Itself? Inside a Live Multi-Device Prototype Built Entirely in ProtoPie

How to Wire a FinTech Dashboard with Variables and Real Financial Logic in ProtoPie

How to Build a Realistic FinTech Login Flow in ProtoPie Without Writing a Single Line of Code

FinTech Prototyping with ProtoPie: Build a Fully Functional Banking App Without Code

How to Build an Interactive MacBook Setup Experience in ProtoPie: A Step-by-Step Guide

A Guide to Creating Reusable Components in ProtoPie - Part 2

Effortless Integration: Connecting Google Sheets to Your ProtoPie Prototypes

A Guide to Creating Reusable Components in ProtoPie - Part 1

Automotive UI Prototyping with Real Car Data

ProtoPie Connect and Unreal Engine 5 Integration

Why Move from Figma to ProtoPie for Advanced Prototyping

Create a Stopwatch Timer using Formulas and Variables

How to Prototype a Dropdown Menu with Components

How to Create a Looping Scroll Carousel for Web