Send a friend $100
without an account.
Role
Sole designer
End to end
Timeline
Jul 2026 – present
In development
Type
Gifting
Co-branded wallet
Focus
Claim & redemption
Across six paths
The brief
One gift,
six ways it gets opened.
The recipient arrives with or without the app, with or without a wallet, at a register or in a browser. Every combination is a different sequence.
Has app, has wallet
The gift lands in the existing balance and is spendable at once.
Has app, no wallet
Opens and spends in store. The wallet is offered afterward.
No app, in store
A barcode the register reads. No install.
No app, online
A code applied at checkout, shown against the basket.
Gift covers the basket
Completes. Nothing further asked.
Gift falls short
Spend up to the gift amount. Split tender was cut in compliance review.
TL;DR
The brief
Let someone send wallet money to a friend. The friend might not have the app, an account, or any interest in getting one.
What I drew
A three-step send, a reveal that opens on the sender, and one claim screen that works at a register or in a browser. Six recipient paths, 50+ screens.
Where it stands
In development. Six rounds of iteration behind it, two features cut in compliance review, and the edge states drawn.
The constraint
The gift is stored value,
not a transfer.
Money moving between two people triggers an identity check on both ends. Closed-loop value, spendable only at this retailer, does not.
If it were a transfer
Verify, open a wallet, then see the gift. Three screens before the present.
As stored value
Open the gift, spend it in store. Verification only if they want a wallet of their own.
The screens
Compose, open,
spend.
Sending
Three steps, then Review
Details, Personalize, Review
The last step was labelled Payment, then Send, before landing on Review. Payment made a $100 gift feel like a bill, and Send implied the tap before it had already done something.
Opening
Sealed, then open
Who it is from, then what is in it
A full-screen sealed state, a tap to open, the sender and their note, then the amount. Nothing else on the screen except one line of type.
Spending
Barcode and code together
One screen, in store or online
The register reads the barcode. The browser takes the code at checkout, applied as its own line against the basket with the remaining balance shown beside it.
Iteration
Six rounds.
What changed, and why.
The gift balance
A $100 gift card sitting beside a $91 wallet balance
One $191 balance, with VIEW GIFT DETAILS underneath
Two amounts on one screen made people add up before paying. The card also pushed the flow to four dots; folding it in took it back to three.
Pre-verification state
$110 shown locked until identity is verified
$100 spendable now, $10 welcome bonus locked
The gift is already paid for. Locking the whole amount showed one balance in two states and read as the money being withheld.
The claim screen
A toggle between in-store barcode and online code
Both on one screen
The toggle asked which channel you wanted before you had any reason to know.
The reveal
Amount first, then sender and message
Sender and message first, amount second
Opening on the number made the screen read as a deposit confirmation.
Shortfall at checkout
Split the payment across the gift and a card
Spend up to the gift amount
Cut in review. The split re-opened a cash-out path that the closed-loop model exists to prevent.
Video message
Record a short clip with the gift
Text message only
Descoped for V1 on effort. The flow is drawn for it to come back.
Compliance review
Two features cut,
one sentence rewritten six times.
Every screen that touches identity or money went through review before it could ship.
Split tender, cut
Paying part gift and part card re-opened a route to convert closed-loop value into spendable cash. Replaced with spend-up-to-gift-amount.
The disclosure, rewritten
The banner explaining the identity check went through six versions. “Verify your identity” read as an accusation; the shipped line names the law and what it blocks.
Wording, standardised
“Gift card” collides with the retailer’s own product, so everything says gift code. Swept across every screen and every state.
QA
The states nobody
asks for in a brief.
Most of the screen count is here. A gift has more failure states than happy ones.
Verification denied
The wallet is blocked, the gift is not. The balance stays visible and spendable in store, since somebody else already paid for it.
Zero balance
A drained gift card still rendering as a card. Removed, with the transaction kept in history.
Balance disagreement
Home and Pay In Store were reading from different places and could show different numbers. One source.
Pre-verification barcode
The barcode was scannable for the full amount before the check completed. Gated to the spendable portion.
Currency formatting
$00.00 appearing in empty states instead of $0.00.
Barcode expiry
TODO, open with engineering. The in-store and web claim screens both change if it expires.
Shipped
In development,
drawn to the edges.
My learning
What held
Folding the gift into the main balance. It removed a dot from the flow, a number from the screen, and the question of which amount was spendable.
What I would redo
Draw the denied and expired states in round one. Both arrived late and both changed screens that were already signed off.
Never tested with users
This went through design and compliance review, not sessions. Review catches whether a screen is allowed to exist. It does not tell you whether someone opening a gift understands what they are holding, and the reveal order is exactly the call I would want evidence for.