(001) OVERVIEW
ROLE
Product design and the front-end build — research framing, flows, UI, and the working prototype.
PLATFORM
Mobile. Built as a real React app, not a clickthrough.
CONTEXT
Academic fintech concept.
A security model people can read is worth more than one they are told to trust.
When a bank stops a payment you learn two things: that it was stopped, and that you should call someone. You never learn what tripped it. The suspicion is real, the reasoning is sealed, and the cost lands on you — a dead card at a counter, twenty minutes on hold, a dispute form that asks you to prove a negative.
TruePay started as a concept with the right ingredients: a security score, live alerts, biometric approval, a model watching every transaction. But it spent them on reassurance — badges telling you that you were safe. That is the same black box in nicer packaging.
So I rebuilt it as a working front-end shell, because the interesting questions here are not answerable in static frames. How much security presence is too much? Does anyone actually read five risk factors, or do they just want the verdict? Does making the model legible calm someone down, or hand them a new thing to worry about?
The forty-second version
Onboarding, then home, then a payment sent, screened and approved. If you watch one thing on this page, make it this — the prototype drives itself.
(002) THE QUESTION
Security you never see is invisible. Security you always see is a checkpoint.
This is the tension the whole product sits on, and I did not want to settle it by argument. So I built visibility as a live variable with three settings, and made every screen answer to it.
Quiet
Present, but not shouting. No score, no trust block.
Default
As it ships: score in the header, trust block in the feed.
Foregrounded
Something needs attention, so narration takes the top.
FIG. 01 — ONE SCREEN, THREE POSTURES, SWITCHABLE AT RUNTIME
Default is what the build ships with — enough that the model is visibly working, quiet enough that it is not asking for credit. Foregrounded earns its place right after a hold, when narration is genuinely wanted, and nowhere else.
(003) THE CALM PATH
Most payments are fine. The design has to believe that.
Ninety-nine times out of a hundred the model has nothing to say, and the screening should cost you nothing but a beat of reassurance. Five steps, one thumb, no interruption — and the security work stays visible without ever asking permission.
04 — APPROVED WITH FACE ID
FIG. 02 — FOUR CHECKS RUN BEFORE THE MONEY MOVES, AND THE USER NEVER WAITS ON THEM
(004) READING THE RISK
People need to know how bad it is before they need to know why.
A held payment normally arrives as a wall of text. But the first question is never why — it is how bad. So the review leads with the shape of the suspicion, and only then explains itself.
THE SHAPE, THEN THE REASONS
Silhouette first
Five signals on five axes. A shape pulled hard toward two of them means something specific is wrong — not that everything is faintly off. You read that in under a second, and confidence sits as one number in the middle.
Then the list
Strongest-first, each signal’s weight drawn as a bar. The radar answers how much; the list answers which. Splitting those two jobs is what stops the screen reading as model output dumped on a user.
FIG. 03 — UNKNOWN MERCHANT 94, UNUSUAL AMOUNT 86, DISTANT ORIGIN 62, OFF-PATTERN TIMING 34, DEVICE MATCH 12
Colour before you read a word
The same tension runs underneath the whole app: a drifting field behind every screen shifts from calm, to screening, to held, to cleared. It never carries state alone — every mood is paired with text, an icon and a token — but it is what makes the app feel read before the review screen explains itself.
FIG. 03B — CALM · SCREENING · HELD · CLEARED
(005) THE DECISION
Held is not blocked. The model narrows the choice; it never takes it.
There is no path where the review resolves itself and tells you afterwards. Both outcomes sit in a footer pinned to the bottom of the sheet, so however long the signal list runs, the decision stays one thumb-reach away.
Yes, this was me
Releases the payment and folds the merchant into what the model trusts — it will not stop you there again.
Not me
Freezes the card, opens a dispute, and says plainly that you are not liable while it is reviewed. Neither outcome is a dead end.
A fix, not a plan
The first build let the buttons sit at the end of the content. On a 390-point screen the signal list pushed them below the fold — the single most important control in the product, reachable only by scrolling past every reason to distrust it. Sticky footer, gradient fade, problem gone.
I only caught it because the prototype was real enough to scroll. That is the argument for building the thing.
(006) THE SCORE
A number you cannot move is decoration.
Trust scores in finance apps are usually handed down, with no visible relationship to anything you control. Here the score is the sum of six protection weights. Switch one off and it recalculates in front of you.
TRUST BLOOM — 72 TICKS ON A STANDING WAVE
Why not a ring
The visual had to be able to degrade, which ruled out a progress ring — a ring at 42% looks like a ring at 96%, only shorter. Instead the score is 72 ticks riding a standing wave. Lit ticks encode the value; a second, rougher harmonic scales with how much cover you have lost.
So a weakened score does not merely shrink. It visibly frays. The number and the feeling move together.
FIG. 04 — PROTECTIONS COME OFF, THE WAVE FRAYS, THEN THEY GO BACK ON
(007) THE CRAFT
Dark fintech has a house style. I went to banknotes instead.
Following the house style would have produced a competent app nobody remembers. The material I reached for was security printing — banknotes, share certificates, cheque stock — not as pastiche, but for the two things it does well: fine line-work that signals value, and typography that treats numbers as the subject.
Guilloché under the money
Real spirograph geometry sits beneath the balance and every card face — the same construction used on currency to make forgery expensive. Drawn faintly enough that most people never consciously notice it, which is the point: it makes those surfaces read as an object with value rather than a coloured rectangle.
Four faces, one job each
A grotesque for display and balances, one italic serif word carrying the pitch in the headline and never appearing again, a humanist sans for interface prose, and a mono for every micro-label — so timestamps and card numbers line up down the screen instead of drifting.
Acid lime for verified
The one deliberate oddity. Green on violet goes muddy; lime cuts. It is the colour the eye finds first in a feed of cleared payments, which is exactly the job.
A spectrum that derives itself
The two companion gradient stops are not hand-picked — they rotate off the chosen accent in hue, so the brand gradient stays coherent whichever accent is set.
Tactility
The balance card tilts under the pointer and catches a specular sweep that tracks the cursor. On a payments surface that is not decoration — it is the difference between a number on a screen and a thing you own.
(008) THE SYSTEM
Every colour and corner in the build is one token away from changing.
The prototype ships with its own control panel. Accent, corner radius, type pairing and AI presence are all live, and each writes a CSS custom property the whole app reads — no component holds a literal colour or radius. It exists so a design review can change the argument mid-sentence instead of asking for another round of comps.
WELCOMECALIBRATINGFACE IDHOMEACTIVITYSECURITYPROFILESEND MONEYHELD PAYMENTTRANSACTIONCARDS
ELEVEN SCENES — THREE ONBOARDING BEATS, FOUR TABS, FOUR OVERLAY FLOWS — ALL REACHABLE BY ARROW KEY
FIG. 05 — THE STAGE: SCENE RAIL, DEVICE, AND THE LIVE TOKEN PANEL
Autoplay, for people who will not click
Seven scripted reels drive the prototype hands-free — a synthetic pointer travels to each control, taps it, and a caption narrates underneath. A record mode strips the stage chrome so a screen capture comes out clean.
Built to be recorded
At a viewport around 945 points tall the device renders at exactly 390 × 844, so a retina capture gives clean 2× pixels with no resampling. The prototype is its own asset pipeline.
Cards
A physical card, a merchant-locked virtual number, and a business card — each with its own freeze switch and spend meter, drawn with the same banknote line-work as the balance.
(009) WHERE IT LANDED
Security as a relationship, not a gauntlet.
11
Screens, all navigable — a shell, not a clickthrough.
5
Signals behind every hold, each one weighted and shown.
0
Red walls. Every stop comes with its reasons and both outcomes.
The insight that stuck: people will accept almost any safeguard if you tell them why it is there, and resent the smallest one if you do not. Every decision in this build follows from that — the radar, the ambient field, the score you can move, the decision that never leaves the screen.
Rebuilding it as a working shell rather than a prototype deck was the right call for a second reason I did not expect: the sticky-footer problem in (005) is invisible in static frames. You only find it by scrolling a real screen at a real size.
What it has not earned yet
Does the radar actually read?
I believe the silhouette is faster than a list. That is a hypothesis, and it needs five people and a stopwatch, not my confidence.
An accessibility pass on the ambient field
State is carried by colour, icon and text together — but I have not tested it with a screen reader, or at reduced motion beyond honouring the media query.
The watching verdict needs a home
Recurring subscriptions sit between cleared and held, and that middle verdict currently only appears as a badge. It deserves a surface.
Business mode is a switch, not a flow
Dual approval over a threshold is stated in the profile and implemented nowhere. It is the obvious next build.