Senior Product Designer Web3 · FinTech · Enterprise

I leverage AI to design & develop world-class products

01 Position

Money makes people nervous. My job is to design the moment that nervousness turns into confidence.

I work closely with founders, engineers, and business stakeholders to translate regulatory, technical, and business requirements into digital & build products that solve real problems of user and business.

I work at the seam where crypto, banking and enterprise software meet — the places where one unclear label costs somebody real money.

My strength lies in bridging user needs with business objectives to deliver high-impact solutions.

Selected
Work

Four products.
Hover to summon · click to open

Method — four movements 01 / 04

Interrogate

Before a single frame: what is the money actually doing, who is afraid of it, and where does trust break? I read support tickets before I open Figma.

Output — one page: the problem, in the customer’s words

Frame

One sentence the whole team can repeat. Flows on a wall, states before screens, the ugly edge cases named out loud while they are still cheap to fix.

Output — flows, states and the edge cases nobody wants

Build

Production-ready code, at real speed. If it can’t be clicked it can’t be judged — so stakeholders get a build, not a deck of rectangles.

Output — a clickable build, not a deck of rectangles

Systematize

Tokens, components, modes and the documentation nobody wants to write. The measure of the work is what the next designer can do without me.

Output — tokens, components, modes, documentation

Drag across the plate

02 — Studio

A designer who ships, and a builder who still argues about kerning.

I’m Aamir Khan — a senior product designer who designs, builds, and manages products across Web3 wallets, stablecoins, payments, KYC/KYB, AML, onboarding, banking and enterprise SaaS. I design the system, then build the prototype that proves it, and ship it, usually in the same week.

ChatGPT for the research and the design thinking. Claude for the quick prototype that validates the idea. Figma for making it pixel-perfect, and HTML, CSS and JavaScript as the icing on the cake. Everything you are scrolling through right now is hand-built — the portrait above is 70,000 GPU particles reading a photograph.

Figma

Claude

ChatGPT

Product design

Prototype

Research

Design systems

Back-end & front-end

Deep analysis

Interaction & motion

Build & ship

Content & UX copy

0Flagship products

0Industries, in depth

0Components in the last design system I shipped

∞Infinite iterations until stakeholders satisfied

hi@aamir.design

Available for senior & lead product design roles. Relocation welcome.

aamir.design Email Mobile Back to top

Local time --:--:-- GMT+4

All work

Case study 03Global Citizen

Making global impact traceable

Rethinking how a US nonprofit moves funding across borders — and how that movement can be made visible, faster and accountable.

Global Citizen · brand key visual

RoleSenior Product Designer

ScopeDiscovery → product definition → prototype

SurfaceFunding platform & dashboard

RailCrypto payments alongside FIAT

The challenge

What if every dollar donated could be traced from the moment it was given to the moment it created impact?

Global Citizen is a US-based nonprofit that mobilizes funding for critical challenges around the world — food security, education, agriculture, energy.

But moving funds across borders is complex. Organizations and implementing partners face slow cross-border settlement, transaction limits, intermediaries and high payment costs. Donors face something simpler and harder: not knowing.

The opportunity wasn’t to redesign a payment screen. It was to rethink how funds move through the ecosystem — and how that movement could be made visible and accountable.

What every donor actually asks

Where did my money go?
Who received it?
Where is it now?
What did it fund?
What impact did it create?

A global funding journey
with limited visibility

The existing FIAT-based payment infrastructure introduces friction at multiple points in the funding lifecycle. Each hop is a place where time, money and traceability are lost.

Existing FIAT railDays to settle · fees at each hop · limited visibility

DonorIntermediariesPartner

Proposed crypto railNetwork-dependent settlement · verifiable record · fewer hops

DonorNetworkPartner

Transparency

ConsequenceA trust gap for donors

Fund movements can pass through multiple financial institutions and intermediaries, making it difficult to give a simple, end-to-end view of where funds originated, where they went, and how they ultimately created impact.

Settlement delays

ConsequenceDays or weeks, in time-sensitive work

Cross-border FIAT transactions can require multiple intermediaries and settlement processes. Funds that could reach their destination quickly may take days or weeks to fully settle. For organizations operating in time-sensitive environments, that delay matters.

Transaction constraints

ConsequenceInfrastructure limits the mission

Traditional financial infrastructure can introduce limits around how much can be transferred, where funds can be sent, and how transactions are processed. The rail becomes a constraint on the funding ecosystem itself.

Cost of moving money

ConsequenceOverhead competes with impact

Cross-border transactions can involve fees across different stages of the payment journey. For organizations working to maximize the impact of every donated dollar, payment overhead directly competes with mission impact.

Reframing the opportunity

Rather than asking

How can we make the existing payment flow better?

I asked

Can we create a more transparent and efficient financial rail for moving funds across the ecosystem?

This led me to explore crypto-based payments as an additional payment method alongside the existing FIAT infrastructure. The goal was never to replace traditional payments overnight — it was to introduce an alternative rail that addresses some of the structural limitations of cross-border FIAT.

Why blockchain —
and why not as a trend

It was evaluated because some of its underlying characteristics mapped directly onto the problems we were trying to solve.

Traceability

Transactions are recorded on a public blockchain, creating a verifiable transaction history.

Potential product benefit Donors and authorised stakeholders gain visibility into fund movement.

Speed

Depending on network and conditions, digital assets can settle significantly faster than traditional cross-border processes.

Potential product benefit Less friction moving funds between participants.

Programmability

Smart contracts can encode predefined rules and automate financial workflows.

Potential product benefit More structured fund distribution and accountability.

Lower overhead

Certain networks can offer lower transaction costs than traditional cross-border rails.

Potential product benefit More of the available funding reaches its intended destination.

Important caveat

These benefits depend on the blockchain network, asset, custody model, compliance requirements and operating environment. The product therefore had to treat crypto as a financial infrastructure choice — not a UI feature.

My role

Senior Product Designer, working from discovery through product definition and prototyping.

The work required thinking beyond individual screens and understanding the entire funding lifecycle.

Responsibilities

Problem framingUser & stakeholder analysisProduct research Information architectureComplex financial workflowsUX architecture Design systemInteraction designPrototyping Usability validationIterationProduct documentation AI-assisted research

Designing for an ecosystem,
not a single user

This was never a two-sided product. Four groups touch the same money with entirely different motivations.

Donors

Need — confidence & visibility

They want to understand where their contribution went and what it achieved.

Implementing partners

Need — access & clear records

They receive, manage, allocate and report on funding, and need efficient access to it.

Leadership

Need — organizational visibility

Funding flows, performance, allocation and impact at an aggregate level.

Finance & compliance

Need — control & accountability

Transaction histories, permissions, auditability and appropriate controls.

The product shouldn’t merely move money. It should make the movement of money understandable.

From payment to impact

I stopped treating the transaction as the end of the experience and started treating it as one event inside a much longer journey.

Donor
Contribution
Transaction
Fund allocation
Implementing partner
Program
Beneficiary
Impact

That reframing opened the questions the product actually had to answer: where did the funds originate, which organization received them, which program got the allocation, how much, what stage is it in now, and what outcomes did it produce.

Three principles
held the concept together

Make money movement visible

Give users a clear transaction trail rather than forcing them to understand blockchain infrastructure.

Hide unnecessary complexity

Blockchain terminology should not become the user’s problem. Nobody should need to understand gas, hashes, networks or wallet mechanics just to know whether their funds arrived.

Connect transactions to impact

A transaction shouldn’t feel like an isolated financial event. The experience should show what happened after it.

Turning infrastructure into product

The blockchain stays underneath. The product speaks the user’s language.

A blockchain transaction carries wallet addresses, hashes, network data, token amounts, confirmations, fees and timestamps. Most people don’t think in any of those terms — so I designed the information in layers instead of exposing it by default.

Human-readable summary

Relevant transaction detail

Technical blockchain data

A donor needs one sentence. An operations or compliance stakeholder needs the hash. Progressive disclosure lets both be true on the same screen.

Try it — concept UI, illustrative values

Contribution received $250.00 Allocated to Clean Water — Northern Region · settled in seconds

Transaction: 0x7f3a·····c21b
Network: Illustrative L2
Wallet: 0x9b41·····4d0e
Timestamp: 14:02:11 UTC
Fee: 0.004 USD
Confirmations: 32

The architecture is a set
of questions, not a menu

I structured the product around what each stakeholder naturally asks.

“What is happening with the money?”

Dashboard

High-level funding, allocation, transaction and impact visibility.

“Where is the money?”

Funds

Available, allocated, pending and distributed funds in one view.

“What happened to this payment?”

Transactions

A detailed, traceable history of financial activity.

“What is this money funding?”

Programs

Funding connected to the initiatives it supports.

“What did the money achieve?”

Impact

Outcomes and measurable impact surfaced against funding.

“Who is involved?”

Organizations

Donors, implementing partners and other ecosystem participants.

Design decisions

Trust over technology

I avoided making the product feel like a crypto exchange. The primary experience is about funds and impact — not cryptocurrency.

Familiar financial patterns

Transaction status, payment confirmation, fund allocation, balances, activity history, receipts, audit trails. Established patterns reduce the cognitive load of introducing a new rail.

Transparency without overload

Showing everything doesn’t create transparency. Good transparency is showing the right information at the right moment — so essential information and technical data were separated.

A simple loop,
run rigorously

Ask the right questions

Challenge the assumptions behind the problem before designing screens.

Understand the problem

Map users, stakeholders, constraints, workflows and dependencies.

Research & analyze

The existing funding journey, financial infrastructure, blockchain capabilities, user needs.

Prototype

Convert concepts into interactive prototypes early, before heavy implementation.

Test with stakeholders

Use real feedback to find gaps, confusion and operational concerns.

Iterate

Refine on what was learned rather than defending the first solution.

Ship

Problem → validated solution → usable product. Not polished screens.

How I work with AI

AI is my second brain, not my first brain.

AI accelerates the groundwork

Research synthesis
Competitive analysis
Pattern exploration
Design-system exploration
Prototyping
Documentation
Scenario generation
Edge-case exploration
Alternative solutions

AI generates possibilities.

Then the part that matters

I evaluate, challenge, refine and validate the output against user needs, business objectives, technical constraints and stakeholder requirements.

I make the product decisions.

The result

The experience explores how a global nonprofit could introduce blockchain-based payments without forcing users to become crypto experts — a bridge between traditional financial workflows and blockchain infrastructure, while keeping the user’s mental model on what actually matters.

Where did the money go?
Who received it?
What did it fund?
What impact did it create?

What I learned

Transparency is not the same as exposing more data.

A blockchain can provide an immutable record, but that alone doesn’t create a transparent experience. The designer’s job is to turn complex financial and technical infrastructure into information people can understand, trust and act on.

The best technology is invisible when the experience is good.

Users shouldn’t have to care that blockchain is underneath. They should simply feel that their money moves faster, is easier to trace, and is connected to real-world impact.

The bigger opportunity

A broader model for transparent impact finance — where funding, organizations, transactions, programs and outcomes live in one connected system.

FromI donated money.

ToI can see where my money went, who it reached, and what it helped create.

Next case studyTaifa Care Pharma supply chain Back toSelected work All four products

All work

Case study 05Taifa Care

Track & Trace for a national medicine supply chain

Designing visibility and accountability across Kenya’s regulated pharmaceutical ecosystem — regulators, manufacturers, distributors, suppliers and healthcare facilities on one traceable record.

Taifa Care regulatory dashboard: totals for products, manufacturers, suppliers, facilities, recalled batches and compliance ratio, with earnings and weekly revenue charts, recent batches and orders tables, order traffic, total recall breakdown and recently onboarded organizations — Regulatory dashboard · the ecosystem at a glance

RoleProduct Designer

SectorPharmaceutical supply chain

MarketKenya

ScopeDiscovery → prototype → design system → build support

The premise

Medicines don’t simply move from manufacturer to distributor to hospital.

In a national pharmaceutical supply chain, every movement creates a new question. Taifa Care connects government regulators, manufacturers, distributors, suppliers and healthcare facilities, and gives them visibility into how medicines move across Kenya.

As the Product Designer, my challenge was turning a highly complex, regulated supply-chain ecosystem into workflows that very different stakeholders could actually understand and operate.

Every movement creates a question

Where did this medicine come from?
Where is it now?
Who handled it?
Is it authentic?
Where did this batch go next?

A medicine’s journey was
difficult to see end-to-end

The supply chain involved multiple organizations, systems, locations and handoffs — which created a different problem for every stakeholder.

Government & regulators

Oversight · investigation

Can we identify suspicious or counterfeit medicines in the market?

Regulators need visibility across the ecosystem to monitor product movement, investigate anomalies and support regulatory oversight.

Manufacturers

Downstream visibility

Where did this batch go?

Once products leave the facility, manufacturers need to know where batches were distributed and which organizations received them. Without reliable traceability, investigating a problematic batch becomes significantly harder.

Distributors & suppliers

Verification · onward movement

Did we receive the genuine product, and where did it go afterward?

Distributors need to verify products entering their inventory and keep visibility over where those batches are subsequently sent.

Healthcare facilities

Receiving · confidence

Can we verify what we’re receiving?

Hospitals, pharmacies and other facilities need confidence that the medicines entering their supply chain can be identified and traced.

The real product challenge

At first glance it sounds simple

Track medicines.

It wasn’t

Track individual products and batches across a multi-organization supply chain — under different permissions, responsibilities, workflows and regulatory requirements.

Which meant the product had to answer three fundamental questions. These became the foundation of the whole experience.

Identity

What exactly is this product?

A unique identifier assigned to pharmaceutical products and batches — a digital identity that travels with the physical product.

Location

Where has it been?

Every organization and location the product has passed through, and where it sits right now.

History

What happened to it along the way?

The sequence of events attached to the product — created, aggregated, shipped, received, verified, recalled, dispensed.

From product identity to traceability

Instead of treating a medicine as a line item, the platform had to represent it as a moving object with a history.

The inventory model

Product→Quantity

The traceability model

Product→Batch→Location→Organization→Movement→Event→History

Designing for an ecosystem

Taifa Care wasn’t a single-user application. It was an ecosystem — different jobs, different access, different questions.

Stakeholder	Primary need
Government / regulators	Oversight, compliance & investigation
Manufacturers	Production & downstream visibility
Distributors	Receiving, verification & distribution
Suppliers	Inventory & movement visibility
Healthcare facilities	Product verification & receiving
Platform owners	Operational & ecosystem visibility

That table drove everything downstream: the information architecture, the permissions, the dashboards, the workflows, and how much detail each user was shown.

Before designing,
I went into discovery

This wasn’t a project where I could jump straight into Figma. The domain itself had to be understood first, so I spent time with stakeholders in discussions and working sessions — and researched the risks of introducing traceability into a regulated pharmaceutical environment.

Understand the system before designing the interface.

What had to be understood first

Existing supply-chain workflowsStakeholder responsibilities Operational pain pointsRegulatory requirements Compliance constraintsData dependencies System limitationsRoles & permissions Partner integrationsBusiness objectives

Mapping the supply chain

The physical product moves forward. The platform has to keep a parallel digital trail of events. That distinction became critical to the architecture.

Physical movementDigital trail

ManufacturerProduction & batching

Product manufacturedBatch createdProduct aggregated

Supplier / distributorReceiving & onward distribution

Shipment createdShipment dispatchedShipment received

WarehouseHolding & allocation

Product transferredProduct verified

Healthcare facilityVerification on arrival

Shipment receivedProduct verifiedBatch recalled

PatientPoint of care

Product dispensed

The product had to understand
events, not just screens

A traditional ERP mindset stops at inventory, orders, users and reports. Track & Trace needs another layer underneath — every event contributes to a product’s history, so the UX had to make those events understandable without exposing the machinery behind them.

Product manufacturedBatch createdProduct aggregated Shipment createdShipment dispatchedShipment received Product transferredProduct verifiedBatch recalled Product dispensed

The product architecture

Structured around the operational needs of the ecosystem, not around the database.

01Regulatory dashboard

A centralized view for monitoring pharmaceutical activity across the ecosystem.

02Product & batch traceability

Search and trace products and batches across their full lifecycle.

03Product verification

Let stakeholders check whether a product can be identified within the system.

04Inventory

Understand what products and batches an organization currently holds.

05Shipment & distribution

Track movement between organizations and locations.

06Recalls & alerts

Surface relevant batch, expiry and recall information where it matters.

07Organizations

Manage the organizations participating in the pharmaceutical ecosystem.

08Audit & compliance

Visibility into activities and historical events, for the people who must answer for them.

Making a complex supply
chain understandable

A batch may pass through several organizations and locations. Representing that as a table wasn’t enough — the interface had to carry two very different questions at once.

The ten-second question

Where is this batch right now?

And the deeper investigation

Show me every movement and event on this batch.

Which led to one object carrying high-level status, a timeline of history, location information and detailed event data — layered so that neither question drowns the other.

Try it — concept UI, illustrative values

BATCH · KE-AMX-4417-B

Amoxicillin 500 mg · 12,000 units

In transit

Current holderCentral Medical Stores

Last eventShipment dispatched

ManufacturedBatch KE-AMX-4417-B

ExpiryIn 19 months

Then reality arrived

The design isn’t finished when
the Figma file is finished

The platform had to exchange information with external partners and systems. The design couldn’t assume the data would look exactly like the prototype — so I worked alongside engineering during integration to make sure the UI represented the data actually being exchanged.

Sometimesan API returns a different structure than expected.

Sometimesa field is optional.

Sometimesa new status appears.

Sometimesone partner sends data differently from another.

Sometimesa backend constraint changes the interaction entirely.

So the work ran as a loop, not a handoff

What it wasn’t

Design→Handoff→Done

What it was

Design→Prototype→Engineering→API→Real data→Feedback

I supported engineering throughout: reviewing implemented screens, clarifying interaction behavior, reviewing API-driven states, updating designs when data structures changed, refining components and handling the edge cases that only appear once real data arrives.

From ambiguity to prototype

Because the domain was so complex, I deliberately didn’t start by polishing UI. I translated research and stakeholder sessions into workflows, user journeys and information architecture first — then into an interactive prototype covering the key flows.

Prototype the system before polishing the screens.

That prototype became the shared language between stakeholders, product, design and engineering. Instead of asking “does this screen look right?” we could ask “can you complete this real-world workflow?” — which produced far more useful feedback.

What the feedback changed

NavigationWorkflow structureInformation hierarchy Form behaviorStatesPermissions ValidationError handlingData presentationEdge cases

Then the system had to hold all of this

Multiple modulesMultiple stakeholder typesComplex tables FormsStatus systemsAlerts Data-heavy dashboardsTraceability viewsAudit information Interaction states

Built on the existing brand, adapted to the realities of the users and the regional context. The goal was never visual consistency alone — it was a system that could carry a product this wide.

How I worked with AI here

AI is my second brain — not my first brain.

Where it accelerated the work

Research synthesis
Workflow exploration
Scenario generation
Prototype development
Design-system exploration
Documentation
Alternative solutions
Edge-case discovery

AI-assisted prototyping let me turn complex workflows into something stakeholders could interact with, fast.

Where it had to be checked

AI-generated output isn’t automatically good product design. It can hallucinate. It can misunderstand domain rules. It can produce workflows that are technically plausible and operationally wrong.

So I reviewed, challenged, redesigned and validated every output against user needs, stakeholder requirements, business objectives, technical constraints and regulatory considerations.

What made this hard

Domain complexity

NotA conventional SaaS dashboard

Pharmaceutical supply chains, government stakeholders, regulatory considerations, physical products, digital identities and multiple organizations — all in one product.

Multiple mental models

RiskA product that fragments

A regulator, a manufacturer, a distributor and a healthcare facility don’t think about the same data in the same way. The product had to accommodate that without splitting into four products.

Physical world × digital world

RealityEvery event is a real movement

The platform wasn’t tracking abstract data. It was tracking real medicines moving through real locations — and that relationship shaped almost every design decision.

The outcome

Taifa Care evolved from a complex supply-chain requirement into a connected platform for pharmaceutical traceability.

Identify products→Track batches→Verify authenticity→Monitor movement→Investigate events→Support recalls→Keep an auditable history

The most important shift wasn’t a feature. It was moving from fragmented visibility toward a shared source of truth for pharmaceutical product movement.

What I learned

Complex products need simple mental models

Users shouldn’t have to understand the architecture of the system to understand where a medicine is.

Enterprise UX is systems design

The most important decisions weren’t visual. They were about roles, permissions, data, workflows, states, integrations and exceptions.

Design doesn’t stop at handoff

When real APIs and real operational constraints arrive, the product changes. Senior product design means staying involved long enough for the experience to survive contact with reality.

Technology should serve the workflow

An API, AI, ERP infrastructure or a traceability standard is only valuable when it helps people do the job with less uncertainty.

The bigger picture

Taifa Care wasn’t just an ERP interface. It was an attempt to create a digital layer of trust across a physical pharmaceutical supply chain — connecting the manufacturer who needs to know where a batch went, the distributor who needs to know what they received, the facility that needs to know what entered its inventory, and the regulator who needs to see the whole picture.

Every medicine should have a story.

Where it came from.
Where it went.
Who handled it.
And where it is now.

Next case studySpark Bank Luxury banking Back toSelected work All four products

All work

Case study 02DDSC Wallet

A digital AED wallet for 24/7 money movement

Making blockchain-based money movement feel simple, transparent and trustworthy — for people who are not thinking about blockchain at all.

DDSC Wallet on three phones: onboarding with login and create account, home screen showing a 1,250.50 DDSC balance with recent transactions, and the Send DDSC form — Onboarding · Balance · Send

RoleProduct Designer

AssetDDSC · AED-backed, 1:1 peg

SettlementADI Chain

ScopeRequirements → 3 prototypes → design system

The premise

Money is one of the highest-trust products a person can use.

DDSC is an AED-backed digital currency designed to hold a 1:1 peg with the UAE dirham, settling on ADI Chain. My challenge was to translate blockchain infrastructure and regulated financial requirements into an experience simple enough for everyday users and robust enough for serious financial activity.

What the wallet has to do

On-ramp into DDSCHoldSend ReceiveOff-ramp to fiatTrack activity

What nobody should have to wonder

Did it go through?
Where is my money?
How much did I actually send?
Who received it?
Can I trace it?

Money moves globally.
Infrastructure doesn’t always keep up.

Businesses and individuals increasingly operate across borders, but traditional payment infrastructure introduces friction. A single cross-border transfer can pass through five parties before it lands — and every additional layer is another dependency.

Sender→Bank→Correspondent bank→Payment network→Receiving bank→Recipient

Which can result in

Slower cross-border transfersMultiple intermediaries Transaction & FX costsBanking hours & cut-offs Difficult reconciliationComplex settlementSlow treasury movements

~27%

Banking hoursWeekday windows and cut-off times decide when value can actually move.

24/7

Continuous settlementThe opportunity: AED-denominated value moving digitally, transparently and continuously.

The product proposition

I didn’t treat blockchain as the product. I treated it as the infrastructure underneath the product.

Nobody should need to understand

Blockchain architecture · wallet infrastructure · network mechanics · transaction hashes · smart contracts

to do this

Send AED.

Complex infrastructure. Simple experience.

Designing a wallet is easy.
Designing one people trust
with their money is not.

Six requirements pulled against each other on almost every screen.

Simplicity

Financial actions should feel obvious.

Transparency

Users should always understand what is happening to their money.

Security

High-risk actions need appropriate friction and confirmation.

Compliance

The experience has to operate inside regulatory requirements.

Technical feasibility

The UI must reflect what the wallet, chain and APIs can actually support.

Business objectives

Useful enough that people adopt it and keep using it.

So the design problem was never “what should the wallet look like?” It was “how do we make blockchain-based financial transactions feel trustworthy and understandable?”

Designing with constraints, not around them

I worked with founders, product managers, technology leaders, product engineers, compliance professionals and legal stakeholders. Several working sessions went into establishing the boundaries before any detailed design started.

Users→Use cases→Features→Constraints→Compliance→Technology→Trade-offs

That gave me a much clearer definition of what the product needed to solve — and, just as usefully, what it couldn’t promise.

Three financial behaviours, one wallet

Individuals

Minimal complexity

Deposit→Hold→Send→Receive→Withdraw

Everyday movement of value, with as few decisions as the action honestly requires.

Businesses

Operational visibility

Transfers→Settlement→Visibility→Reconciliation

Stronger reporting, because the money is somebody’s books as well as somebody’s balance.

Finance & compliance

Control

Controls→Records→Verification→Auditability

The wallet couldn’t be designed around a single happy path.

The core experience

I structured the wallet around the user’s fundamental questions, not around the feature list.

“How much value do I have?”

Balance

The first thing anyone opens a wallet to see.

“How do I move my money?”

Send

The highest-consequence action in the product.

“How can someone send money to me?”

Receive

Sharing an address without exposing wallet mechanics.

“How do I convert AED into DDSC?”

Deposit · on-ramp

The bridge in from traditional currency.

“How do I convert DDSC back into AED?”

Withdraw · off-ramp

The bridge back out, which matters just as much.

“What happened to my money?”

Transactions

The record that turns a balance into a history.

Trust isn’t created by adding a lock icon. It’s created by predictability, clarity, feedback and control.

For every critical transaction I designed against four moments.

BeforeWhat am I about to do?

DuringWhat is happening right now?

AfterDid it succeed?

If something goes wrongWhat happened, and what can I do next?

Which shaped

Transaction confirmationsAmount presentationStatus states Error handlingTransaction historyPending states Success statesFailed statesNetwork statesDeposit & withdrawal flows

Designing Send

“Send” sounds simple

A financial transaction contains several decisions and several potential failure points. The flow has to walk the user through all of them without making the walk feel long.

Who→What amount→Which asset→Where→Fees→Final amount→Confirmation

The confirmation step is the final checkpoint. Instead of a button that says Confirm, the user should be able to say: “I am sending X DDSC to this recipient, and this is what will happen next.”

Try it — concept UI, illustrative values

You send

2,500.00DDSC

ToAl Fahidi Trading LLC

Address0x7c2e·····9f41

AssetDDSC · AED 1:1

Blockchain gives you data.
It doesn’t give you understanding.

A transaction hash is useful to a technical user and meaningless to someone who only wants to know whether their payment arrived. So transaction history was built in layers — what you need first, with the depth available when you want it.

Human-readableSent · Received · Deposit · Withdrawal

FinancialAmount · Date · Status

TransactionRecipient · Reference · Network details

TechnicalTransaction ID · Blockchain details

On-ramp & off-ramp

The user is moving between two representations of the same value. The interface has to say so plainly.

AEDUAE dirham

On-rampOff-ramp

DDSCDigital AED · 1:1

Which the flow has to communicate every time

AmountConversionDestinationStatus TimingFees, where applicableConfirmation

The goal was for this to feel like a familiar financial transaction rather than a complicated crypto operation.

I didn’t settle on
the first workflow

Once the requirements were established, I used AI-assisted prototyping to build three high-fidelity product directions — each taking a different position on architecture, navigation and transaction flow. The team got to evaluate working experiences instead of static ideas.

Direction one

Information architecture and wallet navigation as the organizing idea — what the product foregrounds before anything is tapped.

Direction two

Transaction flows and send/receive behaviour as the organizing idea — the product built outward from its riskiest action.

Direction three

Deposit, withdrawal and transaction visibility as the organizing idea — the product built around moving between AED and DDSC.

Evaluated against

User needsBusiness objectivesCompliance requirements Technical feasibilityDevelopment effortProduct scalability Time & team constraints

We didn’t pick the most visually impressive concept. We picked the direction with the strongest balance between experience, feasibility, compliance and business requirements — and that became the foundation for the product.

The design system

With the direction settled, I moved from exploration into systematization — a system aligned with the DDSC brand and the needs of a financial product.

TypographyColorSpacingButtonsInputs FormsCardsNavigationTransaction components Status indicatorsTablesModalsAlerts Empty statesLoading statesError states

When users are moving money, consistency reduces uncertainty.

AI as an accelerator

I used Claude heavily for concept exploration, high-fidelity prototyping, scenario generation, alternative workflows, design-system development, edge cases, documentation and iteration.

But not for the decisions

AI-generated output requires scrutiny — particularly in financial products, where a seemingly small interaction can create a significant user or compliance issue. Every output was reviewed against user needs, business requirements, regulatory constraints and technical feasibility.

AI increased the speed of exploration. Human judgment determined the product.

Designing for financial confidence

Users should never feel uncertain about their money.

Instead of a technical state

Transaction processing…

Answer the questions actually being asked

What is happening?
How much is involved?
What happens next?
Do I need to do anything?
When will I know it’s complete?

And the visual language had to read as

SimpleCleanPreciseModernTrustworthy

Sophisticated enough for financial professionals. Simple enough for everyday users. Financial infrastructure without feeling sterile or intimidating.

The wallet becomes the control center for digital AED

On-ramp→Hold→Send / Receive→Track→Off-ramp

And underneath that simplicity sits everything it takes to run it: blockchain settlement, transaction traceability and regulated financial operations.

What I learned

Trust is an interaction design problem

People don’t trust financial products because they look secure. They trust them when the product consistently says what happened, what is happening, and what will happen next.

Blockchain UX should hide complexity, not information

The chain should provide transparency without forcing anyone to understand it. Abstraction should remove complexity — not remove control.

Compliance can improve UX

Understanding compliance early creates better product boundaries. I treated it as an input into the architecture rather than a restriction discovered afterward.

Prototype the decision, not just the interface

Three working prototypes gave stakeholders something tangible to evaluate, which made the conversations far more productive than debating static screens.

Financial products demand precision

A button isn’t just a button when it moves money. A status isn’t just a label when someone is waiting on settlement. Every interaction carries financial consequence.

The bigger picture

DDSC isn’t simply another crypto wallet. The broader opportunity is a bridge between traditional AED and programmable digital value — and the wallet is the interface that makes that infrastructure usable. My role was to make a complex financial system feel clear, controlled and trustworthy, without hiding the information people need to make confident decisions.

Complex infrastructure underneath. Simple experience on top.

Say what will happen.
Say what is happening.
Say what happened.
And never make them guess.

Next case studyGlobal Citizen Impact finance Back toSelected work All four products

All work

Case study 04Spark Bank

A whole bank that behaves like a luxury object

Every banking app ships the same features. Spark Bank was built on the bet that once features stop being the difference, the deciding factor is how the thing makes you feel when you open it.

Cards · Welcome · Savings

RoleSr. Product Designer

ScopeResearch → IA → wireframes → visual language → build

MethodInterviews, surveys, personas, empathy maps, CJM, card sorting

Output30 screens · clickable prototype

The premise

Banking apps compete on a feature list that stopped being a differentiator years ago.

Balance, transfer, cards, statements — every serious bank has them, and has had them for a decade. So Spark Bank does not try to be the perfect banking product. It takes a position: that a financial app can carry full-scale banking functionality and still be something a person looks forward to opening.

That is a design problem, not a feature problem. It took several months, and the whole thing was built on what people told us they actually wanted rather than on what the category assumes.

What “luxury” had to mean here

Not a gold gradient on a standard app
Nothing removed to make it look calm
Considered at every state, not just the home screen
Emotionally legible, not just visually rich
Worth opening when there is nothing to do

01 — Find the heroes of the story

You cannot design for a feeling
you have not heard described

Before a single frame, I wanted to know who would become an enthusiastic supporter of this bank and why. That meant asking, not assuming — interviews in person and remotely, publicly available research, and surveys run on social media to reach people outside our own circle.

In-person interviewsRemote interviewsSocial-media surveys Desk researchCompetitive teardown

Two archetypes came out of it, and they turned out to be the whole brief.

Discoverers

Traditional banking apps are complicated and tedious.

Energetic people who keep up with current trends. They are not asking for more features; they are asking why using their money feels like admin.

Lovers of beauty

It should look like something I chose.

Enthusiasts of good-looking, authentic solutions and modern novelties, who want that appreciation of beauty to extend into the ordinary parts of their lives.

02 — Key user personas

Two people carried the decisions. One is why the app has to be fast. The other is why it has to be exact.

Lukas Warner

Sales manager

Age: 35
Education: MBA
Work: Sales manager at an IT company
Family: Mother, brother, three sisters
Lives: Dubai, UAE

Financial literacy

Tech skills

Elegant, precise, ambitious. Still paying a student loan from three years ago and saving for his first property, because paying down a loan beats paying rent. He holds accounts at several banks he never chose — one per job — and splits his life between them: one for the loan and savings, another for daily spending. He plans purchases rather than making them. What he wants is simply to see where the money goes.

Chris Torel

Finance manager

Age: 55
Education: PhD, Business Strategy
Work: Finance manager at a global bank
Family: Father, wife and son
Lives: Sharjah, UAE

Financial literacy

Tech skills

He knows exactly what a bank owes him, which makes him the harder of the two to please. He will forgive a slower path if the numbers are unambiguous, and forgive nothing if they are not. Designing for Chris is what kept the product honest: no figure without its context, no confirmation without its detail, nothing simplified past the point of being checkable.

Between them they cover the two failure modes of a premium financial product — too slow for the person who lives on their phone, too vague for the person who reads the statement.

03 — Open your heart to the user’s feelings

An empathy map for each persona,
to find out what the interview left out

A persona tells you who someone is. An empathy map tells you what it is like to be them — and that is where the main paths of usage came from, ranked by what actually mattered to the person rather than by what was easiest to build.

Says

“Is there something innovative in finances?” Pays attention to details. Likes discussing fintech, and a lot of other things besides.

Thinks

All financial apps are the same — complex, and nothing to look at. A financial app should make life easier. It should save time and energy, not spend it.

Does

Loves sport, spends weekends outside rather than at home. Plans his spending in a spreadsheet, because the bank never gave him anything better.

Feels

Dislikes the feeling of not being on top of his spending. Relaxed in a space that looks and feels good. Interested every time he tries something new.

Two things fell out of this that shaped everything after it. The pain was not missing functionality — it was out-of-date design that took effort to read. And these people were already primed to leave: they were curious about neo-banks, and being told to try them by friends who had already switched.

The complaint we expectedMy bank is missing features.

The complaint we heardMy bank makes me work to understand my own money.

04 — Map the journey

Everything we had learned,
merged into one picture

The customer journey map pulled the observations from every earlier stage into a single document: what people expected from the app, what they would feel while using it, and the paths they would take most — set against business objectives, KPIs and a plan of action.

Seeing the whole picture at once is what made it possible to design a step-by-step experience that serves the person and the business in the same move, instead of trading one against the other. And it let me mark the moments that carry the most emotional weight — the points where the product either earns trust or loses it.

Curiosity→Enrol→First look→Daily use→Moment of doubt→Loyalty

The crucial action points were not the ones with the most taps. They were the ones where someone asks themselves, quietly, whether this bank has their back.

05 — Information architecture

The decision the whole
product rests on: no menu

I built the architecture from the mental models people showed us rather than from the org chart of a bank. To get there I ran card sorting — potential users arranging the components of the product the way their own heads arrange them — and used the result to shape the conceptual model of the service, built from the fundamental sections of data and the vocabulary that goes with them.

Then I made the call that defines Spark Bank: simplify the architecture until the navigation menu is unnecessary, and delete it. Not fewer features — fewer places to be lost.

MenuA list of where you could be

BecameReplaced

StructureA place you already are

And none of this was given up to get there

AccountsTransactionsStatistics & graphsTransfer RequestAdd fundsScheduled paymentsLines of credit InsuranceDebit cardsInvestmentsProfile settings NotificationsSupport

A full bank, with nowhere to get lost in it. That constraint did more for the feeling of the product than any visual decision that followed.

06 — Wireframes, low then high

Low fidelity to argue about structure. High fidelity to find out we were wrong about one thing.

Low-fidelity wireframes drew the overall structure of the app — cheap enough to throw away, complete enough to disagree with. High fidelity turned that into a prototype real enough to test the UX strategy and the key user scenarios properly, which is where the interesting failure showed up.

We tested in-house against the most critical and frequently used banking scenarios from the Red Route Analysis. People struggled to work out how to activate the payment function.

The obvious fixAdd a control that explains itself.

What we did insteadLeave the structure alone and teach it once, on first login.

Adding a visible affordance would have solved one screen and started the slow slide back toward the cluttered apps we were reacting against. Keeping the structure intact and adding a single learning tip at first login solved it for people less comfortable with advanced technology without charging every other user for it, forever. That trade — one moment of teaching against permanent visual debt — is the one I would defend hardest.

07 — The key concept

You cannot colour in
a wireframe and call it a feeling

This is the phase everyone waits for and the one most often skipped. The job was to turn what we had learned about how these people feel into a visual language — and that is not the same as applying a palette to finished wireframes, or borrowing an abstract inspiration board.

It took a week. The idea changed shape repeatedly, and the version we shipped looks very little like the first one. I kept going until nothing obvious was left to improve, which is the only honest stopping rule I know.

Version one

The premise stated plainly. Enough to see that the direction had something, and that it was not there yet.

Version two

Warmth and depth pushed harder against the dark ground, testing how far richness could go before it read as decoration.

Version three

Pulled back. The restraint that separates a premium product from an expensive-looking one.

Final

Light, depth and motion borrowed from nature rather than from finance — the reason the app feels alive instead of merely dark.

The language had to read as

Mind-blowingEmotionally engagingDelightfulEasy to useInnovative

08 — The product

Thirty screens,
clickable end to end

The final concept covers the scenarios that matter most, built as a clickable prototype in Figma so the experience could be judged by using it rather than by reviewing it.

Enrolment, in full

Welcome→Scan ID→Capture face→Confirm details→Nice to meet you

Identity checks are where most banks lose people, so this is the part that gets the most warmth — the app asks you to smile at it, shows you what it read, and lets you correct it before anything is committed.

And the rest of the bank

Accounts & balancesDebit, credit & salary cardsTransfer with purpose Transaction historySpending by categoryReports InsuranceLoansScheduled paymentsProfile & settings

Small thing, large effect: a transfer asks what it is for — car, business, education, electronics, health, loan. It costs one tap and it is the reason the spending breakdown is worth looking at later. Most apps make you categorise afterwards, which is to say never.

What I took from it

Feeling is a requirement, not a finish

If the emotional target is not written down next to the functional ones, it gets negotiated away in the first review. We wrote ours down: mind-blowing, emotionally engaging, delightful, easy to use, innovative.

Simplify the structure, not the product

Removing the navigation menu while keeping every banking function is harder than cutting features, and it is the only version of simplicity a bank can actually ship.

Let card sorting overrule your instinct

The architecture that felt right to me and the one people built with their own hands were not the same. Theirs won, and navigation stopped being a problem.

Teach once rather than clutter forever

A usability failure is not automatically an argument for another control on the screen. Sometimes the cheapest fix for everyone is one tip, shown one time.

Luxury is consistency under pressure

Anyone can make a home screen look expensive. The product is judged on the confirmation, the error, the empty state and the receipt.

The bigger picture

Spark Bank was never trying to be the perfect banking solution. It was an argument that the next advantage in financial products is not another feature — it is designing for how people feel while they use their own money. That argument is easier to make now than it was in 2021, and it is the one I have been making in every financial product since.

Full-scale banking underneath. Nothing in the way on top.

Ask people how it feels, not what they want.
Build the structure from their heads, not yours.
Earn the restraint before you spend it.
And make it worth opening on a day with nothing to do.

Next case studyDDSC Wallet Digital AED Back toSelected work All four products

Money makes people nervous. My job is to design the moment that nervousness turns into confidence.

SelectedWork

Interrogate

Frame

Build

Systematize

A designer who ships, and a builder who still argues about kerning.

Making global impact traceable

A global funding journeywith limited visibility

Transparency

Settlement delays

Transaction constraints

Cost of moving money

Why blockchain —and why not as a trend

Traceability

Speed

Programmability

Lower overhead

Designing for an ecosystem,not a single user

Donors

Implementing partners

Leadership

Finance & compliance

Three principlesheld the concept together

Make money movement visible

Hide unnecessary complexity

Connect transactions to impact

The blockchain stays underneath. The product speaks the user’s language.

The architecture is a setof questions, not a menu

“What is happening with the money?”

“Where is the money?”

“What happened to this payment?”

“What is this money funding?”

“What did the money achieve?”

“Who is involved?”

Trust over technology

Familiar financial patterns

Transparency without overload

A simple loop,run rigorously

Ask the right questions

Understand the problem

Research & analyze

Prototype

Test with stakeholders

Iterate

Ship

Track & Trace for a national medicine supply chain

A medicine’s journey wasdifficult to see end-to-end

Government & regulators

Manufacturers

Distributors & suppliers

Healthcare facilities

Identity

Location

History

From product identity to traceability

Before designing,I went into discovery

The product had to understandevents, not just screens

Making a complex supplychain understandable

The design isn’t finished whenthe Figma file is finished

So the work ran as a loop, not a handoff

What made this hard

Domain complexity

Multiple mental models

Physical world × digital world

Complex products need simple mental models

Enterprise UX is systems design

Design doesn’t stop at handoff

Technology should serve the workflow

A digital AED wallet for 24/7 money movement

Money moves globally.Infrastructure doesn’t always keep up.

Designing a wallet is easy.Designing one people trustwith their money is not.

Simplicity

Transparency

Security

Compliance

Technical feasibility

Business objectives

Individuals

Businesses

Selected
Work

A global funding journey
with limited visibility

Why blockchain —
and why not as a trend

Designing for an ecosystem,
not a single user

Three principles
held the concept together

The architecture is a set
of questions, not a menu

A simple loop,
run rigorously

A medicine’s journey was
difficult to see end-to-end

Before designing,
I went into discovery

The product had to understand
events, not just screens

Making a complex supply
chain understandable

The design isn’t finished when
the Figma file is finished

Money moves globally.
Infrastructure doesn’t always keep up.

Designing a wallet is easy.
Designing one people trust
with their money is not.

Blockchain gives you data.
It doesn’t give you understanding.

I didn’t settle on
the first workflow

You cannot design for a feeling
you have not heard described

An empathy map for each persona,
to find out what the interview left out

Everything we had learned,
merged into one picture

The decision the whole
product rests on: no menu

You cannot colour in
a wireframe and call it a feeling

Thirty screens,
clickable end to end