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.

Selected
Work

Six 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 working across Web3 wallets, challenger banking and enterprise SaaS. I design the system, then build the prototype that proves it, usually in the same week.

Figma for the thinking. HTML, CSS and JavaScript for the truth. Everything you are scrolling through right now is hand-built — the portrait above is 70,000 GPU particles reading a photograph.

Product design

Design systems

High-fidelity prototyping

Interaction & motion

Front-end craft

Research & testing

0Flagship products

0Industries, in depth

0Tokens in the last system I shipped

∞Iterations before it feels right

hi@aamir.design

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

Linkedin Email 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 six 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 studyDDSC Wallet Digital AED Back toSelected work All six 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 six 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