Making global payments work like local ones.
Designing a financial ecosystem that connects digital assets, local payment methods, merchants, and liquidity providers through clear, secure, and trustworthy experiences.
ROLE
Brand & Product Designer
· Product Strategist
MARKET
Global · USA / Canada
SCOPE
Brand Strategy · Brand Identity · Product Strategy · UX/UI · Financial Systems · Design System
Global commerce was open, Payment access was not
Customers in emerging markets could discover products and services from around the world, but completing the purchase was often much harder.
Many did not have an internationally enabled card or access to a dollar balance. Even when they had the money locally, overseas merchants frequently depended on payment methods and currencies that were unavailable to them.
The barrier was not the customer’s ability to pay. It was the incompatibility between local financial systems and global online commerce.
Friddy created a bridge
Friddy allowed customers to purchase from international merchants using familiar local payment methods and their own currency.
Behind the transaction, the platform coordinated the payment network, liquidity, digital assets, and merchant settlement required to move value between both sides.
The customer paid locally. The merchant received a global payment.
Making global checkout accessible through local payments
Friddy lets customers pay international merchants using familiar local payment methods and their own currency—while the network handles the complexity behind the transaction.
WITHOUT FRIDDY
International checkouts often require payment access that customers in emerging markets do not have.
Local customer
International checkout
No international card
Unsupported payment method
No USD balance
PURCHASE BLOCKED
WITH FRIDDY
Customers pay locally while Friddy coordinates the international transaction.
Local customer
Local payment method
Local currency
FRIDDY PAYMENT NETWORK
International merchant
PURCHASE COMPLETED
MY ROLE
Designing the brand and product as one connected system
As Friddy’s sole designer, I operated with the scope of a founding designer and product lead—working across business definition, brand strategy, product architecture, and hands-on product design.
I translated the company’s financial model into a structured product, defined how its participants and services connected, and carried that direction through the brand, customer journeys, interfaces, and design system.
Working directly with founders, stakeholders, investors, the startup incubator, and marketing and business teams, I aligned commercial ambition, product priorities, and customer needs throughout the work.
Brand direction
Defining Friddy’s identity, positioning, and visual language across the company and its products.
Product direction
Translating the business model into a coherent product architecture, user roles, capabilities, and priorities.
Hands-on product design
Designing key journeys, financial flows, interfaces, prototypes, and transaction states from strategy through execution.
Design systems
Building reusable foundations and components to create consistency across Friddy’s connected product ecosystem.
PRODUCT STRATEGY
One transaction three different experiences.
Friddy was not designed around a single user journey. A buyer wanted to pay using familiar local methods, a merchant needed reliable international settlement, and a liquidity provider needed eligible requests, clear instructions, and a visible reward.
All three participated in the same transaction, but each entered at a different moment, carried different responsibilities, and faced different risks. A universal experience would either expose too much system complexity or hide the information someone needed to act with confidence.
How do you make one transaction feel clear when every participant experiences a different part of it?
Rather than forcing every participant through the same interface, I structured Friddy around a shared transaction model with role-specific experiences.
The network coordinated eligibility, matching, escrow, confirmation, settlement, and exceptions behind the scenes. Each participant saw only the information, decisions, and transaction states relevant to their role.
One shared transaction Three focused experiences.
Friddy separates each participant’s responsibilities while keeping every action connected to the same transaction.
ROLE-SPECIFIC EXPERIENCES
Each participant sees only the information, actions, and transaction states needed to complete their part.
BUYER EXPERIENCE
Pay locally
Use local currency
Receive confirmation
MERCHANT EXPERIENCE
Create payment request
Track progress
Receive settlement
LIQUIDITY PROVIDER EXPERIENCE
Review eligible requests
Facilitate the exchange
Receieve a bounty
FRIDDY TRANSACTION CORE
Eligiblity
Matching Escrow
Confirmation
Settlement
EXCEPTIONS AND RESOLUTION
Dispute remain connected to the shared transaction
DIFFERENT PROMOTION MECHANICS
Different triggers, rewards, values, and fulfillment conditions.
Buy X → Same item free
Buy X → Different item free
Buy X → Discounted reward
Buy X → Choose reward
Multi-buy → Tiered reward
SHARED BEHAVIORAL VARIABLES
The variables that change across offer types.
Trigger
Reward
Application
Value
Inventory
ONE SHARED INTERACTION MODEL
One predictable customer journey across every promotion mechanic.
Discover
Qualify
Redeem
Confirm
Apply
Promotion behavior & state model
Defining how offers progress—and how the experience responds when eligibility, inventory, or promotion conditions change.
S0
PROGRESSING
Moves toward eligibility by meeting offer requirements.
S1
QUALIFIED
Meets requirements to unlock the reward.
S2
REWARD AVAILABLE
Reward is validated and ready to be applied.
S2A
REWARD UNAVAILABLE
Reward unavailable due to inventory or eligibility.
S3
APPLIED
Promotional value is added to the customer’s cart.
S4
CONFIRMED
Final promotional value is clearly shown at checkout.
Exception scenarios
Key situations that can change the offer state — and how the system responds.
REWARD REMOVED
Customer removes the reward from the cart.
REWARD CHANGED
Customer selects another eligible reward.
QUANTITY INCREASES
Added quantity may unlock a higher reward tier.
QUALIFYING ITEM REMOVED
A required qualifying item is removed from the cart.
REWARD OUT OF STOCK
Selected reward is no longer available.
QUANTITY REDUCED
Cart quantity falls below the eligibility threshold.
PRICE CHANGES
Price update affects qualifying spend or value.
ITEM SUBSTITUTED
Replacement item requires eligibility validation.
FULFILLMENT CHANGES
Delivery method or location affects eligibility.
OFFER CONFLICT
Another promotion takes priority over this offer.
ELIGIBILITY CHANGES
Customer or cart no longer meets requirements.
OFFER EXPIRES
Promotion expires while the customer is shopping.
Exception response in practice
A closer look at how one exception is evaluated, resolved, and communicated to the customer.
QUANTITY REDUCED
Cart quantity falls below the eligibility threshold.
SYSTEM EVALUATION
Cart quantity · qualifying threshold
SYSTEM ACTION
Recalculate progress and reward eligibility
UI RESPONSE
Show remaining requirement
S0
PROGRESSING
Moves toward eligibility by meeting offer requirements.
A shared recovery model
Different exceptions trigger different checks, but follow the same recovery logic: re-evaluate the offer, transition to a valid state, and communicate the change.
Different exceptions. One predictable recovery model.
BOGO customer journey
A simple path from discovering the offer to receiving the reward and completing checkout.
DISCOVER
Sees the offer
SELECT
Adds eligible item
QUALIFY
Unlocks reward
REDEEM
Receives free item
CHECKOUT
Completes purchase
CART
Reviews paid + free
CONFIRM
Sees reward applied
Behind the BOGO journey
A simple “Buy 1, Get 1 Free” experience depends on coordinated decisions across promotion logic, inventory, pricing, and fulfillment.
ADDED ITEM
Eligible product enters cart
CHECK OFFER RULES
SKU · quantity · user · region · offer status
ElIGIBLE?
Meets offer conditions?
NO
YES
KEEP NORMAL STATE
Offer not applied
CHECK REWARD STOCK
Validate reward inventory
AVAILABLE?
Reward item in stock?
NO
YES
SHOW UNAVAILABLE STATE
Reward unavailable
CREATE REWARD
1 promotional unit · SAR 0
RESERVE INVENTORY
1 paid + 1 free · 2 physical units
RECALCULATE CART
Preserve paid + promotional value
CONFIRM IN UI
1 Free Added
SEND TO FULFILLMENT
Pick quantity ×2
CHALLENGE 01
Buy 1, Get 1 Free
Making “free” unmistakable.
Problem
When a customer buys an eligible item, another unit of the same product becomes free. But simply increasing the quantity from one to two could make it appear that the customer was purchasing two items.
The experience needed to distinguish between what the customer bought and what Ninja added as the reward.
Solution
The offer is communicated directly on the product, then surfaced for explicit redemption once the customer becomes eligible.
After redemption, the product state confirms that the offer has been applied, while the cart separates the purchased item from the free unit and shows its original price reduced to zero.
Key UX decision
Treat the offer as 1 purchased item + 1 promotional item — not quantity 2.
CHALLENGE 02
Buy 1, Get the Second Item 30% Off
Showing where the discount actually goes.
Problem
A discounted second item introduces a different mental model. Both units have value, but only one receives the promotional price.
If represented as a single quantity and combined price, customers could struggle to understand which item was discounted and how the total was calculated.
Solution
I kept the redemption interaction consistent with the free-item model, but changed the pricing representation.
The discounted unit remains visibly separate, showing its original and promotional price so customers can understand exactly where the saving has been applied.
Key UX decision
Keep the interaction familiar while allowing the pricing model to change.
CHALLENGE 03
Buy 1, Get a Different Item
Turning a promotion into a selection experience.
Problem
Different-item promotions introduce another layer of complexity: the reward is no longer predetermined.
The system needed to tell customers that they had unlocked an offer, show which products qualified, allow only the permitted selection, and communicate how the discount would be calculated.
Solution
Instead of automatically adding a reward, the eligible state opens a focused selection experience.
Qualified products are presented together, selection is constrained by the promotion rules, and supporting copy explains how pricing is applied before the customer continues shopping.
Key UX decision
When the reward requires a decision, make selection part of redemption.
One framework. Different promotion mechanics.
Same-item rewards, discounted rewards, and customer-selected rewards introduced different business rules, but followed the same underlying interaction model.
Discover
Qualify
Redeem
Confirm
Cart
Separating promotion mechanics from customer-facing behavior allowed new offer types to reuse the same interaction model.
DIGITAL ORDERS
Bringing digital and physical products into one order.
Ninja was expanding beyond products that could be picked, packed, and delivered. Digital cards introduced a different fulfillment model — purchased alongside groceries, but available instantly.
Digital and physical products could exist in the same order, but behaved differently after purchase. The experience needed to make what gets delivered, what becomes available instantly, and what happens next immediately clear.
How do you introduce instantly fulfilled digital products into a commerce journey designed around physical delivery?
Rather than creating a separate experience, I integrated digital goods into the existing commerce model — sharing checkout and order history while introducing the behaviors needed for instant access.
Extending one order across two fulfillment models
Physical products and digital goods shared the same order, but followed different paths after purchase. The experience needed to support both without creating two separate journeys.
ONE ORDER
Contains both product types
PHYSICAL PRODUCTS
Purchase → Prepare → Deliver
DIGITAL GOODS
Purchase → Generate → Reveal → Use
SHARED ORDER EXPERIENCE
One place to access and manage both
Designing for instant access
Unlike physical products, digital goods become usable immediately after purchase. The order experience needed to make access clear while protecting the value until the customer chose to reveal it.
Purchased
Unrevealed
Revealed
Copied
PURCHASED
Payment confirmed; digital value generated.
UNREVEALED
Value available, protected by default.
REVEALED
Value intentionally exposed by the customer.
COPIED
Value copied with immediate confirmation.
One digital product, multiple access states.
One order, two timelines
Physical and digital products share the same transaction, while progressing through different fulfillment states.
ORDER CONFIRMED
One transaction, two fulfillment paths.
PHYSICAL FULFILLMENT
DIGITAL FULFILLMENT
PREPARING
GENERATED
OUT FOR DELIVERY
DELIVERED
AVAILABLE
One order model, without forcing different products into the same fulfillment lifecycle.
When digital fulfillment doesn’t go as planned
Instant fulfillment creates a different class of exceptions from physical delivery. The experience needed to communicate these states without breaking the shared order model.
GENERATION
// How the digital value is created.
Generating
Generated
Generating
Failed
ACCESS
// How the customer accesses the digital value.
Unrevealed
Revealed
Copied
AVAILABILITY
// Whether the digital value can be accessed.
Available
Unavailable
ORDER
// How order changes affect the digital product.
Active
Cancelled
Refunded
Handle digital exceptions at the product level while keeping the order as the shared experience.
Exception response in practice
A closer look at how a failed digital fulfillment state is detected, contained, and communicated without affecting the rest of the order.
GENERATION FAILED
Digital value could not be generated.
SYSTEM EVALUATION
Digital item · generation status
SYSTEM ACTION
Isolate failed digital item
UI RESPONSE
Show failure state and next action
S0
ORDER CONTINUITY
Physical fulfillment continues
Handle digital exceptions at the product level while keeping the order as the shared experience.
CHALLENGE 01
Mixed-product orders
One checkout. Two fulfillment models.
Problem
A single order could contain both groceries and a digital card. Although customers paid for them together, the products behaved differently after purchase: physical goods required delivery while the digital product became available directly inside the app.
Creating separate orders would fragment the experience. Treating them identically would hide an important difference in how customers receive what they purchased.
Solution
I kept both product types within the same order while creating clear grouping inside Order Details.
Digital products received their own section and interaction model, while physical products continued to follow the familiar grocery structure.
This preserved one transaction and one order history while making the different fulfillment models understandable.
Key UX decision
Separate by fulfillment behavior, not by transaction.
CHALLENGE 02
A product that becomes a credential
Making digital value accessible without exposing it by default.
Problem
Unlike a grocery item, the value of a digital card exists in its redeemable code. Once purchased, customers needed an easy way to retrieve and copy that code — without permanently exposing it whenever Order Details was opened.
Solution
The code remains concealed by default and can be deliberately revealed when needed.
Once visible, customers can copy it directly, with immediate system feedback confirming that the action succeeded.
Key UX decision
Treat the card code as an actionable credential, not ordinary order information.
CHALLENGE 03
Reordering across product types
Making “Order Again” work when not everything behaves the same.
Problem
Reordering a mixed purchase introduced a different problem: the previous order could contain products with fundamentally different behaviours. A digital card and a grocery item could be purchased together, but they could not simply be treated as identical line items when rebuilding the order.
The experience needed to translate the previous mixed order back into purchasable items while preserving the distinction between product types and allowing customers to adjust quantities before placing the new order.
Solution
The Order Again experience reconstructs the previous purchase as an editable cart, grouping Digital Cards and Grocery separately while maintaining a single order action and combined total.
Key UX decision
Preserve product-type differences without fragmenting the repurchase journey.
One commerce experience. Different fulfillment models.
Digital cards joined Ninja’s existing commerce model, sharing checkout and order history while introducing instant digital fulfillment.
Ninja could expand what it offered without changing how customers understood an order.
Discover
Purchase
Fulfill
Access
NINJA PRIME
Introducing membership without interrupting the shop.
Ninja Prime introduced a new relationship between customers and the product. Instead of engaging only when placing an order, customers could subscribe for ongoing benefits such as free delivery and cashback.
Prime needed to be discoverable within the existing shopping journey, communicate enough value to justify a recurring commitment, and make joining feel like a natural extension of ordering from Ninja.
How do you introduce a paid membership into a transactional Q-commerce experience without adding friction to the shopping journey?
Rather than treating Prime as a separate product, I integrated membership discovery, plan selection, and payment into the existing commerce experience — keeping the journey connected to behaviors customers already understood.
CHALLENGE 01
Introducing Prime inside an existing shopping journey.
Make membership visible without turning commerce into an ad.
Problem
Prime needed enough visibility for customers to discover it, but Ninja’s home experience was already focused on getting users quickly into products, categories, offers, and repeat purchases.
Making Prime too passive would hurt discovery. Making it too dominant could interrupt the core shopping journey.
Solution
Prime was introduced within the existing commerce experience rather than treated as a disconnected destination.
The entry point communicates the proposition at the moment customers are already thinking about ordering, creating a bridge from transactional value to membership value without changing the primary purpose of Home.
Key UX decision
Introduce membership in the context where its benefits become relevant.
CHALLENGE 02
Turning benefits into a reason to subscribe.
Explain the value before asking for commitment.
Problem
A recurring subscription requires a different decision from purchasing groceries. Customers needed to understand what they would receive in return before being asked to choose a plan or provide payment.
Prime therefore couldn't rely on branding or a generic “Subscribe” CTA alone.
Solution
The Prime experience establishes the value proposition first, surfacing the membership benefits before introducing plan selection.
Benefits such as free delivery and cash back are presented as concrete advantages connected to how customers already use Ninja, making the subscription easier to evaluate in practical terms.
Key UX decision
Sell the value before selling the plan.
CHALLENGE 03
Turning recurring commitment into a simple decision
From benefits to plan selection without unnecessary friction.
Problem
Once customers understood Prime, the next decision was no longer whether Prime has value, but which commitment makes sense for them.
Introducing multiple durations, pricing and savings could easily turn a lightweight subscription into a comparison exercise.
Solution
Plan options were consolidated into a focused selection step where duration, price and relative value could be compared without leaving the Prime journey.
The selected plan then carries forward into confirmation, keeping the transition from consideration to commitment explicit.
Key UX decision
Reduce subscription choice to the information required to make the decision.
CHALLENGE 04
Making payment feel like continuation, not another journey.
Complete the subscription inside a familiar payment model.
Problem
After deciding to subscribe, customers still needed to complete payment. Introducing an unfamiliar checkout specifically for Prime would add friction at the point of highest intent.
Solution
The subscription moves into familiar payment patterns, allowing customers to use an existing payment method or add a new card without breaking the flow.
This keeps the final step focused on completing the decision customers have already made rather than asking them to learn another interaction model.
Key UX decision
Reuse familiar commerce patterns when the mental model doesn't need to change.
Prime changed the commercial model without making Ninja feel like a different product.
Prime extended Ninja beyond individual transactions, integrating membership discovery, plan selection, and payment into the existing commerce experience.
Discover
Understand
Choose
Confirm
Pay
Prime
DESIGN SYSTEM
Building the system behind the product.
As Ninja expanded across new features, categories, and commercial models, solving individual experiences wasn’t enough. The product needed a shared foundation that could keep teams moving quickly without allowing the experience to fragment.
Recurring interface patterns needed to become reusable components, states, and interaction rules — supporting consistency across Arabic and English while giving Design and Engineering a shared language.
How do you increase the speed of product development without allowing a rapidly expanding experience to become inconsistent?
Rather than standardizing screens after they were designed, I helped establish a system from the recurring behaviors already emerging across the product — turning them into reusable foundations, components, and patterns.
Foundations
Creating a shared visual and interaction language.
Components & Patterns
Turning recurring interactions into reusable product patterns.
Product Application
Scaling the system across real product experiences.
OUTCOMES
Designing for the next stage of growth.
The strongest outcome wasn't a single feature. It was creating a product foundation that could accommodate new business models and experiences without fragmenting the customer journey.
This work supported Ninja’s evolution from a focused Q-commerce experience into a broader multi-vertical platform.
A more extensible product
Promotions, digital goods, subscriptions, and new verticals could build on shared patterns rather than creating disconnected experiences.
Greater consistency at scale
Reusable components, interaction patterns, and product behaviours created greater coherence across features, Arabic and English.
A stronger foundation for teams
Shared patterns and design-system principles gave Product, Design, and Engineering a common framework for evolving the experience.
WHAT I TOOK FROM IT
Absorb complexity into the system, not the customer experience.
Ninja reinforced something that has shaped how I approach product design: growth inevitably creates complexity, but customers shouldn't have to carry that complexity themselves.
The most effective solutions were rarely isolated screens. They came from understanding the underlying product logic, finding behaviours that repeated across different problems, and turning those behaviours into systems that could scale.
It also reinforced the value of staying hands-on while leading. Staying close to the product connected detailed interaction decisions with broader product direction, while leadership created the structure for those decisions to scale beyond an individual designer or feature.
As products scale, design shifts from solving individual experiences to building the systems that allow many experiences — and many teams — to evolve coherently.
© 2026 Moe Slah. All rights reserved.