Role: Product & service Designer

Status: Ready for Development

Wakafrica Ecosystem

Synchronizing Cross-Border Commerce

the context.

The African diaspora sends billions home via cash transfers, but lacks control over how funds are spent. The client's vision was to disrupt this model.

The African diaspora sends billions home via cash transfers, but lacks control over how funds are spent. The client's vision was to disrupt this model.

from cash to care

from cash to care

The goal: transforming a financial transaction into a tangible act of care-giving.

The goal: transforming a financial transaction into a tangible act of care-giving.

the challenge.

A single platform served all actors (Buyers, Vendors, Admins, Agents).

This created cognitive overload and operational risks: vendors saw irrelevant data, while buyers faced a raw database interface instead of a shopping experience.

The real challenge was solving

the Monolith Problem

the challenge.

A single platform served all actors (Buyers, Vendors, Admins, Agents).

This created cognitive overload and operational risks: vendors saw irrelevant data, while buyers faced a raw database interface instead of a shopping experience.

The real challenge was solving

the monolith problem.

the technical translation.
the technical translation.

The challenge was not just designing an app, but structurally

unbundling the ecosystem.

How do you transform a single database into two emotionally opposite products?

The legacy backend held raw data but offered zero usability.

I split this monolithic block into distinct experiences, each optimized for a specific user mindset.

How do you transform a single database into two emotionally opposite products?

The legacy backend held raw data but offered zero usability.

I split this monolithic block into distinct experiences, each optimized for a specific user mindset.

architecture as strategy.

Translating complex requirements and

backend constraints into user interfaces.

I first mapped every single touchpoint to ensure the flow of money and goods never broke.

This diagram is the brain of the application.

the unbundling strategy.

vendor side

For the vendor, I extracted an operational dashboard from the monolith, hiding shopping distractions to focus strictly on stock constraints.

Since inventory levels were a rigid contractual obligation, I designed the interface as a preventative system: it hides distractions to strictly enforce stock limits and block errors.

buyer side

experience strategy.

The goal was to make sending goods across borders as immediate as a local purchase.

I focused on eliminating administrative friction to prioritize speed.

the unbundling strategy.

vendor side

For the vendor, I extracted an operational dashboard from the monolith, hiding shopping distractions to focus strictly on stock constraints.


Since inventory levels were a rigid contractual obligation, I designed the interface as a preventative system: it hides distractions to strictly enforce stock limits and block errors.

managing friction.

guided onboarding & compliance

The business model enforced a strict "hard gate": no shop could go live until they completed a substantial catalog upload.


This barrier created a critical risk of abandonment.

Unable to remove the rule, I mitigated the friction by breaking the task into micro-steps with a dynamic progress bar.


The interface transforms a tedious contractual obligation into a guided mission, significantly reducing cognitive load.

managing friction.

guided onboarding & compliance

The business model enforced a strict "hard gate": no shop could go live until they completed a substantial catalog upload.


This barrier created a critical risk of abandonment.


Unable to remove the rule, I mitigated the friction by breaking the task into micro-steps with a dynamic progress bar.

The interface transforms a tedious contractual obligation into a guided mission, significantly reducing cognitive load.

the technical transaltion.

La sfida non era disegnare un'app, ma

unbundling the ecosystem.

How do you transform a single database into two emotionally opposite products?

The legacy backend held raw data (e.g., "User Level 3") but offered zero usability.

I split this monolithic block into distinct experiences, each optimized for a specific user mindset.

architecture as strategy.

Translating complex requirements and

backend constraints into user interfaces.

I first mapped every single touchpoint to ensure the flow of money and goods never broke.

This diagram is the brain of the application.

Per il venditore, ho estratto dal monolite una Dashboard operativa, nascondendo la distrazione dello shopping e focalizzandomi sui vincoli di stock."

vendor side

For the vendor, I extracted an operational dashboard from the monolith, hiding shopping distractions to focus strictly on stock constraints.


Since inventory levels were a rigid contractual obligation, I designed the interface as a preventative system: it hides distractions to strictly enforce stock limits and block errors.

the unbundling strategy.

interruptive design

for error prevention

I implemented a "Takeover" pattern that locks the interface with a full-screen alarm and a persistent ringtone when a new order arrives.

This forces immediate attention, ensuring no revenue is lost to environmental distractions.

In noisy markets, standard notifications are ignored.

Since vendors are contractually forbidden from cancelling orders, missing a request means a service failure.

In noisy markets, standard notifications are ignored. Since vendors are contractually forbidden from cancelling orders, missing a request means a service failure.

The component library acts as the bridge.

It allows the Vendor Dashboard (functional, dense) and the Buyer App (emotional, simple) to share the same DNA, ensuring brand integrity while respecting the unique context of each user.

In noisy markets, standard notifications are ignored. Since vendors are contractually forbidden from cancelling orders, missing a request means a service failure.

interruptive design

shared language for distinct worlds


We needed to split the features, but we couldn't afford to split the identity.


So I built a

for error prevention
scalability & consistency.

I implemented a "Takeover" pattern that locks the interface with a full-screen alarm and a persistent ringtone when a new order arrives.

This forces immediate attention, ensuring no revenue is lost to environmental distractions.

I implemented a "Takeover" pattern that locks the interface with a full-screen alarm and a persistent ringtone when a new order arrives.

This forces immediate attention, ensuring no revenue is lost to environmental distractions.

experience strategy.

buyer side

The goal was to make sending goods across borders as immediate as a local purchase.


I focused on eliminating administrative friction to prioritize speed.

The goal was to make sending goods across borders as immediate as a local purchase.

I focused on eliminating administrative friction to prioritize speed.

experience strategy.
conversion rate optimization.

To maximize recurring transactions, I moved beyond a static menu. The buyer hub is a decision engine designed to


trigger immediate action.

I placed a dynamic Smart Action card in the thumb-zone.


By reminding the user of a past positive impact ("You made Nasha happy"), I leverage emotional engagement to drive retention.


Below, the beneficiary slider allows for quick access, reducing the journey to a single tap.

To maximize recurring transactions, I moved beyond a static menu.


The dashboard is a decision engine designed to

To maximize recurring transactions, I moved beyond a static menu. The dashboard is a

I placed a dynamic Smart Action card in the thumb-zone.


By reminding the user of a past positive impact ("You made Nasha happy"), I leverage emotional engagement to drive retention.


Below, the beneficiary slider allows for quick access, ,n .

conversion rate optimization.

The core challenge was the entry point, so I designed a

dual-path system

where users can either begin by adding a beneficiary (People First) or by browsing the catalog (Product First).


This flexibility aligns with the user's changing intent, making the complex three-party transaction feel like a simple online purchase.

where users can either begin by adding a beneficiary (People First) or by browsing the catalog (Product First).


This flexibility aligns with the user's changing intent, making the complex three-party transaction feel like a simple online purchase.

The core challenge was the entry point, so I designed a

The core challenge was the entry point, so designed a

service design & recovery.

Considering the over-50 demographic of beneficiaries, relying on a single SMS was a risk.


So I designed

Considering the over-50 demographic of beneficiaries, relying on a single SMS was a risk.


I designed

The pickup code is sent simultaneously to both the beneficiary and the buyer.


This dual-delivery acts as a safety net: if the recipient accidentally deletes or loses the message, the buyer retains a backup copy to share manually, ensuring the transaction is never lost due to user error.

redundancy as a feature.

redundancy as a feature.

The pickup code is sent simultaneously to both the beneficiary and the buyer.


This dual-delivery acts as a safety net: if the recipient accidentally deletes or loses the message, the buyer retains a backup copy to share manually, ensuring the transaction is never lost due to user error.

Considering the over-50 demographic of beneficiaries, relying on a single SMS was a risk.


I designed

The pickup code is sent simultaneously to both the beneficiary and the buyer.


This dual-delivery acts as a safety net: if the recipient accidentally deletes or loses the message, the buyer retains a backup copy to share manually, ensuring the transaction is never lost due to user error.

service design & recovery.
scalability & consistency.

We needed to split the features, but we couldn't afford to split the identity.

So I built a

shared language for distinct worlds

The component library acts as the bridge.

It allows the Vendor Dashboard (functional, dense) and the Buyer App (emotional, simple) to share the same DNA, ensuring brand integrity while respecting the unique context of each user.

By shifting the focus from a simple shopping app to a synchronized two-sided ecosystem I drastically reduced transaction friction, turning a high-risk operational bottleneck into a scalable, trust-based marketplace connecting Europe and Africa.

By shifting the focus from a simple shopping app to a synchronized two-sided ecosystem I drastically reduced transaction friction, turning a high-risk operational bottleneck into a scalable, trust-based marketplace connecting Europe and Africa.