Design demo. Every screen here is a static mockup — nothing is connected to a payment system, and no control does anything. Names, balances, account numbers and references are invented for review. The rate shown (¥1 ≈ ₵1.76) is illustrative, not quoted.
Corridor 02 · 13 screens
Ama Boateng sends school fees to her son in Guangzhou from a feature phone on a 2G signal. No data connection, no install, no way to scroll back — a USSD session shows one page at a time and dies without warning. Thirteen screens: ten inside the session, three in the app that later explains it.
A remittance from Accra to a Chinese bank account, carried entirely over a GSM signalling channel. The hard constraint is 182 characters per screen: anything longer paginates, and a second page roughly doubles the chance the session drops before the sender confirms. Every screen below fits the budget, and every screen assumes it may be the last one she sees.
Four items, no greeting, no branding line beyond the name. Everything cut from this screen is a character that buys room on the confirmation screen later, where the cost of pagination is much higher.
Her own name confirms the SIM the session is running on before she types a secret into it. The reset shortcode sits on the screen rather than in a help menu, because a forgotten PIN here ends the session and she has to redial from the start.
Held and available are split on the smallest screen in the product, and the hold names the trade it belongs to. A sender who sees ₵12,480.50 and can only spend ₵12,080.50 will read the shortfall as theft unless the session says where the ₵400 went.
Saved names only — there is no path here for typing a Chinese bank account, because a mistyped digit on a keypad with no way to scroll back is how remittances get lost. Names appear in Latin script: the session is GSM 7-bit and cannot carry 李伟.
Both limits and the rate are on the entry screen, not behind a rejection. Finding out that ₵6,000 is over the cap after typing it costs another round trip on a session that may not survive one.
The yuan figure appears before the money is committed, because she is not thinking in cedis — she is thinking about what her son can withdraw. Fee and total are separated so the ₵8.50 is never discovered afterwards on a statement.
A second PIN, distinct from the one that opened the session, and the amount is restated above it. The last line says plainly what the keypress does: on a menu of numbered options, a lone “1” does not feel like authorising ₵858.50.
USSD sessions time out, so the screen releases her instead of asking her to wait. It also names the SMS as the real receipt and prints the reference now — if the session dies in the next second, she still has the number that identifies the transfer.
The reference leads, above the word “Sent”, because it is the only durable artefact of a session that is about to vanish — it is what she reads out to an agent three days later. The new available balance closes the loop on the ₵400 still held.
The rejection names the bank, the cause and the account it applies to, and then says the money never left the wallet. A bare “transaction failed” is indistinguishable from a lost ₵858.50, and the failed attempt still carries its own reference so support can find it.
The same transfers on a smartphone, for the household member who has one. The constraint here is that the app is never the system of record for a USSD transfer: it must show the identical reference, the identical amounts and the identical failure reason, or the two channels start disagreeing in front of a support agent.
Both currencies sit in the summary because the household measures the year in yuan delivered, not cedis spent. The rejected transfer stays in the list at full weight rather than being filtered out — a failure she cannot find is a failure she assumes took her money.
Beneficiaries are created and corrected only here, which is what lets the USSD menu be a list of two numbers. Each entry shows its Latin USSD label next to the Chinese name the bank actually matches on, so the string that caused screen 10’s rejection is visible and editable.
The timeline is leg by leg with a timestamp on each, because “arrives in 2 hours” is only credible if she can see which leg it is sitting in. The header carries the same reference the session printed, and the row naming *714*88# is what tells her this is that transfer.