Designing Financial Trust During Cuba’s Currency Crisis
A remittance platform designed during Cuba’s 2021 liquidity crisis to help families exchange money faster, more fairly, and outside institutional banking systems. Originally created to solve my own need to externalize savings before relocating from Cuba to Spain, the platform facilitated approximately $25k USD equivalent in exchanges over a three-month period during one of the country’s most unstable financial moments.
Challenge
Two sides of the same broken system
For decades, Cuba’s financial system had remained largely disconnected from the international economy:
- Cuban bank cards only worked domestically,
- citizens could not freely open foreign bank accounts,
- and travelers could only leave the country with limited amounts of cash.
Despite these restrictions, people could still traditionally exchange Cuban pesos (CUP) for USD through state banks at the official rate:
1 USD ≈ 25 CUP.
But after the COVID-19 economic collapse, Cuban banks effectively ran out of foreign currency reserves. Citizens could no longer reliably purchase USD or EUR through official channels, while the informal exchange market rapidly inflated to nearly:
1 USD ≈ 50 CUP.
At the same time, traditional remittance systems like Western Union continued operating at the outdated official exchange rate (~25 CUP), causing Cuban families abroad to lose nearly half the real market value of the money they sent home.
Recipients inside Cuba also faced:
- long lines,
- transportation shortages,
- slow delivery processes,
- and limited office availability during a nationwide mobility crisis.
Meanwhile, I faced the opposite side of the same problem. As I prepared to move from Cuba to Spain for graduate school, I needed to:
- convert my savings into foreign currency,
- move that money outside Cuba,
- and avoid the extremely inflated rates of the informal market.
I realized both problems could partially solve each other.
My role
Designer, operator, and courier
I:
- identified the operational opportunity,
- designed the service model,
- designed the full UX and interface system,
- structured the UX flows and information architecture,
- coordinated logistics and delivery operations,
- managed customer communication and trust,
- handled distribution,
- and operated the system directly during its active period.
At the time, I was working as a designer at Futurasit, a Cuban software agency. Developers from the agency collaborated on building the live web platform under my product and UX direction.
I also collaborated with a 3D designer for the visual illustrations used in the original website.
The Solution
Designing the exchange, not just the interface
Instead of exchanging my savings directly through the black market at nearly:
1 USD ≈ 50 CUP,
I designed a lightweight remittance platform that connected:
- Cuban families abroad who needed to send money into Cuba,
- with recipients who needed Cuban pesos (CUP) locally.
The system worked through a direct exchange model:
- families abroad transferred USD or EUR through PayPal to an external account associated with the platform,
- and I delivered the equivalent value locally in CUP inside Cuba.
Wanikiki operated around:
1 USD ≈ 35 CUP
Positioned between:
- the institutional rate (~25 CUP),
- and the black market (~50 CUP).
This created value for both sides simultaneously:
- families abroad obtained significantly better rates than Western Union,
- recipients received money faster and more conveniently,
- and I was able to progressively externalize my own savings at a far more sustainable rate than the informal market offered directly.
The Live Product
A lightweight site, a heavyweight promise
The original platform operated as a lightweight remittance coordination website focused on:
- simplicity,
- speed,
- and operational trust.
Users abroad could:
- initiate transfers,
- select delivery methods,
- and track transaction status updates.
The system supported:
- home delivery within Havana,
- and local Cuban bank transfers.
Most operations ended up using home delivery, which quickly became one of the platform’s strongest trust signals.
The original experience notified users when:
- the process started,
- the transfer entered delivery,
- and the transaction was completed.
At this stage, the system was designed primarily around the sender abroad, who had access to the platform and transaction tracking. But operationally, a different behavior emerged.
First Operational Insights
The most active participant saw the least
After operating the platform and completing the first deliveries myself, a more important insight emerged.
The sender abroad initiated the transfer, but the recipient inside Cuba often became the focal point of the experience. Recipients frequently:
- requested delivery updates,
- changed availability times,
- modified delivery addresses,
- or contacted support directly during the process.
The original platform already included transaction tracking and basic operational tooling.
However, real-world usage exposed additional operational needs around:
- delivery coordination,
- scheduling flexibility,
- and recipient communication during the process.
Three operational patterns quickly emerged:
- The most engaged participant in the process had the least visibility into it.
- Most support requests were coordination requests rather than payment issues.
- Trust depended on keeping multiple actors aligned around the same delivery status.
As the operator, I was manually handling much of that coordination outside the product.
Service models
Mapping the operation I was running by hand
To understand where those responsibilities lived, I mapped the complete operational journey behind each transfer. The resulting models reframed Wanikiki from a remittance website into a coordination system involving multiple actors, communication channels, and operational responsibilities, and became the foundation for the redesign that followed.
2026 Mobile Redesign
Coordination becomes part of the product
The redesign explored what the service could look like if the operational coordination that originally depended on a single person became part of the product itself.
Rather than centering the experience around the sender alone, the system was restructured around four actors: Sender, Recipient, Courier, and Operator.
Each actor received dedicated permissions, visibility, communication channels, and responsibilities throughout the delivery lifecycle.
The redesign introduced:
- shared real-time delivery states across all participants,
- role-based operational workflows,
- integrated communication linked to each transfer,
- delivery scheduling and rescheduling,
- recipient-facing tracking without account creation,
- and automated notifications triggered by operational events.
A key design decision was treating the recipient as a first-class participant despite never requiring an account. Recipients could receive SMS updates, access a public tracking link, communicate during delivery, confirm details, and follow the transfer from any device with a browser.
The redesign also formalized the operational model behind the service:
- courier route blocks,
- cash-float management,
- assignment workflows,
- delivery capacity planning,
- exception handling,
- and daily operational reconciliation.
By bringing communication, coordination, and operational visibility into the product itself, the redesign transformed Wanikiki from a remittance website into a shared trust and delivery system.
Design system
One language, four roles
A single design system covering the four experiences, from visual foundations to product patterns, documented as the source of truth for the redesign.
Machine-readable in DTCG format: tokens.json →
Key screens
Ten screens that carry the key decisions
The full redesign spans 44 screens across four actors. These ten are the ones that best show the thinking: what each actor sees, and the decision each screen carries.
01 · Sender
Recipient & address book
The delivery slots show real capacity: days marked "full" or "few left," booked slots disabled. The sender's choice is tied to the operator's actual blocks and couriers on the ground, so what they pick is always something the system can deliver.
02 · Sender
Payment
Many transfers happened without the recipient knowing who sent them. So the sender controls what the SMS reveals (name, amount, or neither) with a live preview of the exact message that will arrive. Nothing is sent that the sender has not already read.
03 · Sender
Payment successful
The success screen echoes the exact SMS the recipient will get, plus a copyable tracking code. Instead of "trust us, it's on its way," the sender sees the literal message reaching their family.
04 · Sender
Transfer failed
Failure is handled differently depending on where it happens. A rejected payment reassures first ("your money is intact, nothing was charged") and explains likely causes; a failed delivery shows the exact refund window and dates.
05 · Recipient
Public tracking
The recipient has no account and no app, just a tracking link over SMS, built for a basic browser on a slow connection. From it they can follow the delivery, message the courier, and reschedule.
06 · Courier
Today · Active day
A courier's day doesn't start until the operator confirms she has physically picked up the cash, and only then do her deliveries activate. Her active day shows what that means in practice: the float she carries, updated with every delivery. You can't hand over money you don't have yet, and the interface enforces it.
07 · Operator
Delivery detail
The timeline shows how the delivery was assigned, step by step: proposed to Carmen (declined), to Daniel (no reply), to Rachel (accepted). Instead of a black box, the operator, and anyone reviewing the system, can audit an automated decision in plain sight.
08 · Operator
Operations panel
The operator's dashboard works in blocks, not individual shipments, with a "needs your attention" feed surfacing what's urgent. And it tracks cash in circulation as a live metric: the physical money currently in couriers' hands. The mental model matches how the operation actually runs.
09 · Sender
Empty history
Empty isn't a dead end. The empty history is treated as an onboarding moment, a clear illustration and one action that opens the path forward ("make my first transfer · no fee the first time"). The same anatomy repeats across every empty state in the app.
10 · Operator
Chat with sender
Inside the conversation, automatic events ("time slot updated · SMS sent to María") render as centered system notes, visually separate from human messages, so it is always clear whether a machine or a person is speaking.
Outcomes & Reflections
$25k moved, zero failed deliveries
Wanikiki operated publicly for approximately three months, the time required for me to successfully externalize my savings before relocating to Spain.
During that period, the platform facilitated approximately:
- $25k USD equivalent in exchanges,
- through dozens of successful operations,
- including several high-value transactions.
The system achieved:
- zero failed deliveries,
- strong referral-driven growth,
- and high user trust despite operating entirely outside institutional infrastructure.
Although the original platform was intentionally lightweight, operating it exposed a much larger design problem than currency exchange alone.
What began as a remittance service revealed itself as a coordination system involving trust, communication, logistics, and operational visibility across multiple actors.
The redesign documented in this case study represents how I would evolve that experience today: transforming operational knowledge gained in the field into a more scalable service model.
Looking back, Wanikiki emerged during the earliest stage of what would become a much deeper monetary collapse in Cuba.
At the time, the informal exchange rate had already risen to nearly 1 USD ≈ 50 CUP (double the official institutional rate). In 2026, that same informal rate exceeds 500 CUP per USD. What initially felt like a temporary workaround ultimately reflected the beginning of a much larger systemic breakdown.
More importantly, it changed how I think about product design. Not simply as interface creation, but as the design of trust, coordination, incentives, communication, and operational systems under real-world constraints.
