Why Test Users Stop Believing Your Prototype

Nearly every usability session hits the same wall: a participant pauses at the login screen, types a few characters, then glances up to check whether they’re “doing it right.” That glance is the moment the illusion breaks. Once a tester realizes the app isn’t real, every subsequent data point is filtered through that awareness.

Financial products amplify the problem. Users who manage money are trained to notice inconsistencies: a balance that doesn’t add up, a field that accepts anything. When a banking prototype skips real authentication, participants don’t just disengage — they stop mid-session to call it out. The team walks away with findings about how people behave in a demonstration, not in a shipped product.

In a banking context, the login screen is where trust gets established. This tutorial builds a login flow for Pie Bank, a mobile banking prototype, with functional text inputs, a masked password field, credential validation, a live error state, and a Face ID animation timed to feel native to iOS. No code required.

What you’ll need:

  • A login UI from Figma (or any supported design tool)
  • ProtoPie Studio — free to start; everything here works on the free plan
  • A Lottie file for the Face ID animation
  • The finished Pie Bank prototype file to follow along or use as a reference

Bringing Layers In: Scene, Not Flattened

In Figma, open the ProtoPie plugin with your login frame selected and export as Scene rather than Flattened. Flattened collapses everything into one image; Scene preserves your layer hierarchy, so every element arrives in ProtoPie as a separate, targetable layer.

Rename layers meaningfully before moving on. “Input Username” beats “Rectangle 14” when you’re referencing names in formulas — vague labels compound into real time lost.

Making the Fields Accept Real Text

ProtoPie’s native Input layer accepts actual keyboard entry — participants type text, not just tap a placeholder. Go to Text → Input, drag an Input layer onto the canvas, and nest it inside your username field group. Match the visual design: placeholder text Username, background fill, and font. Preview the result: click the field, type, and the prototype starts behaving like an app instead of depicting one.

Rename the layer Input Username, duplicate it, and nest the copy inside your password field group.

On the duplicated layer, change the placeholder to Password and set Type to Text Password. ProtoPie handles the masking automatically — no custom logic needed. Username shows text, password shows dots. It already feels real, and you haven’t written a single condition.

Wiring the Button — and the Problem With Letting Everyone Through

Create a new scene (even a blank one) before wiring navigation. Trying to build a navigation response without a destination is the most common sequencing mistake in ProtoPie.

Select Log In, add a Tap trigger, set the response to Jump, target your dashboard scene, and choose Slide in from right to left as the transition.

Preview and tap. It navigates — for any input, including empty fields. The prototype is still lying. Two more steps fix that.

Variables and Conditions: The Prototype Starts Remembering

Add two Text type variables at the bottom-left: username and password. Bind each to its input layer with a formula:

Enable the debug icons: green overlays show live variable values as you type. When keystrokes appear in real time, the binding is confirmed.

Return to the Tap trigger on the login button. Add a Condition with two rules, both required:

Move the Jump response inside that condition. Wrong credentials, empty fields, wrong format: none get through. Participants must actually log in, and that single constraint changes the texture of every test session that follows.

Now build the error state that most prototypes skip. Find your error message layer, rename it Error Text, and set its initial opacity to 0. Add a second condition (the inverse of the first), and inside it a Change Property response setting Error Text opacity to 100.

Wrong credentials — error appears. Correct credentials — dashboard. Two distinct outcomes make the prototype testable, not just demonstrable.

The Face ID Detail That Makes Testers Ask, “Is This Real?”

Go to Media, drag a Lottie layer onto the canvas, load your Face ID file, and position it off-screen above the iPhone frame. On your Login with Face ID button, add a Tap trigger (rename it Tap Face ID) with four responses in sequence:

  • Move: Lottie container to Y: 60
  • Playback: Seek time 0s (resets so it always plays from the start)
  • Playback: Play: Lottie file
  • Jump: to dashboard

Without delays, all four fire at once and the scene jumps before the animation plays. Add offsets to the sequence so the animation drops in, plays, and only then transitions. Enable Reset selected scenes on Jump — without it, navigating back leaves the animation stuck at Y: 60.

The result: tap Face ID, animation drops in, plays, and the screen transitions. A biometric login visually indistinguishable from the real thing.

What a Real Login Changes in Your Research

When authentication actually works, the error state becomes a genuine research touchpoint. Do users understand the message? Do they retry? Do they reach for Face ID instead? These are questions a faked login can’t answer.

In stakeholder reviews, the flow speaks for itself. In engineering handoff, the interaction panel documents conditional logic, variable bindings, and timing — engineers see stated intent, not interpretation.

FinTech teams invest in login fidelity even when the login isn’t the feature under test. It establishes participant trust. Get it right, and everything downstream produces better signal.