WATERMELON v4.0
WEB PLATFORM
WATERMELON v4.0
WEB PLATFORM
WATERMELON v4.0
WEB PLATFORM
TLDR: As Head of Design, I define the design language across products, manage budgets and resourcing, and provide strategic alignment across teams
TLDR: As Head of Design, I define the design language across products, manage budgets and resourcing, and provide strategic alignment across teams
TLDR: As Head of Design, I define the design language across products, manage budgets and resourcing, and provide strategic alignment across teams
TLDR: As Head of Design, I define the design language across products, manage budgets and resourcing, and provide strategic alignment across teams
3 Platforms
3 Platforms
Buyer, Supplier, Admin
Buyer, Supplier, Admin
Buyer, Supplier, Admin
Buyer, Supplier, Admin
78%
78%
Beta test approval rating
Beta test approval rating
Beta test approval rating
Beta test approval rating
40%
Reduction in Time To Find
Reduction in Time To Find
Reduction in Time To Find
Reduction in Time To Find
92%
92%
Task Success Rate
Task Success Rate
Task Success Rate
Task Success Rate
OVERVIEW
OVERVIEW
What changed when the gap closed.
What changed when the gap closed.
What changed when the gap closed.
What changed when the gap closed.
The features weren't shipped as a list — they were shipped as answers to specific places where V3 fell short. Beta behavior showed up exactly where you'd expect it to, at each of those points.
The features weren't shipped as a list — they were shipped as answers to specific places where V3 fell short. Beta behavior showed up exactly where you'd expect it to, at each of those points.
The features weren't shipped as a list — they were shipped as answers to specific places where V3 fell short. Beta behavior showed up exactly where you'd expect it to, at each of those points.
The features weren't shipped as a list — they were shipped as answers to specific places where V3 fell short. Beta behavior showed up exactly where you'd expect it to, at each of those points.
Catalogue hierarchy
(product → variant → selling unit → offer)
85% fewer pre-order clarification messages, more orders placed without leaving the platform.
Open Marketplace (no sign-up wall)
Lifted signup conversion by 33%, removing gate friction.
Embedded Finance
Unlocked faster repeat transactions and reduced account churn rate by 70%
Catalogue hierarchy
(product → variant → selling unit → offer)
85% fewer pre-order clarification messages, more orders placed without leaving the platform.
Open Marketplace (no sign-up wall)
Lifted signup conversion by 33%, removing gate friction.
Embedded Finance
Unlocked faster repeat transactions and reduced account churn rate by 70%
Catalogue hierarchy
(product → variant → selling unit → offer)
85% fewer pre-order clarification messages, more orders placed without leaving the platform.
Open Marketplace (no sign-up wall)
Lifted signup conversion by 33%, removing gate friction.
Embedded Finance
Unlocked faster repeat transactions and reduced account churn rate by 70%
Catalogue hierarchy
(product → variant → selling unit → offer)
85% fewer pre-order clarification messages, more orders placed without leaving the platform.
Open Marketplace (no sign-up wall)
Lifted signup conversion by 33%, removing gate friction.
Embedded Finance
Unlocked faster repeat transactions and reduced account churn rate by 70%
New Mega Menu
Made catalogue upgrade actually discoverable on-site
Price Comparison
Increased basket size & trust across existing suppliers
Multi-shipment delivery
Completely eliminated partial order cancellations for suppliers and optimised admin workflows
New Mega Menu
Made catalogue upgrade actually discoverable on-site
Price Comparison
Increased basket size & trust across existing suppliers
Multi-shipment delivery
Completely eliminated partial order cancellations for suppliers and optimised admin workflows
New Mega Menu
Made catalogue upgrade actually discoverable on-site
Price Comparison
Increased basket size & trust across existing suppliers
Multi-shipment delivery
Completely eliminated partial order cancellations for suppliers and optimised admin workflows
New Mega Menu
Made catalogue upgrade actually discoverable on-site
Price Comparison
Increased basket size & trust across existing suppliers
Multi-shipment delivery
Completely eliminated partial order cancellations for suppliers and optimised admin workflows
Platform Overview
Step 1
Step 1
Step 1
Step 1
Framing the Problem
Framing the Problem
Framing the Problem
Framing the Problem
Procurement was already digital. It just wasn't on our platform.
Procurement was already digital. It just wasn't on our platform.
Procurement was already digital. It just wasn't on our platform.
Procurement was already digital. It just wasn't on our platform.
The first 2 weeks went into user interviews, operational audits and live order shadowing - sitting with buyers as they placed real orders, and with our own ops team as they patched what the platform couldn't do.
The pattern was consistent: every high-value workflow happened outside the product. Orders, invoices, payments and credit were all manual. We hadn't built a bad interface. We'd built an incomplete system.
The first 2 weeks went into user interviews, operational audits and live order shadowing - sitting with buyers as they placed real orders, and with our own ops team as they patched what the platform couldn't do.
The pattern was consistent: every high-value workflow happened outside the product. Orders, invoices, payments and credit were all manual. We hadn't built a bad interface. We'd built an incomplete system.
The first 2 weeks went into user interviews, operational audits and live order shadowing - sitting with buyers as they placed real orders, and with our own ops team as they patched what the platform couldn't do.
The pattern was consistent: every high-value workflow happened outside the product. Orders, invoices, payments and credit were all manual. We hadn't built a bad interface. We'd built an incomplete system.
The first 2 weeks went into user interviews, operational audits and live order shadowing - sitting with buyers as they placed real orders, and with our own ops team as they patched what the platform couldn't do.
The pattern was consistent: every high-value workflow happened outside the product. Orders, invoices, payments and credit were all manual. We hadn't built a bad interface. We'd built an incomplete system.
Key themes surfaced:
Key themes surfaced:
Discovery was poor, pricing was opaque, and supplier reliability was unclear
Large and credit-based orders bypassed the platform entirely
Suppliers had no motivation or tooling to maintain listings
Discovery was poor, pricing was opaque, and supplier reliability was unclear
Large and credit-based orders bypassed the platform entirely
Suppliers had no motivation or tooling to maintain listings
Operational complexity spiked after checkout, not before
Most suppliers were digitising their business for the first time
Buyers reordered the same basket — we'd designed for shopping, not reordering
Operational complexity spiked after checkout, not before
Most suppliers were digitising their business for the first time
Buyers reordered the same basket — we'd designed for shopping, not reordering
Pain Points & Blockers board
Step 2
Step 2
Step 2
Step 2
Choosing What to Sequence
Choosing What to Sequence
Choosing What to Sequence
Choosing What to Sequence
Three personas, one system, six months.
Three personas, one system, six months.
Three personas, one system, six months.
The obvious plan was to fix the buyer app first — it was the surface leadership saw. We argued against it. Buyers weren't ordering more because they couldn't pay, and suppliers weren't maintaining catalogues because nothing made it worth their time. Fixing the front door moved neither.
So we sequenced the roadmap around the two real constraints instead: supplier catalogue effort, and buyer liquidity. Two parallel workstreams on one shared design foundation, with the system built first so both could move at once.
The obvious plan was to fix the buyer app first — it was the surface leadership saw. We argued against it. Buyers weren't ordering more because they couldn't pay, and suppliers weren't maintaining catalogues because nothing made it worth their time. Fixing the front door moved neither.
So we sequenced the roadmap around the two real constraints instead: supplier catalogue effort, and buyer liquidity. Two parallel workstreams on one shared design foundation, with the system built first so both could move at once.
The obvious plan was to fix the buyer app first — it was the surface leadership saw. We argued against it. Buyers weren't ordering more because they couldn't pay, and suppliers weren't maintaining catalogues because nothing made it worth their time. Fixing the front door moved neither.
So we sequenced the roadmap around the two real constraints instead: supplier catalogue effort, and buyer liquidity. Two parallel workstreams on one shared design foundation, with the system built first so both could move at once.
The obvious plan was to fix the buyer app first — it was the surface leadership saw. We argued against it. Buyers weren't ordering more because they couldn't pay, and suppliers weren't maintaining catalogues because nothing made it worth their time. Fixing the front door moved neither.
So we sequenced the roadmap around the two real constraints instead: supplier catalogue effort, and buyer liquidity. Two parallel workstreams on one shared design foundation, with the system built first so both could move at once.
The bets we made:
The bets we made:
One design language across admin, supplier and buyer — one product wearing three hats
Shared foundations built before feature work, not extracted after
One design language across admin, supplier and buyer — one product wearing three hats
Shared foundations built before feature work, not extracted after
Credit treated as a native ordering surface, not a finance module
Supplier onboarding measured in minutes, not sessions
Credit treated as a native ordering surface, not a finance module
Supplier onboarding measured in minutes, not sessions
Catalog Management - Architecture
How we modelled the catalogue before designing it
Keeping those four questions apart is the decision the rest of the catalogue UX hangs off.
1
Product
What is this thing, independent of how it is packed or priced?
IDENTITY
Name and description
Brand
Category → sub → sub-sub
CODES
Watermelon code — our own unique ID
HS code — for customs, optionalMEDIA
Default imageOne record. Never duplicated per supplier.
What the model told us before we drew a single screen
01
Nothing is just created — everything is proposed
Product, Variant and Selling Unit each carry a state and a note of who suggested it — a supplier, a buyer, or us.
→ One review-and-approve pattern, reused at three levels.
2
Variant
Which pack, size or origin of that product is this?
SPECIFICATION
Variant name — e.g. 500 g bottle
Net content + unit of measure
Country of origin
Allergens
CODES
GTIN —barcode, if it has oneMEDIA
Images
Same product, different pack or origin.
What the model told us before we drew a single screen
02
Quantities have to reconcile upward
Every selling unit stores its quantity in a base unit, so a pallet, a case and a single bottle stay comparable — and nestable.
→ Unit-of-measure entry became a flow, not a field.
3
Selling unit
How is it actually bought and sold - by the each, the case, the pallet?
TRADE FORMAT
Display name the buyer sees
Sold as — each / case / pallet Quantity per pack and per container Quantity in base unit, to compare
CODES
GTIN, and a normalised nameSTRUCTURE
Can nest inside a parent selling unit Open attributes for anything else
Different Packaging Bundles for enterprise purchases.
What the model told us before we drew a single screen
03
Names are the real identifier, not barcodes
All three levels store a normalised name for matching. GTIN is optional, so barcodes could never be the source of truth.
→ Duplicate detection had to happen while someone is still typing.
4
Offer
Who sells it, at what price, on what terms?
COMMERCIALS
Supplier Price and currency Promo price, valid from → to
Brand
Category → sub → sub-sub
TERMS
Minimum order quantity Lead time in days In stock, or notREACH
Public, or private to one buyer Sponsored placementOne offer per supplier, per selling unit. This is what a buyer adds to a cart.
What the model told us before we drew a single screen
04
Price never touches identity
One selling unit carries many supplier offers — each with its own price, terms, visibility and promo window.
→ Search results are offers, not products.
1
Product
What is this thing, independent of how it is packed or priced?
IDENTITY
Name and description
Brand
Category → sub → sub-sub
CODES
Watermelon code — our own unique ID
HS code — for customs, optionalMEDIA
Default imageOne record. Never duplicated per supplier.
What the model told us before we drew a single screen
01
Nothing is just created — everything is proposed
Product, Variant and Selling Unit each carry a state and a note of who suggested it — a supplier, a buyer, or us.
→ One review-and-approve pattern, reused at three levels.
2
Variant
Which pack, size or origin of that product is this?
SPECIFICATION
Variant name — e.g. 500 g bottle
Net content + unit of measure
Country of origin
Allergens
CODES
GTIN —barcode, if it has oneMEDIA
Images
Same product, different pack or origin.
What the model told us before we drew a single screen
02
Quantities have to reconcile upward
Every selling unit stores its quantity in a base unit, so a pallet, a case and a single bottle stay comparable — and nestable.
→ Unit-of-measure entry became a flow, not a field.
3
Selling unit
How is it actually bought and sold - by the each, the case, the pallet?
TRADE FORMAT
Display name the buyer sees
Sold as — each / case / pallet Quantity per pack and per container Quantity in base unit, to compare
CODES
GTIN, and a normalised nameSTRUCTURE
Can nest inside a parent selling unit Open attributes for anything else
Different Packaging Bundles for enterprise purchases.
What the model told us before we drew a single screen
03
Names are the real identifier, not barcodes
All three levels store a normalised name for matching. GTIN is optional, so barcodes could never be the source of truth.
→ Duplicate detection had to happen while someone is still typing.
4
Offer
Who sells it, at what price, on what terms?
COMMERCIALS
Supplier Price and currency Promo price, valid from → to
Brand
Category → sub → sub-sub
TERMS
Minimum order quantity Lead time in days In stock, or notREACH
Public, or private to one buyer Sponsored placementOne offer per supplier, per selling unit. This is what a buyer adds to a cart.
What the model told us before we drew a single screen
04
Price never touches identity
One selling unit carries many supplier offers — each with its own price, terms, visibility and promo window.
→ Search results are offers, not products.
Finance Flows Remapped with new Embedded Credit Finance
Finance Flows Remapped with new Embedded Credit Finance
Step 3
Step 3
Step 3
Step 3
Designing for First-Time Digital Users
Designing for First-Time Digital Users
Designing for First-Time Digital Users
Designing for First-Time Digital Users
The hardest constraint wasn't the interface. It was the user's first day.
The hardest constraint wasn't the interface. It was the user's first day.
The hardest constraint wasn't the interface. It was the user's first day.
The hardest constraint wasn't the interface. It was the user's first day.
Suppliers were never going to leave WhatsApp for something merely more modern — it had to be faster. And most of them had never used a business tool before ours. That reframed the brief for the whole team: we weren't designing for tech-savvy users, we were designing for people running their first digital tool.
Two non-negotiables came out of it. A supplier gets from signup to a live listing without help, and nothing in the catalogue flow assumes they've done this before. Bulk upload, SKU variants, inventory and pricing were all designed backwards from those two rules.
Suppliers were never going to leave WhatsApp for something merely more modern — it had to be faster. And most of them had never used a business tool before ours. That reframed the brief for the whole team: we weren't designing for tech-savvy users, we were designing for people running their first digital tool.
Two non-negotiables came out of it. A supplier gets from signup to a live listing without help, and nothing in the catalogue flow assumes they've done this before. Bulk upload, SKU variants, inventory and pricing were all designed backwards from those two rules.
Suppliers were never going to leave WhatsApp for something merely more modern — it had to be faster. And most of them had never used a business tool before ours. That reframed the brief for the whole team: we weren't designing for tech-savvy users, we were designing for people running their first digital tool.
Two non-negotiables came out of it. A supplier gets from signup to a live listing without help, and nothing in the catalogue flow assumes they've done this before. Bulk upload, SKU variants, inventory and pricing were all designed backwards from those two rules.
What that changed:
What that changed:
Onboarding rebuilt around a single live outcome, not a form sequence
Catalogue upload designed for messy real-world data, not clean data
Onboarding rebuilt around a single live outcome, not a form sequence
Catalogue upload designed for messy real-world data, not clean data
Duplicate SKUs and missing variants handled as system responsibilities, not user errors
Buyer browsing rebuilt reorder-first, matching how buyers actually purchase
Duplicate SKUs and missing variants handled as system responsibilities, not user errors
Buyer browsing rebuilt reorder-first, matching how buyers actually purchase
Supplier onboarding
Supplier onboarding
Catalogue management
Catalogue management
Buyer browsing recaliberated
Buyer browsing recaliberated
Step 4
Step 4
Step 4
Step 4
Reimagining Payments & Watermelon Credit
Reimagining Payments & Watermelon Credit
Reimagining Payments & Watermelon Credit
Reimagining Payments & Watermelon Credit
Turning a cash-flow ceiling into an ordering surface.
Turning a cash-flow ceiling into an ordering surface.
Turning a cash-flow ceiling into an ordering surface.
Turning a cash-flow ceiling into an ordering surface.
Research kept returning the same sentence from buyers: they wanted to order more, but liquidity got in the way. Every improvement to browsing or checkout was working against a wall that wasn't a design problem — until we decided to make it one.
So we built credit as product, not banking. Available credit visible where buyers decide, applied at checkout in the same flow as any other payment, repayment tracked in-platform. The whole point was to turn “I want to order more but can't right now” into “I'll order now and settle later.”
Research kept returning the same sentence from buyers: they wanted to order more, but liquidity got in the way. Every improvement to browsing or checkout was working against a wall that wasn't a design problem — until we decided to make it one.
So we built credit as product, not banking. Available credit visible where buyers decide, applied at checkout in the same flow as any other payment, repayment tracked in-platform. The whole point was to turn “I want to order more but can't right now” into “I'll order now and settle later.”
Research kept returning the same sentence from buyers: they wanted to order more, but liquidity got in the way. Every improvement to browsing or checkout was working against a wall that wasn't a design problem — until we decided to make it one.
So we built credit as product, not banking. Available credit visible where buyers decide, applied at checkout in the same flow as any other payment, repayment tracked in-platform. The whole point was to turn “I want to order more but can't right now” into “I'll order now and settle later.”
Research kept returning the same sentence from buyers: they wanted to order more, but liquidity got in the way. Every improvement to browsing or checkout was working against a wall that wasn't a design problem — until we decided to make it one.
So we built credit as product, not banking. Available credit visible where buyers decide, applied at checkout in the same flow as any other payment, repayment tracked in-platform. The whole point was to turn “I want to order more but can't right now” into “I'll order now and settle later.”
Key shifts:
Key shifts:
Credit balance surfaced at browse and cart, not buried in an account page
Statements, limits and dynamic pricing logic designed as one model
All payments centralised through Watermelon
Credit balance surfaced at browse and cart, not buried in an account page
Statements, limits and dynamic pricing logic designed as one model
All payments centralised through Watermelon
Refunds and replacements designed as credit flows, not exceptions
Invoice upload enforced before delivery, closing the post-order gap
Multi-supplier carts made possible for the first time
Refunds and replacements designed as credit flows, not exceptions
Invoice upload enforced before delivery, closing the post-order gap
Multi-supplier carts made possible for the first time
Payments & Watermelon Credit flow board
Payments & Watermelon Credit flow board
Step 5
Step 5
Step 5
Step 5
One System, Three Surfaces
One System, Three Surfaces
One System, Three Surfaces
One System, Three Surfaces
The only way three dashboards ship in six months.
The only way three dashboards ship in six months.
The only way three dashboards ship in six months.
The only way three dashboards ship in six months.
Three surfaces, parallel development, and a team that would grow mid-project. Shared foundations weren't a nice-to-have - they were the delivery plan.
Tokens, tables, forms, order cards and status primitives went in up front and were treated as shared property across all three dashboards. It cost us the first few weeks and bought back roughly 60% faster shipping, plus consistency we never had to retrofit.
Three surfaces, parallel development, and a team that would grow mid-project. Shared foundations weren't a nice-to-have - they were the delivery plan.
Tokens, tables, forms, order cards and status primitives went in up front and were treated as shared property across all three dashboards. It cost us the first few weeks and bought back roughly 60% faster shipping, plus consistency we never had to retrofit.
Three surfaces, parallel development, and a team that would grow mid-project. Shared foundations weren't a nice-to-have - they were the delivery plan.
Tokens, tables, forms, order cards and status primitives went in up front and were treated as shared property across all three dashboards. It cost us the first few weeks and bought back roughly 60% faster shipping, plus consistency we never had to retrofit.
Three surfaces, parallel development, and a team that would grow mid-project. Shared foundations weren't a nice-to-have - they were the delivery plan.
Tokens, tables, forms, order cards and status primitives went in up front and were treated as shared property across all three dashboards. It cost us the first few weeks and bought back roughly 60% faster shipping, plus consistency we never had to retrofit.
Foundations:
Foundations:
Tokens for colour, type, spacing and elevation shared across all three dashboards
Table, form, order-card and status primitives built once, used everywhere
Tokens for colour, type, spacing and elevation shared across all three dashboards
Table, form, order-card and status primitives built once, used everywhere
Same components, three densities: admin depth, supplier speed, buyer clarity
New patterns checked against existing ones before they shipped
Same components, three densities: admin depth, supplier speed, buyer clarity
New patterns checked against existing ones before they shipped
Design System Component Library
Design System Component Library
the PLATFORM
the PLATFORM
PLATFORM SCREENS AND FEATURE SHOWCASE
Buyer - Onboarding
Admin - Catalog Management - Create Selling Units
Supplier - Add New Offer
Order Lifecycle
Buyer - Mega Menu
Buyer - Apply for Credit on Homepage
Buyer - Product Detail Page
Buyer - Checkout with Watermelon Credit
Buyer - Supplier Catalog
Admin - Order Details Page
Step 7
Step 7
Step 7
Step 7
Testing the System
Testing the System
Testing the System
Testing the System
40 testers (20 buyers, 20 suppliers)
40 testers (20 buyers, 20 suppliers)
40 testers (20 buyers, 20 suppliers)
Beta Test Scoring Template
Beta Test Scoring Template
Beta Test Scoring Template
Beta Test Scoring Template
Watermelon V4 beta test: evaluated the platform across all major feature areas, scoring 78% overall favourability (3.87/5)
Buyer platform: 78.1% | Supplier platform: 76.8% - a narrow gap showing consistent core UX on both sides of the marketplace
Strongest area by far: order flow - buyer checkout (84%) and supplier order management (86%) - validating the core “operating system” value proposition
Onboarding scored well (78–82%) - suggesting the product itself reduces switching friction, a top pre-launch sales objection
Supplier catalogue browsing for buyers landed at 80% - supporting the “shop by preferred supplier” positioning in practice
Weakest area: Embedded Finance (68% buyer / 72% supplier) - not a rejection of the feature, but testers struggled to find/understand terms and payout schedules
Flexible deliveries (72–76%) and supplier catalogue/product contribution (70%) were the next areas flagged - good concepts, execution needs refinement
LEARNINGS
LEARNINGS
LEARNINGS
LEARNINGS
What We'd Take Into the Next One
What We'd Take Into the Next One
What We'd Take Into the Next One
What We'd Take Into the Next One
Onboarding matters more in B2B than in B2C.
Onboarding matters more in B2B than in B2C.
Onboarding matters more in B2B than in B2C.
Because you are often someone’s first software, and their first day decides whether there is a second.
Because you are often someone’s first software, and their first day decides whether there is a second.
Because you are often someone’s first software, and their first day decides whether there is a second.
Because you are often someone’s first software, and their first day decides whether there is a second.
Simplify the delivery-scheduling and catalogue/product-contribution flows
Simplify the delivery-scheduling and catalogue/product-contribution flows
Simplify the delivery-scheduling and catalogue/product-contribution flows
Both landed as "good idea, rough execution," so a focused UX pass (fewer steps, clearer per-product vs. per-order logic).
Prioritize a clarity pass on Embedded Finance.
Prioritize a clarity pass on Embedded Finance.
Prioritize a clarity pass on Embedded Finance.
Surface payment terms, credit conditions, and payout schedules more prominently at checkout and in the supplier dashboard, since the gap tested as presentation / discoverability, not functionality
WATERMELON MOBILE APP
WATERMELON MOBILE APP
WATERMELON MOBILE APP
Designing the Region's Most Holistic F&B Procurement App
Designing the Region's Most Holistic F&B Procurement App
Read More
Read More
Read More
Read More
