3 years designing across Afriex
Afriex is a money transfer app for Africans at home and abroad. People send between the US, the UK, Canada, Europe and countries across Africa, in both directions, and hold balances in more than one currency. Its users are careful with money apps and wary of change.
When I joined in May 2022 the app had the right pieces: sign-up, verification, transfers, receipts. What it lacked was reassurance at the moments that mattered most: why we need this document, what will arrive, where the money is now. This case study follows the app in the order people meet it, from the first screen to the receipt, then the services that grew around the wallet, the business platform and the tools behind the app, and the system and habits that held 3 years of work together.
For most of that time I was the only product designer. The decisions were mine; the work was shared: the previous product designer supported my handover, Tobi co-created the design system with me from August 2022 to 2023, compliance reviewed verification before high fidelity, a lead engineer codified the system, and support and operations were the daily users of the internal tools. How that worked is in the last section.
Getting in, and getting back in
Before someone could move money, they needed to create an account. Returning users needed a straightforward way back in. The original sign-up was one long form, login required email and password each time, and sending money required no confirmation at all. Far more people downloaded the app than finished signing up; the sign-up funnel in Retool, conversations with support and compliance reviews told us where and why. 5 things we knew shaped the redesign.
Sign-up
Coming back
A funnel we could read step by step, and a phone number from the first screen so support could follow up with people who stopped. People leave sign-up with biometrics set, the country chosen and the account secured. With a PIN at confirmation and biometrics for repeat use, completion held while exposure dropped. Activation was one of the weekly metrics I tracked from then on.
Splitting one form into single-task screens makes the flow longer on paper. Because abandonment clustered around cognitive load rather than step count, the extra taps cost less than the confusion they replaced, and visible progress kept the perceived effort low.
Verification that explains itself
With an account open, the next step was proving who they were, and a careful user reasonably asks why a money app needs their ID. In 2022 only about 15% of people who signed up completed verification. The flow opened with a demand, gave no sense of the steps ahead and did not say which documents were accepted. Interviews across Nigeria, Ghana, Kenya, the UK, the US and Canada showed the same hesitation with different documents behind it, so the redesign explains itself in each market's own terms, starting with why.
The introduction
Why, what it unlocks, how long it takes.
A demand, with no sense of the steps ahead.
The local ID
A date of birth field with no explanation.
From about 15% of sign-ups when I joined to nearly 30% by the time I left, watched week by week and market by market in Amplitude and Retool. The metric I followed most closely, because it gated everything after it.
Explaining verification up front costs seconds for people who would have finished anyway. I took that cost deliberately: the people we were losing were the ones who did not understand why we were asking, and they were worth far more than the seconds.
The wallet: the screen people saw most
Once verified, people land on the wallet every time they open the app. They expect to see their balances at a glance and to start whatever they came to do from there. Across 4 versions the wallet's structure did not change: header, actions, wallets, then what is new. What changed was what the actions were, and where sending starts: by 2025 Send sits on the wallet itself, so the next section begins where this one ends.
Pick a year
Inside a wallet
Each wallet carries its own actions, account details and transactions.
Sending money, and knowing what arrives
People reach the send screen with an amount in mind and one question: what will arrive? When I joined, the screen showed the amount and the receive amount with the rate in small print, and fees and the funding source appeared later in the flow. It changed more than any other screen, and each version answered a question people were asking support: what is the rate, what is the fee, what will they get. The questions came from support tickets and from interviews in sending and receiving countries; the answers were checked in Amplitude and UXCam after each release.
One screen, 2022 to 2025
Reported by Afriex 3 weeks after the Dynamic Pricing launch. The pricing was the initiative, led with product, engineering and growth; the send screen and the rate presentation are where people saw it, and where the struck-through standard rate made the discount legible before anyone typed an amount.
Removing the bottom navigation during a transfer locks people inside the task, which is the point. It demands a clear exit, so every step has an explicit cancel and leaving never loses work.
The whole flow, from the amount to the receipt
Receipts that answer 'did it work?'
After sending, people want to know where the money is now, and often need to show the person receiving it. The old receipt listed what was sent but not where the money was, so people asked support. Session recordings showed people reopening the same receipt several times; the receipt became the status view they were looking for.
Receipt
Activity
The question 'did it work?' stopped arriving in support tickets as often, because the answer now lived in the product. Receipts became something people could send to the recipient as proof, and transaction success, the company's measure, reached 98.9% as failures became visible and fixable rather than silent.
Cards, recurring transfers, rewards and credit
Some needs went beyond a single transfer: paying for services abroad, sending the same amount every month, being rewarded for using the app, building a credit history in a new country. Each arrived as a card below the balances, with its own small flow, its own reason to exist and its own result. Interviews in each market said what people needed; usage after launch said whether we were right. Money requests and payment links were explored and did not ship.
Virtual card
Scheduled transfers
Rewards and referrals
Credit builder
Virtual card
International spending for people in Africa, and Nigerians above all, whose bank cards were blocked from paying for services abroad. The card sits on the USD wallet balance, so a funded balance has a daily use.
Scheduled transfers
For the people who send the same amount on the same day every month. Useful to them, and usage stayed narrow: interviews had told us most sending is prompted by a call or a need rather than a calendar, and the numbers after launch agreed.
Rewards and referrals
Rewards tied to actions that matter: coupons, gift cards, points from real transactions, and referrals that paid out only once the new person had signed up and used Afriex, slower than paying on sign-up and cheaper. Referral conversion was one of the weekly metrics, so the change could be read rather than guessed.
Credit builder
For new immigrants who arrive with no credit history and need one to rent, borrow or get a phone contract. A $5 monthly subscription that reports transactions to credit bureaus, so settling in and building a score happen together.
Afriex Business, and the tools behind the app
Businesses needed to move larger amounts with a record of each step, and the people behind the app needed tools built for their day. The same instinct applied on both sides: say what is happening, and make it traceable. I defined the business platform with product and engineering from the data model up, and designed the operations dashboard and help centre with the support and operations teams who would work in them.
Home, tracking, team roles, business verification
Click a screen to see it at full size.
Operations dashboard
Transactions, users, KYC and referrals with search, date filters and status; light and dark modes; 2FA on admin login.
Support site
Structured articles, a ticket form and ticket status, in the brand.
A new revenue surface: structured, higher-value business transfers beyond individual remittances, with compliance intake, history and progress built in from the data model up. For operations and support, restructured transaction data, filters and statuses made issues faster to find and resolve, and after the help centre launched, general inquiries fell so the team could spend its time on the serious cases.
Additional checks and a confirmation on every business transfer make it slower than a personal send. Traceability came before speed, because a business needs to trace the payment later.
One system, and how the work was shared
I inherited a UI guide from the previous product designer. With Tobi, from August 2022, I built the fuller system: foundations, every input and control the app needed, and the currency and flag assets that let a new corridor be a row rather than a redesign. The harder part was getting it into the codebase and keeping it there.
Parts of the system
Click a part to see it at full size.
From 85% in December 2023, measured in my own tracker. New screens composed from shared parts instead of being redrawn, which is what made the delivery cadence below possible.
Building a system as the only designer meant weeks where no new feature shipped. I paid that cost early: every screen after it composed from shared parts, and the speed it bought never had to be bought again.
Never working alone
Every flow above was shaped with the people who owned the risk, wrote the code, answered the tickets and set the priorities. The research behind them, interviews, surveys, town halls, competitive audits and behavioural analytics, sits in the sections where it did its work; this is the rest of the machinery.
With compliance
Verification and business flows were reviewed with risk and compliance in low fidelity, before anything was polished, so their requirements set the order of steps rather than arriving as late changes.
With customer support
Conversations with support shaped onboarding and recovery: what people asked in their first days, where they got stuck, and how a phone number early on let support reach them. Support and operations were also the daily users of the dashboard and help centre, so they reviewed those with me.
With engineering
Every flow shipped as a spec with states, empty and error screens, and a fallback for each assumption. Design QA before each release was a joint session on staging against the spec, not tickets over a wall.
Priorities and decisions
In Monday leadership meetings I worked with product, engineering, growth, compliance, finance and support leads on priorities and trade-offs, with the week's metrics on the table: activation, KYC success, referral conversion, transaction success. This is where I made the case for the design system and the onboarding changes.
Systems I established
A weekly design report, a monthly design update to the whole company and the company's first monthly NPS programme kept design visible and customer feedback in the room. Recorded walkthroughs let people follow complex work at their own pace.
Delivery cadence
Delivery cadence after reusable patterns and a structured handoff, from my own experience of the release cycle.
3 years. A few things stuck.
Trust is built in layers
No single screen builds trust. It is the cumulative effect of consistency, feedback and reliability across every interaction, every market and every edge case.
Systems outlive any single feature
The design system, the QA process and owning the metrics had compounding returns. The less visible work made everything else possible.
Compliance is a design partner, not a gate
Working with risk as collaborators rather than a final approval step changed what I could ship, and how fast.
Konga: designing at scale in e-commerce
Consumer, merchants, payments and platform, 2021 to 2025.
3 years designing across Afriex
Afriex is a money transfer app for Africans at home and abroad. People send between the US, the UK, Canada, Europe and countries across Africa, in both directions, and hold balances in more than one currency. Its users are careful with money apps and wary of change.
When I joined in May 2022 the app had the right pieces: sign-up, verification, transfers, receipts. What it lacked was reassurance at the moments that mattered most: why we need this document, what will arrive, where the money is now. This case study follows the app in the order people meet it, from the first screen to the receipt, then the services that grew around the wallet, the business platform and the tools behind the app, and the system and habits that held 3 years of work together.
For most of that time I was the only product designer. The decisions were mine; the work was shared: the previous product designer supported my handover, Tobi co-created the design system with me from August 2022 to 2023, compliance reviewed verification before high fidelity, a lead engineer codified the system, and support and operations were the daily users of the internal tools. How that worked is in the last section.
Getting in, and getting back in
Before someone could move money, they needed to create an account. Returning users needed a straightforward way back in. The original sign-up was one long form, login required email and password each time, and sending money required no confirmation at all. Far more people downloaded the app than finished signing up; the sign-up funnel in Retool, conversations with support and compliance reviews told us where and why. 5 things we knew shaped the redesign.
Sign-up
Coming back
A funnel we could read step by step, and a phone number from the first screen so support could follow up with people who stopped. People leave sign-up with biometrics set, the country chosen and the account secured. With a PIN at confirmation and biometrics for repeat use, completion held while exposure dropped. Activation was one of the weekly metrics I tracked from then on.
Splitting one form into single-task screens makes the flow longer on paper. Because abandonment clustered around cognitive load rather than step count, the extra taps cost less than the confusion they replaced, and visible progress kept the perceived effort low.
Verification that explains itself
With an account open, the next step was proving who they were, and a careful user reasonably asks why a money app needs their ID. In 2022 only about 15% of people who signed up completed verification. The flow opened with a demand, gave no sense of the steps ahead and did not say which documents were accepted. Interviews across Nigeria, Ghana, Kenya, the UK, the US and Canada showed the same hesitation with different documents behind it, so the redesign explains itself in each market's own terms, starting with why.
The introduction
Why, what it unlocks, how long it takes.
A demand, with no sense of the steps ahead.
The local ID
A date of birth field with no explanation.
From about 15% of sign-ups when I joined to nearly 30% by the time I left, watched week by week and market by market in Amplitude and Retool. The metric I followed most closely, because it gated everything after it.
Explaining verification up front costs seconds for people who would have finished anyway. I took that cost deliberately: the people we were losing were the ones who did not understand why we were asking, and they were worth far more than the seconds.
The wallet: the screen people saw most
Once verified, people land on the wallet every time they open the app. They expect to see their balances at a glance and to start whatever they came to do from there. Across 4 versions the wallet's structure did not change: header, actions, wallets, then what is new. What changed was what the actions were, and where sending starts: by 2025 Send sits on the wallet itself, so the next section begins where this one ends.
Pick a year
Inside a wallet
Each wallet carries its own actions, account details and transactions.
Sending money, and knowing what arrives
People reach the send screen with an amount in mind and one question: what will arrive? When I joined, the screen showed the amount and the receive amount with the rate in small print, and fees and the funding source appeared later in the flow. It changed more than any other screen, and each version answered a question people were asking support: what is the rate, what is the fee, what will they get. The questions came from support tickets and from interviews in sending and receiving countries; the answers were checked in Amplitude and UXCam after each release.
One screen, 2022 to 2025
Reported by Afriex 3 weeks after the Dynamic Pricing launch. The pricing was the initiative, led with product, engineering and growth; the send screen and the rate presentation are where people saw it, and where the struck-through standard rate made the discount legible before anyone typed an amount.
Removing the bottom navigation during a transfer locks people inside the task, which is the point. It demands a clear exit, so every step has an explicit cancel and leaving never loses work.
The whole flow, from the amount to the receipt
Receipts that answer 'did it work?'
After sending, people want to know where the money is now, and often need to show the person receiving it. The old receipt listed what was sent but not where the money was, so people asked support. Session recordings showed people reopening the same receipt several times; the receipt became the status view they were looking for.
Receipt
Activity
The question 'did it work?' stopped arriving in support tickets as often, because the answer now lived in the product. Receipts became something people could send to the recipient as proof, and transaction success, the company's measure, reached 98.9% as failures became visible and fixable rather than silent.
Cards, recurring transfers, rewards and credit
Some needs went beyond a single transfer: paying for services abroad, sending the same amount every month, being rewarded for using the app, building a credit history in a new country. Each arrived as a card below the balances, with its own small flow, its own reason to exist and its own result. Interviews in each market said what people needed; usage after launch said whether we were right. Money requests and payment links were explored and did not ship.
Virtual card
Scheduled transfers
Rewards and referrals
Credit builder
Virtual card
International spending for people in Africa, and Nigerians above all, whose bank cards were blocked from paying for services abroad. The card sits on the USD wallet balance, so a funded balance has a daily use.
Scheduled transfers
For the people who send the same amount on the same day every month. Useful to them, and usage stayed narrow: interviews had told us most sending is prompted by a call or a need rather than a calendar, and the numbers after launch agreed.
Rewards and referrals
Rewards tied to actions that matter: coupons, gift cards, points from real transactions, and referrals that paid out only once the new person had signed up and used Afriex, slower than paying on sign-up and cheaper. Referral conversion was one of the weekly metrics, so the change could be read rather than guessed.
Credit builder
For new immigrants who arrive with no credit history and need one to rent, borrow or get a phone contract. A $5 monthly subscription that reports transactions to credit bureaus, so settling in and building a score happen together.
Afriex Business, and the tools behind the app
Businesses needed to move larger amounts with a record of each step, and the people behind the app needed tools built for their day. The same instinct applied on both sides: say what is happening, and make it traceable. I defined the business platform with product and engineering from the data model up, and designed the operations dashboard and help centre with the support and operations teams who would work in them.
Home, tracking, team roles, business verification
Click a screen to see it at full size.
Operations dashboard
Transactions, users, KYC and referrals with search, date filters and status; light and dark modes; 2FA on admin login.
Support site
Structured articles, a ticket form and ticket status, in the brand.
A new revenue surface: structured, higher-value business transfers beyond individual remittances, with compliance intake, history and progress built in from the data model up. For operations and support, restructured transaction data, filters and statuses made issues faster to find and resolve, and after the help centre launched, general inquiries fell so the team could spend its time on the serious cases.
Additional checks and a confirmation on every business transfer make it slower than a personal send. Traceability came before speed, because a business needs to trace the payment later.
One system, and how the work was shared
I inherited a UI guide from the previous product designer. With Tobi, from August 2022, I built the fuller system: foundations, every input and control the app needed, and the currency and flag assets that let a new corridor be a row rather than a redesign. The harder part was getting it into the codebase and keeping it there.
Parts of the system
Click a part to see it at full size.
From 85% in December 2023, measured in my own tracker. New screens composed from shared parts instead of being redrawn, which is what made the delivery cadence below possible.
Building a system as the only designer meant weeks where no new feature shipped. I paid that cost early: every screen after it composed from shared parts, and the speed it bought never had to be bought again.
Never working alone
Every flow above was shaped with the people who owned the risk, wrote the code, answered the tickets and set the priorities. The research behind them, interviews, surveys, town halls, competitive audits and behavioural analytics, sits in the sections where it did its work; this is the rest of the machinery.
With compliance
Verification and business flows were reviewed with risk and compliance in low fidelity, before anything was polished, so their requirements set the order of steps rather than arriving as late changes.
With customer support
Conversations with support shaped onboarding and recovery: what people asked in their first days, where they got stuck, and how a phone number early on let support reach them. Support and operations were also the daily users of the dashboard and help centre, so they reviewed those with me.
With engineering
Every flow shipped as a spec with states, empty and error screens, and a fallback for each assumption. Design QA before each release was a joint session on staging against the spec, not tickets over a wall.
Priorities and decisions
In Monday leadership meetings I worked with product, engineering, growth, compliance, finance and support leads on priorities and trade-offs, with the week's metrics on the table: activation, KYC success, referral conversion, transaction success. This is where I made the case for the design system and the onboarding changes.
Systems I established
A weekly design report, a monthly design update to the whole company and the company's first monthly NPS programme kept design visible and customer feedback in the room. Recorded walkthroughs let people follow complex work at their own pace.
Delivery cadence
Delivery cadence after reusable patterns and a structured handoff, from my own experience of the release cycle.
3 years. A few things stuck.
Trust is built in layers
No single screen builds trust. It is the cumulative effect of consistency, feedback and reliability across every interaction, every market and every edge case.
Systems outlive any single feature
The design system, the QA process and owning the metrics had compounding returns. The less visible work made everything else possible.
Compliance is a design partner, not a gate
Working with risk as collaborators rather than a final approval step changed what I could ship, and how fast.
Konga: designing at scale in e-commerce
Consumer, merchants, payments and platform, 2021 to 2025.
3 years designing across Afriex
Afriex is a money transfer app for Africans at home and abroad. People send between the US, the UK, Canada, Europe and countries across Africa, in both directions, and hold balances in more than one currency. Its users are careful with money apps and wary of change.
When I joined in May 2022 the app had the right pieces: sign-up, verification, transfers, receipts. What it lacked was reassurance at the moments that mattered most: why we need this document, what will arrive, where the money is now. This case study follows the app in the order people meet it, from the first screen to the receipt, then the services that grew around the wallet, the business platform and the tools behind the app, and the system and habits that held 3 years of work together.
For most of that time I was the only product designer. The decisions were mine; the work was shared: the previous product designer supported my handover, Tobi co-created the design system with me from August 2022 to 2023, compliance reviewed verification before high fidelity, a lead engineer codified the system, and support and operations were the daily users of the internal tools. How that worked is in the last section.
Getting in, and getting back in
Before someone could move money, they needed to create an account. Returning users needed a straightforward way back in. The original sign-up was one long form, login required email and password each time, and sending money required no confirmation at all. Far more people downloaded the app than finished signing up; the sign-up funnel in Retool, conversations with support and compliance reviews told us where and why. 5 things we knew shaped the redesign.
Sign-up
Coming back
A funnel we could read step by step, and a phone number from the first screen so support could follow up with people who stopped. People leave sign-up with biometrics set, the country chosen and the account secured. With a PIN at confirmation and biometrics for repeat use, completion held while exposure dropped. Activation was one of the weekly metrics I tracked from then on.
Splitting one form into single-task screens makes the flow longer on paper. Because abandonment clustered around cognitive load rather than step count, the extra taps cost less than the confusion they replaced, and visible progress kept the perceived effort low.
Verification that explains itself
With an account open, the next step was proving who they were, and a careful user reasonably asks why a money app needs their ID. In 2022 only about 15% of people who signed up completed verification. The flow opened with a demand, gave no sense of the steps ahead and did not say which documents were accepted. Interviews across Nigeria, Ghana, Kenya, the UK, the US and Canada showed the same hesitation with different documents behind it, so the redesign explains itself in each market's own terms, starting with why.
The introduction
Why, what it unlocks, how long it takes.
A demand, with no sense of the steps ahead.
The local ID
A date of birth field with no explanation.
From about 15% of sign-ups when I joined to nearly 30% by the time I left, watched week by week and market by market in Amplitude and Retool. The metric I followed most closely, because it gated everything after it.
Explaining verification up front costs seconds for people who would have finished anyway. I took that cost deliberately: the people we were losing were the ones who did not understand why we were asking, and they were worth far more than the seconds.
The wallet: the screen people saw most
Once verified, people land on the wallet every time they open the app. They expect to see their balances at a glance and to start whatever they came to do from there. Across 4 versions the wallet's structure did not change: header, actions, wallets, then what is new. What changed was what the actions were, and where sending starts: by 2025 Send sits on the wallet itself, so the next section begins where this one ends.
Pick a year
Inside a wallet
Each wallet carries its own actions, account details and transactions.
Sending money, and knowing what arrives
People reach the send screen with an amount in mind and one question: what will arrive? When I joined, the screen showed the amount and the receive amount with the rate in small print, and fees and the funding source appeared later in the flow. It changed more than any other screen, and each version answered a question people were asking support: what is the rate, what is the fee, what will they get. The questions came from support tickets and from interviews in sending and receiving countries; the answers were checked in Amplitude and UXCam after each release.
One screen, 2022 to 2025
Reported by Afriex 3 weeks after the Dynamic Pricing launch. The pricing was the initiative, led with product, engineering and growth; the send screen and the rate presentation are where people saw it, and where the struck-through standard rate made the discount legible before anyone typed an amount.
Removing the bottom navigation during a transfer locks people inside the task, which is the point. It demands a clear exit, so every step has an explicit cancel and leaving never loses work.
The whole flow, from the amount to the receipt
Receipts that answer 'did it work?'
After sending, people want to know where the money is now, and often need to show the person receiving it. The old receipt listed what was sent but not where the money was, so people asked support. Session recordings showed people reopening the same receipt several times; the receipt became the status view they were looking for.
Receipt
Activity
The question 'did it work?' stopped arriving in support tickets as often, because the answer now lived in the product. Receipts became something people could send to the recipient as proof, and transaction success, the company's measure, reached 98.9% as failures became visible and fixable rather than silent.
Cards, recurring transfers, rewards and credit
Some needs went beyond a single transfer: paying for services abroad, sending the same amount every month, being rewarded for using the app, building a credit history in a new country. Each arrived as a card below the balances, with its own small flow, its own reason to exist and its own result. Interviews in each market said what people needed; usage after launch said whether we were right. Money requests and payment links were explored and did not ship.
Virtual card
Scheduled transfers
Rewards and referrals
Credit builder
Virtual card
International spending for people in Africa, and Nigerians above all, whose bank cards were blocked from paying for services abroad. The card sits on the USD wallet balance, so a funded balance has a daily use.
Scheduled transfers
For the people who send the same amount on the same day every month. Useful to them, and usage stayed narrow: interviews had told us most sending is prompted by a call or a need rather than a calendar, and the numbers after launch agreed.
Rewards and referrals
Rewards tied to actions that matter: coupons, gift cards, points from real transactions, and referrals that paid out only once the new person had signed up and used Afriex, slower than paying on sign-up and cheaper. Referral conversion was one of the weekly metrics, so the change could be read rather than guessed.
Credit builder
For new immigrants who arrive with no credit history and need one to rent, borrow or get a phone contract. A $5 monthly subscription that reports transactions to credit bureaus, so settling in and building a score happen together.
Afriex Business, and the tools behind the app
Businesses needed to move larger amounts with a record of each step, and the people behind the app needed tools built for their day. The same instinct applied on both sides: say what is happening, and make it traceable. I defined the business platform with product and engineering from the data model up, and designed the operations dashboard and help centre with the support and operations teams who would work in them.
Home, tracking, team roles, business verification
Click a screen to see it at full size.
Operations dashboard
Transactions, users, KYC and referrals with search, date filters and status; light and dark modes; 2FA on admin login.
Support site
Structured articles, a ticket form and ticket status, in the brand.
A new revenue surface: structured, higher-value business transfers beyond individual remittances, with compliance intake, history and progress built in from the data model up. For operations and support, restructured transaction data, filters and statuses made issues faster to find and resolve, and after the help centre launched, general inquiries fell so the team could spend its time on the serious cases.
Additional checks and a confirmation on every business transfer make it slower than a personal send. Traceability came before speed, because a business needs to trace the payment later.
One system, and how the work was shared
I inherited a UI guide from the previous product designer. With Tobi, from August 2022, I built the fuller system: foundations, every input and control the app needed, and the currency and flag assets that let a new corridor be a row rather than a redesign. The harder part was getting it into the codebase and keeping it there.
Parts of the system
Click a part to see it at full size.
From 85% in December 2023, measured in my own tracker. New screens composed from shared parts instead of being redrawn, which is what made the delivery cadence below possible.
Building a system as the only designer meant weeks where no new feature shipped. I paid that cost early: every screen after it composed from shared parts, and the speed it bought never had to be bought again.
Never working alone
Every flow above was shaped with the people who owned the risk, wrote the code, answered the tickets and set the priorities. The research behind them, interviews, surveys, town halls, competitive audits and behavioural analytics, sits in the sections where it did its work; this is the rest of the machinery.
With compliance
Verification and business flows were reviewed with risk and compliance in low fidelity, before anything was polished, so their requirements set the order of steps rather than arriving as late changes.
With customer support
Conversations with support shaped onboarding and recovery: what people asked in their first days, where they got stuck, and how a phone number early on let support reach them. Support and operations were also the daily users of the dashboard and help centre, so they reviewed those with me.
With engineering
Every flow shipped as a spec with states, empty and error screens, and a fallback for each assumption. Design QA before each release was a joint session on staging against the spec, not tickets over a wall.
Priorities and decisions
In Monday leadership meetings I worked with product, engineering, growth, compliance, finance and support leads on priorities and trade-offs, with the week's metrics on the table: activation, KYC success, referral conversion, transaction success. This is where I made the case for the design system and the onboarding changes.
Systems I established
A weekly design report, a monthly design update to the whole company and the company's first monthly NPS programme kept design visible and customer feedback in the room. Recorded walkthroughs let people follow complex work at their own pace.
Delivery cadence
Delivery cadence after reusable patterns and a structured handoff, from my own experience of the release cycle.
3 years. A few things stuck.
Trust is built in layers
No single screen builds trust. It is the cumulative effect of consistency, feedback and reliability across every interaction, every market and every edge case.
Systems outlive any single feature
The design system, the QA process and owning the metrics had compounding returns. The less visible work made everything else possible.
Compliance is a design partner, not a gate
Working with risk as collaborators rather than a final approval step changed what I could ship, and how fast.
Konga: designing at scale in e-commerce
Consumer, merchants, payments and platform, 2021 to 2025.