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 Gap That Kills Good Products in Production

Research across fintech 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.

Prototype at the Level Your Product Requires

The question isn't whether high-fidelity prototyping is worth it. For products 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.

Inside a Real-Time, No-Code Prototype That Runs Across Five Devices Simultaneously

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

In fintech user testing, 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 dashboard with numbers on it from a dashboard that knows its numbers.

 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:

What This FinTech Dashboard Prototype Makes Possible

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 

Do the same for password: input("Input Password").text

Toggle on the debug icons next to each variable. Green variable overlays will appear on screen showing live variable values as you type. This confirms the binding is working before you build any logic on top of it.

On the free plan? You can build everything in this tutorial. When you're ready for more – unlimited prototypes, team collaboration, more scenes – here's what's available.

Step 7: Add Conditional Logic So Only Valid Credentials Log In

. Create two conditions that must both be true simultaneously:

 response inside this condition block. The scene transition now only fires when both values match exactly. Wrong credentials, wrong email format, or empty fields — none of them get through.

Step 8: Build the Error State for Failed Login Attempts

A login flow without an error state isn't a login flow — it's a one-way door. Find your error message layer, rename it 

Add a second condition to the login button trigger, the inverse of the first:

Preview the full flow. Wrong credentials surface the error message. Correct credentials jump to the dashboard. The login now has two distinct outcomes, which is what makes it testable and stakeholder-ready.

Step 9: Add the Face ID Animation – the Detail That Makes This Feel Real

Biometric login is the interaction that makes testers stop and ask if this is a real app. Here's how to build it.

 layer onto your canvas. Load your Face ID Lottie file and position the group above the iPhone frame, off-screen. Note the Y coordinate of where you want it to land — Y: 60 works well as a landing position.

 to distinguish it from the main login trigger.

 — target the Lottie container, set Y to 

 — target the Lottie file, set time to 

. This resets the animation so it always plays from the beginning.

 — to your dashboard scene, slide in from right to left.

Step 10: Sequence the Timing So the Animation Plays Before the Scene Changes

Without delay settings, all four responses fire simultaneously, the scene jumps before the animation has a chance to play. Use the timeline delay controls to stagger them.

: 0.5s (gives the Move animation time to complete before the Lottie starts)

: 1s (gives the full Lottie animation time to play out before transitioning)

 on the Jump response. This ensures the Face ID animation returns to its starting position if a user navigates back to the login screen.

Preview the complete flow: tap Login with Face ID, the animation drops in and plays, the screen transitions. That's a biometric login that holds up in front of any stakeholder or test participant.

A login that validates real credentials, surfaces a live error state, and simulates biometric authentication doesn't just look impressive. 

It changes what you can do with the prototype

 engage with it the way they would a live product. The feedback you collect reflects real behavior, not accommodations for "it's just a demo." Stakeholders experience the authentication flow rather than having it explained to them. And when the logic is this precise, the prototype stops being a visual reference and starts being the specification your engineering team works from.

That's the foundation Pie Bank is built on. In 

, we wire the variable architecture that makes every balance in Pie Bank consistent across every screen — and build the logic that makes the numbers actually do math.

Download the Chapter 1 prototype file – the login scene fully built, every interaction wired. Open it alongside this tutorial to explore how each step fits together, or use it as a reference to check your own build.

 Chapter 2: The Living Dashboard Wire real financial logic into your dashboard — variables, live balances, and a net worth formula that actually does the math. 

Tutorial 1 of 4 — FinTech Prototyping with ProtoPie

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

We Built a Fully Functional Banking App. Without Writing a Single Line of Code.

Pie Bank looks like a real app. It behaves like a real app. The login validates actual credentials. The password field masks with dots. The balance updates when you transfer money. The camera opens when you deposit a check.

It’s a  fintech prototype.  Built entirely in ProtoPie.

AI tools can generate a button, approximate a layout, even suggest interaction patterns. What they can't do is validate the specific logic your product depends on. Pie Bank isn't a best-guess interface. Every conditional flow, every balance calculation, every biometric trigger behaves exactly as specified. That's the difference between a fintech prototype that looks right and one that proves the product works.

This series breaks down exactly how it was made. Not the surface-level interactions, but the mechanics that make it feel real: the variables, the conditional flows, the hardware integrations, the math that keeps numbers accurate across every screen.

Why FinTech Prototyping Requires More Than Figma Can Offer

Most product designers in fintech and banking run into the same wall: 

Figma's prototyping layer wasn't built for logic.

A balance figure in Figma is a text label. It doesn't update when a user types a transfer amount. A login screen in Figma can't actually validate credentials. A stock chart can't react to a toggle. To work around this, designers create dozens — sometimes hundreds — of static frames to simulate what a single dynamic interaction should do.

The result is a banking app prototype that looks finished but doesn't behave like one. And in fintech, that gap matters. When stakeholders can't see how the product 

 — how the balance changes, how an error state triggers, how a failed Face ID attempt is handled — they're approving something they haven't actually experienced.

 Users can type real numbers and see the prototype react — balance updates, error states trigger, conditional flows branch based on actual input

 Store account states, balances, and session data in variables that persist across every screen, so the prototype carries real financial state as the user navigates

 Test what happens when a transfer exceeds the balance, when Face ID fails, or when a network error interrupts a transaction — without faking it with static frames

 Run the prototype in ProtoPie Player on a physical device, so stakeholders and test participants experience the banking app UX exactly as the final product will feel

The designers we spoke with were direct about what drives this need. In fintech specifically, 

if portfolio amounts don't add up correctly in a prototype, users stop the test to call out the error

 — and the session is compromised. Realism isn't a nice-to-have when you're testing financial flows. It's the baseline for valid research.

The Business Case for High-Fidelity FinTech Prototyping

validated before a single engineering ticket is created. 

that produce data you can act on, not feedback qualified with "well, it was just a prototype." 

 that happens when a decision-maker slides to send a transfer on a physical device instead of reading a spec doc that tries to explain it.

In most FinTech design workflows, the prototype is a visual reference and the logic lives in documentation. When a prototype carries real variables, live math, and conditional flows, that gap closes. The prototype becomes the specification. Fewer engineering assumptions. Fewer revision cycles.

This series was built for teams who need all three.

Meet Pie Bank: The FinTech Prototype That Behaves Like a Real App

Pie Bank is a high-fidelity mobile banking prototype with four core interaction areas. Each becomes its own deep-dive tutorial, guided by our Creative Technologists at ProtoPie.

Watch the full demo first. Then come back here to learn how each piece was built.

Master fintech prototyping with ProtoPie. This four-chapter series shows how to build a high-fidelity banking app prototype — with real login logic, live balance updates, and camera integration. No code required.

Tutorials

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

How to Design a Circular Slider with Conditionals