Mobile App
B2C Fintech
2025
A mobile remittance app for expat workers in Saudi Arabia and the UAE sending money home which is designed Arabic-first, with bidirectional UX, real-time transfer status, and trust engineered into every screen.
Scroll to explore
My role
Founding Designer (End-to-End)
Client
Tahweel - early-stage GCC fintech
Timeline
12 weeks design, 6 months to MVP
Team
6 - 3 eng, 1 PM, 1 comp, design (me)
Platform
Mobile - iOS + Android
Tools
Figma, Figma Variables, Google Docs
8.5M expat workers across Saudi Arabia and the UAE send around $45B home every year. The apps available to them - Botim Pay, LuLu Money, e&money, Now Money - were built for users who already trust digital finance. They assume English fluency, formal addresses, smartphone confidence, and patience with opaque fees. Tahweel was started to fix that. I joined as the founding designer to define the product from zero.
Every persona in this market is failed differently by what exists. I mapped four.
The worker
Rajesh, 34, drives for a logistics company in Dubai. Sends AED 2,500 home every month. Uses LuLu for routine, walks into Karama exchange house for anything over AED 5,000. Doesn't trust apps alone, needs the branch as a fallback for "real" money. Last month a transfer was held for 18 hours with no explanation. He called his wife and made her panic.
The nurse
Maria, 29, registered nurse in Riyadh. Uses three apps in parallel - STC Pay in-country, e&money for remittance, Wise for larger amounts. Comparison-shops fees, screenshots every confirmation. Pain point isn't speed or cost. It's redundant KYC across every app she joins, and the lack of a receipt she can actually share with her mother.
The recipient
The wife in Kerala. Finds out money arrived from her bank's SMS, not from the app or sender. The sender ends up calling on WhatsApp to confirm — a manual step the product should have eliminated. Recipients are users too, and no app in this category treats them that way.
The regulator
SAMA in Saudi Arabia, CBUAE in the UAE. Both demand FATF-grade KYC, source-of-funds documentation, sanctions screening on every transaction, and a license to operate stored-value facilities. Compliance UX is not optional. The challenge is making it survivable for users who abandon at a 40-60% rate during onboarding.
No research budget. Founding-designer scrappy mode. Three weeks, around 600 AED total spend.
12 user interviews with senders recruited via worker community centres in Dubai and Sharjah — 8 Indian, 2 Pakistani, 2 Filipino. 4 of them I observed sending money in their actual environment, on their actual phone, using their actual app. 6 recipient interviews over Zoom into India. 80 survey responses snowballed through WhatsApp groups. Two expert sessions — one SAMA compliance consultant, one ex-exchange-house ops manager. r/dubai, r/saudiarabia, and expat Facebook groups for unmoderated complaints.
02-Impact
4.3+
App Store and Play Store rating at launch
>40
NPS at month 6, target >55 by month 12
50K
Downloads by month 6 across iOS and Android
15K
Monthly active senders by month 6
>70%
KYC completion rate against industry baseline of 40-60%
<5 min
Time from first app open to first transaction submitted, for a Rajesh-persona user on a mid-range Android
Parity
Arabic-mode users complete the send flow at the same rate as English-mode users
Platform-level metrics are owned across the team. Design-attributed metrics are the ones I'll be measured on after launch.
03 - My Contribution
1
Discovery
JTBD definition
Research synthesis
There was one moment where the team wants to design Pakistan, Philippines, Bangladesh, and Egypt corridors at launch. I pushed back. Each corridor brings a different receive rail, different naming conventions, different compliance rules. Designing five corridors deeply in 12 weeks meant designing all of them shallowly. I scoped to India only at launch and proposed the other four as a month 7-12 rollout. The founders agreed after seeing the corridor-specific receive flow for India.
2
Token architecture
Arabic typography
Component library
Built the Tahweel design system from scratch — three-tier token architecture (Primitives → Semantic → Component) across three Figma variable collections, light and dark modes from day one, fully bidirectional using logical start/end naming rather than left/right. 15 core components, each with Arabic and Latin language variants verified separately. Open-source fonts (Inter + IBM Plex Sans Arabic) so the system can scale without license overhead.
The frontend team wants to works on LTR only and "retrofit RTL in v2." I walked them through what retrofitting RTL actually costs — every layout that uses left/right padding, every icon position decision, every text alignment, every component variant doubles in cost when added after the fact.
3
Sketch exploration
Wireframes
Edge states
Hi-fi screens
Designed the Send Money flow at full depth — 10 screens from home through receipt, plus 40+ edge states across compliance-hold, recipient-bank-down, rate-expired, no-connection, daily-limit, and exchange-failure cases. Onboarding (15 screens) and Transaction Tracking (6 screens) designed at medium depth. Every screen paired LTR/RTL in Figma.
Users weren't worried that money would disappear. They were worried it wouldn't arrive on time for a specific deadline — school fees due Tuesday, rent on the 1st, hospital deposit needed today. The whole status pipeline component came from that insight. Conservative arrival estimates, live status updates, recipient-side SMS confirmation in their language — all of it built to address one fear, not many.
4
Prototype
Feedbacks
Used a structured process for handing over the designs to the development team. Before that showcasing the prototype to the clients and taking their feedbacks on the first phase.
04- Key Design Decisions
Three decisions. Each one a specific response to something observed.
Decision-1
Arabic-first typography, not Arabic-translated.
Every Arabic typeface in a financial app I audited was treated as a translation target — same line-height as Latin, same component dimensions, same padding. The result is text that feels cramped and hostile in Arabic. Naskh script needs around 15-20% more vertical breathing room than Latin to read comfortably at body sizes.
What I rejected:
A single line-height token per text style, applied to both scripts. This is what every translated app does and it's what makes them feel like translations. The Latin line-height looks fine in Arabic at first glance - until you stack 5 lines of body text on a screen and the whole thing feels suffocating. Rejected because it bakes second-class-citizen treatment into the foundation.
Key Insight
Every text style in the Tahweel system ships in two variants — …/latin and …/arabic — with different line-heights but the same name. Components swap them based on a language property. The Arabic variant always has more vertical breathing room. The Latin variant never does. Same component, two correct typographic treatments.
Decision-2
Recipient-first home screen, not amount-first.
Most remittance apps open to an amount field. The transfer is the noun, the recipient is a detail. Tahweel inverts this. The home screen is a list of saved recipients with photos, names, relationships, and last-sent amounts. The transfer is the verb. The recipient is the noun.
Key Insight
A recipient-first home screen makes the entire send flow shorter for repeat use — long-press a recipient and you get "repeat last transaction" in 3 taps. For Rajesh sending the same amount to his wife on the 5th of every month, this is the difference between a 5-minute task and a 30-second one.
Decision-3
Status pipeline as the post-send experience, not a "thank you" screen.
Every remittance app I audited goes silent after "transaction submitted." A success animation, a transaction ID, and a "we'll let you know" message. Hours later, the user is still wondering. Tahweel replaces the thank-you screen with a 5-step status pipeline that updates in real time.
What I rejected:
A static confirmation screen with push notifications for state changes. The eng lead preferred this — it's a smaller engineering surface and uses existing notification infrastructure. Rejected because notifications get dismissed, ignored, or lost. The status pipeline is the screen the user returns to when they get anxious. It has to live somewhere they can find it, and it has to keep updating whether they're in the app or not.
05- Final Design
The platform at a glance, 31 screens across 3 flows plus system surfaces.
Onboarding & KYC
Send Money (Hero)
Tracking & Recipients
System
Flow Deep Dive
Flow-1
This is the flow where 50% of competitor users abandon. Every screen was designed against that number.
01
Users don't abandon onboarding because there are too many steps. They abandon because they don't understand what's being asked. "Source of funds," "proof of address," "liveness verification" — these are legal phrases, not human ones. The flow has more screens than competitors, not fewer. Every screen asks one clear question instead of three confusing ones.
The headline of every onboarding screen is rewritten from regulator-speak into a question the user can answer. "What is the source of your funds?" becomes "How do you earn your income?" The card options aren't dropdowns — they're tappable cards with icons. The progress indicator at the top is honest. 13 of 15 is more than 12 of 12, but 13 of 15 with screens that make sense beats 12 of 12 with screens that don't.
Designing for the worst phone, in the worst light, at the worst moment
Rajesh uses a Redmi Note 11 with 4GB RAM, often on hostel WiFi at 11pm after a 12-hour shift. The document capture screen has auto-capture that activates when the document is detected and stable, not when the user presses a button. Quality failures show specific reasons — "corners not visible," "too blurry," "too dark" — never a generic "try again." The screen below the camera shows live feedback as the user adjusts. If the user gives up, the onboarding state is preserved so they can resume from the exact step they left.
Flow-2
Send Money (Hero)
The flow Tahweel will be judged on. 10 screens, designed deeply, with 40+ edge states.
02
Flow-3
Tracking & Recipients
The flow nobody designs well. Where trust is maintained, not earned.
03
06 - Reflection
1
What worked
The three-tier token architecture
Building Primitives → Semantic → Component before any hi-fi screen meant every design decision downstream had a single source of truth. When the founders wanted to test a teal-700 brand variant against the teal-600 default, it was a one-token change across the entire system. The architecture paid off in week 4, not month 4.
Arabic-first as a discipline
Designing every component in Arabic before checking it in Latin caught problems early — line-heights, vertical centering, icon positioning, mixed-direction numerics. By the time hi-fi started, the system was already bidirectional. Almost nothing had to be retrofitted.
Pushing back on five corridors at launch
The founders wanted India, Pakistan, Philippines, Bangladesh, Egypt at MVP. Scoping to India only was the right call. It let me design the corridor-specific receive flow deeply enough to be a differentiator, instead of shipping five shallow versions.
2
What I'd change
Source of funds card design
The four card options on the source-of-funds screen — Salary, My business, Family savings, Other — work for most users. But I underestimated how many edge cases sit in "Other." Workers with multiple income sources, gig workers, people supporting family members back home with their own remittance, users in informal sectors. The "Other" path leads to a text field. In retrospect, I'd design the screen as a multi-select with a structured "tell us more" follow-up, not a single-select with a free-text escape hatch.
3
What this project taught me
The bilingual constraint is the brief
Almost every component decision in Tahweel — type system, spacing, icon mirroring, numeric handling, error copy — was driven by the requirement to work equally well in two languages. The bilingual constraint isn't decoration. It's the spine of the design system. Treating it as the brief, instead of as a feature to add later, is what made the system honest.
The recipient is a user too
Every remittance app I audited treated the recipient as a field on a form. Designing for the recipient — SMS in their language, share-friendly receipts, QR for recipient self-onboarding — turned out to be the cheapest, highest-trust feature in the product. The lesson generalises: in any product with a second-party user (a recipient, a reviewer, a customer of the customer), designing for them is almost always under-invested.