Senior Product Designer Web3 · FinTech · Enterprise

I leverage AI to design & develop world-class products

01 Position

Bad UX makes people nervous. My job is to design the moment that nervousness turns into clarity & confidence.

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

My strength lies in reading the room, bridging user needs with business objectives to deliver high-impact solutions with clarity and confidence.

I combine UX strategy, visual design, technical expertise, and business thinking to lead the design and development of digital products that make people’s lives easier and smarter.

Selected
Work

Four products.
Hover to summon · click to open

Method — Design Thinking 01 / 04

Interrogate

Before design begins, I identify the business goal, stakeholder concerns, and trust gaps by understanding real user pain points and support tickets.

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

Frame

I align the team around a clear vision, map end-to-end workflows, and address edge cases early to reduce rework and ensure consistent delivery.

Output — flows, states and the edge cases nobody wants

Build

I leverage AI to turn ideas into high-fidelity prototypes quickly, enabling stakeholders to test, validate, and make informed decisions based on real experiences.

Output — a clickable build, not a deck of rectangles

Systematize

I build scalable design systems with clear documentation, enabling teams to work consistently, independently, and efficiently.

Output — tokens, components, modes, documentation

Drag across the plate

About AAMIR

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.

Turning complexity into clarity and simplicity has always been my priority and is non-negotiable in my dictionary when build world-class complex systems for governments and enterprises.

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.

The product

Three portals,
one chain of custody

Money enters from a donor, is applied for by an organization, is approved, released against evidence, and withdrawn. Each role only ever sees its own step — but every step hands the next one something it can verify. That handover is the product; the screens are just where it surfaces.

One design system, three densities. A donor gets figures and reassurance. A grantee gets forms and status. A reviewer gets tables and verdicts.

Donor portal overview: available USDC balance with a deposit button and wallet address, then tiles for donations, projects, disbursed and withdrawn funds, a second row for actions, rewards, streak and badge, and a carousel of projects to donate to

01 — Overview

The donation is not the end of the story, so the home screen does not say thank you

Four figures answer the question a donor actually carries: what I gave, how many projects it reached, how much has been disbursed, how much has been drawn down. Disbursed and withdrawn are the two most people never get told, so they sit in the same row as the amount given.

The reward tiles — actions, streak, badge — are deliberately a separate row in a different treatment. Motivation data and money data should never be mistaken for each other.

Balance firstLedger rowRewards kept apart

Donation screen for the FIFA Education Fund 2026: amount in USDC with percentage shortcuts, payment method choice between the Global Citizen wallet, card and Google Pay, a donation summary showing amount, fee and rewards, and the project card alongside

02 — Give

The crypto rail is one option among familiar ones, not a conversion funnel

Wallet, card and Google Pay sit at the same level. A donor who has never held a stablecoin is never told they are missing out, and a donor who has one does not have to leave to use it. This was the whole argument for the project: the rail is an implementation detail, and the moment it stops being one you have lost the mainstream donor.

Amount, fee and reward are all stated before the irreversible button — and the fee line says Free rather than leaving it blank, because a blank is read as a hidden cost.

Rails at parityStated feeSummary before commit

Deposit funds screen on bank transfer: amount presets, Global Citizen's own account name, bank and IBAN each with a copy button, fields for the deposited amount and a reference ID, a payment proof upload, and a deposit summary

03 — Deposit

Manual reconciliation is a real constraint, so the form owns it instead of hiding it

A bank transfer does not settle instantly and nothing in the interface can change that. So the screen hands over the account details with a copy button on every field, then asks for the amount actually sent, a reference ID and proof — the three things reconciliation needs.

Pretending this is instant would have produced a cleaner screen and a worse week for whoever matches the payments.

Copy on every fieldReference IDProof upload

Apply for funds form under the FIFA Education Fund, split into Overview, Project Plan and Beneficiaries tabs, with commitment title, description, amount and sector, an eligibility question about whether the request is under half the organization's annual budget, priority, target outcome and expected beneficiaries

01 — Apply

The eligibility question sits before the ask, not after the submission

“Is this under 50% of your annual budget?” is a hard gate for this fund. Asking it on screen one stops a small organization writing a full application it was never eligible for — which is the most expensive thing a grant portal can do to the people it exists to serve.

The application is split across three tabs so a long form has visible progress, and the Submit button stays on screen throughout while Next drives the actual sequence. Grantees can see the finish line without being invited to trip over it.

Gate firstThree-part formVisible finish line

Milestone completion dialog: a milestone description field and three separate upload areas for proofs, spendings and reports, above a button reading submit proofs to get your funds released

02 — Evidence

Three uploads, not one “attach documents”

Proofs, spendings and reports are different artefacts with different reviewers. Collapsing them into one attachment field would have been less work on this screen and far more work on the reviewer's, where someone has to open eleven files to find the receipts.

Naming the three also tells a first-time grantee what evidence actually means here — the form doubles as the brief. And the button says what the upload is for: funds released, not “submit”.

Typed evidenceForm as briefConsequence in the label

Withdraw funds screen: available balance in USDC with its dollar equivalent, a verified Bank of America account, the amount to withdraw with percentage shortcuts, and a withdrawal summary showing a free processing fee and the amount that will be received

03 — Withdraw

For a finance officer, the only number that matters is what lands

The balance is shown in USDC with the dollar figure beside it, the destination account carries a verified badge, and the summary ends on You'll receive rather than on the amount requested. Every other line is working toward that one.

Percentage shortcuts exist because the common case is withdrawing all of it, and typing seven figures by hand is a transcription error waiting to happen.

Dual currencyVerified destinationEnds on what lands

Admin dashboard: donation collected against available funds, counts for campaigns, fund applications, funds to be disbursed and funds in escrow, a recent activity feed, and bordered cards for critical issues and pending actions above organization trend and sector distribution charts

01 — Dashboard

A reviewer's day is driven by exceptions, not totals

Collected against available sits at the top because the gap between them is the operating question. But the two cards that actually start the day — critical issues and pending actions — get their own borders and sit above the charts, away from the metric tiles.

Totals tell you how the programme is doing. Exceptions tell you what to do before lunch. Those are different jobs and they should not share a visual treatment.

Gap over totalExceptions surfacedCharts last

Admin review of a fund application from UNICEF Global for 32.29 million dollars, with approve, reject, on-hold and return actions in the corner, the submitted application fields below, and a milestone schedule

02 — Review

Four verdicts, because most applications are not wrong — they are incomplete

Approve and reject are the obvious two. Return is the one that changes outcomes: a binary gate turns a missing registration document into a rejection, and the organization either reapplies months later or doesn't. On-hold covers the case where the application is fine and the cycle isn't.

The verdict buttons sit top-right, visible from the first scroll, because a reviewer who has already decided should not have to read to the bottom to say so.

Return, not rejectOn-hold for timingVerdict always reachable

Verify milestone dialog: a note that the milestones completed on time, eight document thumbnails labelled proofs, spendings, reports, taxation, legal docs, teams, finances and project plan, and a single button to verify and transfer funds

03 — Verify & release

Money moves from the same screen where the evidence is read

Everything the grantee uploaded comes back sorted by type, each one openable in place. The release button is attached to that review rather than living in a payments queue somewhere else — so approving and paying are one decision with one audit trail, and nobody releases funds against a summary of a summary.

This is the mirror of the grantee's three uploads. The reason that screen asked for typed evidence is so that this one could show it typed.

Evidence in placeRelease at the point of reviewOne audit trail

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

The product

Three roles,
one identity

A manufacturer creates the identity, a supplier carries it, a regulator reads it. Every screen in the platform does one of those three things, and the test for any of them is the same: does the identity survive this step intact?

Which turns most of the design work into a single discipline — derive everything that can be derived, and ask a human only for what the system genuinely cannot know.

Create new case screen in the aggregation section: product, parent ID and GTIN, batch, serial numbers and quantity, repeated for a second product, with an add another product button

01 — Aggregate

A case is rarely one product, so the form repeats instead of flattening

Aggregation is where serialized units become a case and cases become a pallet — the parent–child relationship that makes a recall tractable later. Modelling it as a repeating block with add another product matches what is physically in the box; a single flat list of serials would have been simpler to build and wrong the first time someone packed two SKUs together.

Parent ID and GTIN auto-select from the product. The operator picks a product and a batch; the identifiers assemble themselves.

Parent / childRepeating blockIdentifiers derived

Create shipment screen for a manufacturer: product information with auto-selected GTIN, batch, manufacturing and expiry dates and a quantity field, then order information with supplier, logistics provider, pickup location and dates

02 — Dispatch

In a plant, typing a GTIN is how you lose a batch

Pick the product and the GTIN, batch, manufacturing date and expiry all fill themselves. Supplier email follows the supplier. What is left to type is quantity, locations and dates — the things that genuinely vary per shipment.

Every derived field is a transcription error that cannot happen, and in a traceability system a mistyped identifier is worse than a missing one: it creates a record that looks valid and points nowhere.

Auto-select everythingType only what variesNo silent bad records

Regulator dashboard co-branded with the Social Health Authority: counts for products, manufacturers, suppliers, facilities, batches recalled and a compliance ratio, above earnings and weekly revenue charts, recent batches, daily order traffic, a total recall donut and recently onboarded organizations

01 — Oversight

A regulator's job is the ratio, not the inventory

Products, manufacturers, suppliers and facilities are the scale of the system. Batches recalled and compliance ratio are its health — so they sit in the same row rather than buried in a reports tab, and the recall donut gets its own card showing processed against completed.

The counts tell the Pharmacy and Poisons Board how big the network is. The ratio tells them whether it is working. Both at a glance, in one row, was the whole brief for this screen.

Health beside scaleRecall always visibleOne row, no drilling

Shipment tracker screen with a single search field labelled enter SSCC, serial, GTIN or batch, above a filterable results table of orders with product, GTIN, supplier, quantity and date

02 — Search

Four identifier systems, one field

An inspector standing in a pharmacy has a number — off a carton, a pallet label, a delivery note. Whether it is an SSCC, a serial, a GTIN or a batch is a fact about the packaging hierarchy, not about their question.

Making them choose the type first would be asking the user to know something the system can determine from the string itself. One box, any identifier, and the results narrow from there.

One inputType inferredBuilt for the field

Product tracker for a GTIN: a header strip with shipment ID, order date, type, pickup and delivery locations and dates, then product details with a barcode beside a vertical timeline of manufacturer, supplier and facility hops, each with dispatch date and from and to locations, and parent and child SSCC barcodes

03 — Trace

“Where has this been” is a timeline, not a table

Manufacturer, supplier, facility — each hop with its dispatch date and its from-and-to. A table would have held the same data and answered a different question; the vertical line is what makes the custody chain readable in one pass.

Parent and child SSCC sit side by side because that pairing is how a recall actually propagates: find the child, and the parent tells you what else travelled with it.

Timeline over tableParent beside childReadable in one pass

All shipments table with status tabs, columns for GTIN code, product, ordered by, quantity, a serial numbers column reading counts such as 90 serials with a view link, order date and status pills for pending, active, dispatched and rejected

04 — Scale

Never render five hundred serial numbers in a table cell

The column says 500 Serials · View. At table level the count is the information — it tells you the size of the consignment and whether it matches the quantity beside it. The list itself opens in a searchable dialog, because the only reason to read individual serials is to find one.

This is the recurring problem in serialized traceability: the data is enormous and almost all of it is only interesting as an aggregate until the moment it is not.

Count at table levelList on demandSearchable, not scrollable

Initiate new recall dialog: a batch or lot number selector with product and manufacturer shown as auto-filled, a recall reason text area, and a single initiate recall button, over the recall management table behind it

05 — Recall

Nobody should be choosing a manufacturer from a dropdown during a recall

Select the batch; product and manufacturer fill themselves, because the batch already knows them. The only human input is the reason — and that field is the one the whole record will be judged on later, so it gets the space.

Everything upstream in the platform exists so that this dialog can be three fields long. Aggregation, derived identifiers, the custody timeline: their payoff is a regulator pulling a batch in under a minute without a single chance to name the wrong company.

Batch resolves the restReason gets the roomThree fields under pressure

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.

The screens

Where the restraint
actually went

Deleting the navigation menu only works if every screen knows where it sits. These are the three places a person goes — the account they hold, the money they spent, the thing they want next — and each one had to be reachable without a map.

Salary account screen: tabs for salary, savings and loan, a large amber ring containing the masked account number and a 22,300 AED balance, a transfer button beneath, and three carousel dots

01 — Balance

The balance is a ring, not a number in a header

One figure, centred, inside the form the whole visual language came from — a thing that fills rather than a value that sits. Above it, three account tabs. Below it, one action. That is the entire screen, and with no navigation menu it is also the navigation: you are already where you need to be.

The carousel dots matter more than they look. Accounts are a stack you swipe, not a dropdown you open — one gesture instead of tap, read, choose, confirm.

One figureOne actionSwipe, not select

Cards screen showing three overlapping cards fanned down the screen — a blue debit card, an orange credit card and a mint salary card, each with the cardholder name, number and expiry — above carousel dots

02 — Cards

Cards are objects, so they behave like objects

Three physical cards fanned down the screen, each with its own colour and its own job — debit, credit, salary. You flick through them the way you thumb a wallet.

The alternative was a list of masked numbers with type labels, which is a database view of a wallet. It would have been faster to scan and completely forgettable, and forgettable was the one outcome this product could not afford.

Physical metaphorColour carries roleMemorable over scannable

Select purpose screen for a loan application: a search field above a grid of large tiles for car, home, electronics, insurance, education, business, account, health, loan and credit card

Offers screen headed select product: a search field, a popular section with loan, credit card, account and insurance, and an all products section continuing with credit card, business services, account and investing

01 — Two doors

Borrowing starts with why, not with a product catalogue

A customer knows they need a car. They do not know whether that is a personal loan, an auto lease or a credit facility — and being asked to choose is being asked to do the bank's job. So the purpose grid takes the input they actually have, and the mapping happens behind it.

The catalogue still exists, one tap away, for the people who do know what they want. Two doors into the same place, because the expert and the first-timer are both real and designing only for one of them is how banks end up with a call centre.

Intent over taxonomyCatalogue keptBoth users served

Financial auto lease screen: a dark car photograph with APR, term, deposit and fee listed down the right, a monthly and total toggle with minus and plus controls showing 1385 AED, and a full-width button reading get AED 90,000

02 — Configure

A loan is a configurator, not an application form

APR, term, deposit and fee stay on screen while the minus and plus move the monthly figure. You are not filling in a request and waiting to be told the terms; you are moving one number and watching the other four hold still.

And the button carries the amount — Get AED 90,000 — so the commitment is never abstract. A button that says Continue would have tested the same and meant nothing.

Live termsOne variable at a timeAmount on the button

03 — Confirm

Success states earn their screen

Amount, recipient, receipt, done. The recipient has a face, and that is the whole point of the screen: the fear in a transfer is not that it failed, it is that it went to the wrong person. A name alone does not settle that. A photo does, instantly.

Download receipt sits below the fact and above the dismiss, because the people who need it need it now, and everyone else is already reaching for Done.

Face over nameReceipt before dismissAnswers the real fear

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

Bad UX makes people nervous. My job is to design the moment that nervousness turns into clarity & 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?”

Three portals,one chain of custody

The donation is not the end of the story, so the home screen does not say thank you

The crypto rail is one option among familiar ones, not a conversion funnel

Manual reconciliation is a real constraint, so the form owns it instead of hiding it

The eligibility question sits before the ask, not after the submission

Three uploads, not one “attach documents”

For a finance officer, the only number that matters is what lands

A reviewer's day is driven by exceptions, not totals

Four verdicts, because most applications are not wrong — they are incomplete

Money moves from the same screen where the evidence is read

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

Three roles,one identity

A case is rarely one product, so the form repeats instead of flattening

In a plant, typing a GTIN is how you lose a batch

The only thing the system cannot know is why, so that is the only thing it asks first

The moment the record becomes a physical object

A regulator's job is the ratio, not the inventory

Four identifier systems, one field

“Where has this been” is a timeline, not a table

Never render five hundred serial numbers in a table cell

Nobody should be choosing a manufacturer from a dropdown during a recall

The design isn’t finished whenthe Figma file is finished

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

Three portals,
one chain of custody

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

Three roles,
one identity

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

Where the restraint
actually went