Hipidy
A multi-role platform for local commerce and on-demand delivery, connecting customers, merchants, and couriers through seamless multi-app experience.
Product Design
Case Study
Project Overview
Hipidy is a local marketplace platform that connects local shops with nearby customers by fast, eco-friendly delivery. It helps small and medium merchants compete in the digital world while strengthening local communities.
As the Lead Product Designer on a lean cross-functional team (PM, Business Analyst, developers, junior designer, marketing), I helped define the product vision, align the multi-app ecosystem (Customer, Merchant, Courier), and build the operational foundations that turned a fragile PoC into a reliable MVP pilot.
Context & Challenge
When I joined Hipidy, the product was transitioning from a Proof of Concept (PoC) to a Minimum Viable Product (MVP), preparing for limited pilot testing with real merchants and couriers. Progress was ongoing, but early reviews highlighted a major issue: different parts of the team operated on conflicting assumptions about how Hipidy was supposed to work.
Critical operational questions had no shared, agreed-upon answers:
Order Lifecycle: What exactly happens to an order after it’s placed?
Roles & Responsibilities: Where do merchant and courier responsibilities begin and end?
Exception Handling: How should delays, substitutions, and cancellations be handled?
Success Criteria: What does “successful delivery” mean in business and operational terms?
Because these foundational elements were not properly documented or consistently communicated, decisions were made in isolation, causing roadmap discussions to drift. This posed a risk of investing in features that were functional but could not support real-world delivery flows.
To establish a shared definition of a scalable local marketplace and delivery system and move forward confidently, we required alignment across Product, Engineering, Operations, and Business stakeholders. This alignment was the essential foundation for defining a unified operational model and shared decision-making artifacts that subsequently guided both the design and development processes.
Early-stage feature set presented during PoC launch
Early UI screens for Customer, Courier, and Business apps
Alignment & Product Definition
To ensure the entire team operated from the same page, we organized a series of focused cross-functional workshops. The goal was to establish a shared understanding of what Hipidy needed to be in order to scale as a local commerce platform with integrated delivery.
Together with product, engineering, and business stakeholders, we aligned on:
What Hipidy is – and what it is not?
Who the product serves and what each role needs (Customer, Merchant, Courier, Ops)?
What must be true for deliveries to succeed operationally?
What defines value beyond revenue?
How success is measured across the lifecycle?
These workshops resulted in three core decision-making artifacts used throughout the project:
Product Definition Canvas
A shared single source of truth used to evaluate roadmap decisions and reduce circular debates across teams.End-to-End Delivery Flow
A complete representation of how an order moves through Hipidy, from placement to fulfillment.
This helped engineering build against real operational conditions, not assumptions.Operational Success Criteria
A metrics framework to validate that the delivery system works in practice, including:order completion rate;
SLA predictability;
merchant acceptance rate;
courier idle time;
reorder likelihood (signal for retention and marketplace viability).
Once the product definition was clearly established, we mapped how orders move across Customer, Merchant, Courier, and Ops roles: the states, handoffs, failure points, and recovery paths. We documented this as a BPMN service blueprint, which served as the first shared source of truth across product, design, and engineering.
BPMN Service Blueprint — end-to-end delivery lifecycle across Customer, Merchant, Courier, and Ops, showing states, handoffs, and operational decision points.
Market & Competitive Insights
In addition, we analyzed how leading local marketplace and delivery platforms structure logistics, incentives, and service expectations. The goal was to examine operational principles that enable sustainable delivery at scale.
We combined research across players such as Wolt, Glovo, Bolt Food, Uber Eats, and DoorDash, focusing on their underlying delivery mechanics and economic drivers.
Key operational signals we identified:
Expected urban delivery SLA: consistently 20–40 minutes
Merchant pickup readiness: often required within 6–8 minutes
Courier delay thresholds: escalations or reassignment triggered around 5–7 minutes
Substitution, cancellation, and refund handling: major impact on trust, cost, and reorder frequency
These recurring patterns reflect non-negotiable constraints in local delivery services - routing efficiency, inventory confidence, and unit economics—not subjective product decisions.
Outcome:
A set of operational benchmarks and competitive signals used to shape Hipidy’s delivery lifecycle, routing assumptions, escalation logic, and feature prioritization.
Competitive operations benchmark — delivery models, SLAs, commission ranges, and operational strengths across leading platforms.
Interface patterns reflecting shared local delivery and service behaviors.
Jobs-to-be-Done & Key Operational Constraints
To clarify the true objectives of each role in the Hipidy ecosystem and to align product decisions around what users actually need to accomplish, we used a Jobs-to-be-Done approach. It helped us uncover the operational “jobs” that drive behavior across the system and revealed where failures in one role create breakdowns for the others.
Customer JTBD: receive the correct products within a predictable time window, without additional coordination effort.
Merchant JTBD: sell inventory without being forced to manually manage delivery logistics or resolve fulfillment issues.
Courier JTBD: earn reliably through efficient routing, batching, and minimized idle time.
Ops / Support JTBD: ensure orders complete even when the system encounters failures (inventory mismatches, delays, routing gaps, payment issues).
To guide feature prioritization and flow design, we captured these jobs in a JTBD System Matrix that highlighted:
• the core operational job for each role;
• the constraints and failure risks that cause a job to break;
• the high-risk unmet jobs most likely to disrupt delivery.
This gave the team a clear decision filter: if a solution does not strengthen a role’s ability to complete its core job with fewer failure points, it does not enter the roadmap.
JTBD Matrix - Each breakpoint represents a critical failure mode where the platform must provide intervention mechanisms.
High-Risk Unmet Jobs — Delivery Breakpoints
Operational Architecture & Exception Handling
With the core operational JTBDs defined, we identified the structural points where the lifecycle is most likely to break. The objective was not to just visualize happy paths, but to surface the conditions under which an order сan escalates or fails.
This analysis revealed failure modes, including:
Split inventory acceptance — cart items not fulfillable by a single merchant, forcing complex availability and routing decisions;
Pickup delays caused by prep-time misalignment, batching conflicts, or courier reassignment;
Mid-route address changes, requiring rerouting, ETA recalculation, and validation of courier capacity;
Silent cancellations, where no actor had authority or observability to complete or abort the order cleanly;
Insufficient Ops visibility, preventing intervention before SLA breaches and payout/compensation issues.
Outcome:
A shared understanding of where the lifecycle fails and how the system must support recovery, escalation, and service continuity.
Hipidy Service Blueprint - Operational Coordination
Failure Mode Mapping - We analyzed failure points as systemic risks that determine order success rate and SLA integrity.
Exception Handling Flow - Exception handling logic ensured the system could recover from common breakdowns without relying solely on Ops intervention.
Customer App
The original Customer app UI was designed before we had a unified operational model. It was essentially a large collection of standalone screens covering basic flows. Once we defined the end-to-end operational flow and constraints, it became clear that much of the UI simply couldn’t support the real fulfillment logic.
Key misalignments:
• Discovery was merchant-first, not product-first. Users had to guess which store carried an item, creating loops and early drop-off.
• Stock accuracy appeared only at checkout. Customers built full carts only to learn items were unavailable or orders had to be split.
• Delivery feasibility wasn’t connected to the cart. Distance and availability looked “fine” per store, but not for a mixed order.
Once we introduced a unified operational model, we redesigned the app information architecture around product-first availability and real-time feasibility.
This shift aligned the UI with how the system could truly deliver orders, reducing failed/split orders and increasing conversion and average order value.
Before — Merchant-first discovery (high risk of unfulfillable orders)
Users were forced to start from a store, without cross-merchant search or availability checks, often resulting in carts the delivery system could not fulfill.
After — Availability-driven hybrid discovery (reduced delivery failures)
Users begin from categories or search and see products across merchants with availability/ETA signals, enabling cart validation and lowering split-cart and cancellation risk.
Courier App
The Courier app UI was originally adapted from the Customer app with only minor adjustments. Most screens and flows were reused as-is, without reflecting the realities of courier operations. Once we defined the proper delivery lifecycle and operational states, we audited the UI against real fulfillment needs – and the gaps were immediate.
Key misalignments:
• Manual task picking → unpredictable routing and no connection to actual demand
• No availability or capacity controls → impossible to plan supply or ensure coverage
• No clear task states → unreliable tracking from assignment → pickup → delivery
• No batching or proximity logic → inefficient routes and missed SLA windows
• Zero earnings visibility → low motivation and weak retention
With the unified operational model in place, we designed a dedicated information architecture for the Courier app — one built specifically around the operational pipeline rather than customer-facing patterns.
We rebuilt the experience around a structured fulfillment flow:
Availability → System-Assigned Task → Pickup → Route → Delivery → Earnings Updated.
Key improvements:
• System-assigned tasks based on location, SLA windows, batching, and proximity
• Clear availability settings through a simple working-hours calendar
• Consistent task states for routing, monitoring, and SLA tracking
• Real-time earnings and performance visibility
These changes aligned the Courier app with real operations, enabling predictable routing, proper supply planning, and significantly stronger courier retention.
Before — Manual, Unstructured Courier Flow (high operational chaos)
Couriers manually browsed orders and self-assigned tasks like in a marketplace. Without availability controls, routing rules, batching, or earnings transparency, operations couldn’t predict capacity or ensure SLA reliability. The result: inefficient routes, unstable supply, and frequent failures.
After — Structured, System-Assigned Fulfillment Flow (predictable & SLA-driven)
A redesigned courier lifecycle introduces availability scheduling, automatic task assignment based on location & SLA, clear task states, and transparent earnings. The system now routes efficiently, balances workload, and ensures operational predictability across the entire delivery pipeline.
Merchant Dashboard
As the product moved into the MVP pilot stage, a dedicated Merchant Dashboard became an essential part of the planned ecosystem. The earlier assumption — that merchant operations could be handled manually through forms, messages, and the ops team — was no longer viable once real delivery volume and live operational feedback were required.
To define what the MVP version needed to support, we interviewed merchants to understand how they managed products, orders, and daily workflows in their shops. These insights informed a dedicated information architecture for the Merchant Dashboard, which we then translated into a lightweight but focused interface that enabled merchants to handle core operations without relying on the ops team.
A minimal yet complete dashboard aligned with merchant workflows and early operational constraints:
• Dashboard (Home) — real-time view of daily performance: orders, cancellations, prep time, courier wait time, and action alerts.
• Products & Catalog — add/edit items, instant availability toggles, prep-time controls, and simple stock signals.
• Orders — live order flow, history, cancellation reasons, and basic refund handling.
• Store Settings — opening hours, delivery radius, minimum order value, payout details.
• Notifications & Help — in-app alerts and quick access to support.
Although this was only the MVP version, the dashboard became the operational backbone of the pilot. It shifted merchants from manually supported participants to capable operators and established the technical and behavioral foundation for the more advanced merchant platform that followed.
Operational IA structured around preventing delivery failure and margin loss.
A clean overview of today’s orders, prep time, cancellations, product insights, and customer ratings, with instant actions like marking items out of stock.
Business Impact & Final Reflection
Business Impact (MVP Pilot)
The MVP pilot validated that the unified operational model, redesigned role experiences, and shared decision-making framework could support real deliveries under real constraints. Running the system across a few neighborhoods with a small courier fleet and a focused group of merchants confirmed that Hipidy could operate consistently rather than relying on manual coordination.
Over the first 12 weeks of the pilot, the product showed strong early signals:
• Order completion stabilized at 88–92% across varied scenarios.
• Most orders moved end-to-end without manual corrections, reducing operational noise.
• Couriers received steadier task flow and more predictable earnings patterns.
• Merchants actively maintained catalogs, prep times, and availability through the dashboard, decreasing reliance on the ops team.
• Support requests remained low, with only occasional exceptions requiring intervention.
• Weekly order volume grew predictably as both merchants and couriers adapted to the system.
Although intentionally small in scope, the pilot proved the one thing an MVP must prove:
the system can reliably run real deliveries with real users, under real conditions.
This created the foundation for transitioning from validation to controlled expansion.
Next Steps (Product Design Focus)
With the MVP pilot confirming that the operational model works in practice, the next phase for product design focuses on strengthening clarity, reducing friction, and preparing the system for higher complexity and scale.
• Refine operational edge cases surfaced during the pilot (substitutions, delays, batching conflicts) and improve UX and UI clarity around those states.
• Prioritize redesign of high-friction touchpoints that generated confusion or support requests.
• Prepare the information architecture for larger volume and more complex behaviors.
These steps help prevent ambiguity and misalignment as the product scales – one of the biggest risks for early delivery platforms.
Reflection & Key Learnings
This project reinforced a principle I have always believed: in complex operational products, effective product design depends on early cross-functional alignment. Designers add the most value when they frame the problem, help define the system, and shape the conditions under which the product can function – long before visual decisions are made.
Since a large set of screens already existed when I joined, the assumption was that development would move faster — that engineers could simply take these pre-made interfaces and assemble the product. But because the screens were created without a defined operational model, real user needs, or clarity around the delivery process, they ended up creating more ambiguity than direction. This showed that producing interfaces “in advance” cannot accelerate development when the underlying system and requirements are not yet understood; without knowing what you are building, screens cannot guide you.
By focusing on system definition, lifecycle clarity, and cross-role alignment, I helped shift the team from producing isolated outputs to building a foundation the product could reliably operate on. This experience showed how essential early product designer involvement is for ensuring that the team is solving the right problems within the right structure.
Hipidy
A multi-role platform for local commerce and on-demand delivery, connecting customers, merchants, and couriers through seamless multi-app experience.
Product Design
Case Study
Project Overview
Hipidy is a local marketplace platform that connects local shops with nearby customers by fast, eco-friendly delivery. It helps small and medium merchants compete in the digital world while strengthening local communities.
As the Lead Product Designer on a lean cross-functional team (PM, Business Analyst, developers, junior designer, marketing), I helped define the product vision, align the multi-app ecosystem (Customer, Merchant, Courier), and build the operational foundations that turned a fragile PoC into a reliable MVP pilot.
Context & Challenge
When I joined Hipidy, the product was transitioning from a Proof of Concept (PoC) to a Minimum Viable Product (MVP), preparing for limited pilot testing with real merchants and couriers. Progress was ongoing, but early reviews highlighted a major issue: different parts of the team operated on conflicting assumptions about how Hipidy was supposed to work.
Critical operational questions had no shared, agreed-upon answers:
Order Lifecycle: What exactly happens to an order after it’s placed?
Roles & Responsibilities: Where do merchant and courier responsibilities begin and end?
Exception Handling: How should delays, substitutions, and cancellations be handled?
Success Criteria: What does “successful delivery” mean in business and operational terms?
Because these foundational elements were not properly documented or consistently communicated, decisions were made in isolation, causing roadmap discussions to drift. This posed a risk of investing in features that were functional but could not support real-world delivery flows.
To establish a shared definition of a scalable local marketplace and delivery system and move forward confidently, we required alignment across Product, Engineering, Operations, and Business stakeholders. This alignment was the essential foundation for defining a unified operational model and shared decision-making artifacts that subsequently guided both the design and development processes.
Early-stage feature set presented during PoC launch
Early UI screens for Customer, Courier, and Business apps
Alignment & Product Definition
To ensure the entire team operated from the same page, we organized a series of focused cross-functional workshops. The goal was to establish a shared understanding of what Hipidy needed to be in order to scale as a local commerce platform with integrated delivery.
Together with product, engineering, and business stakeholders, we aligned on:
What Hipidy is – and what it is not?
Who the product serves and what each role needs (Customer, Merchant, Courier, Ops)?
What must be true for deliveries to succeed operationally?
What defines value beyond revenue?
How success is measured across the lifecycle?
These workshops resulted in three core decision-making artifacts used throughout the project:
Product Definition Canvas
A shared single source of truth used to evaluate roadmap decisions and reduce circular debates across teams.End-to-End Delivery Flow
A complete representation of how an order moves through Hipidy, from placement to fulfillment.
This helped engineering build against real operational conditions, not assumptions.Operational Success Criteria
A metrics framework to validate that the delivery system works in practice, including:order completion rate;
SLA predictability;
merchant acceptance rate;
courier idle time;
reorder likelihood (signal for retention and marketplace viability).
Once the product definition was clearly established, we mapped how orders move across Customer, Merchant, Courier, and Ops roles: the states, handoffs, failure points, and recovery paths. We documented this as a BPMN service blueprint, which served as the first shared source of truth across product, design, and engineering.
BPMN Service Blueprint — end-to-end delivery lifecycle across Customer, Merchant, Courier, and Ops, showing states, handoffs, and operational decision points.
Market & Competitive Insights
In addition, we analyzed how leading local marketplace and delivery platforms structure logistics, incentives, and service expectations. The goal was to examine operational principles that enable sustainable delivery at scale.
We combined research across players such as Wolt, Glovo, Bolt Food, Uber Eats, and DoorDash, focusing on their underlying delivery mechanics and economic drivers.
Key operational signals we identified:
Expected urban delivery SLA: consistently 20–40 minutes
Merchant pickup readiness: often required within 6–8 minutes
Courier delay thresholds: escalations or reassignment triggered around 5–7 minutes
Substitution, cancellation, and refund handling: major impact on trust, cost, and reorder frequency
These recurring patterns reflect non-negotiable constraints in local delivery services - routing efficiency, inventory confidence, and unit economics—not subjective product decisions.
Outcome:
A set of operational benchmarks and competitive signals used to shape Hipidy’s delivery lifecycle, routing assumptions, escalation logic, and feature prioritization.
Competitive operations benchmark — delivery models, SLAs, commission ranges, and operational strengths across leading platforms.
Interface patterns reflecting shared local delivery and service behaviors.
Jobs-to-be-Done & Key Operational Constraints
To clarify the true objectives of each role in the Hipidy ecosystem and to align product decisions around what users actually need to accomplish, we used a Jobs-to-be-Done approach. It helped us uncover the operational “jobs” that drive behavior across the system and revealed where failures in one role create breakdowns for the others.
Customer JTBD: receive the correct products within a predictable time window, without additional coordination effort.
Merchant JTBD: sell inventory without being forced to manually manage delivery logistics or resolve fulfillment issues.
Courier JTBD: earn reliably through efficient routing, batching, and minimized idle time.
Ops / Support JTBD: ensure orders complete even when the system encounters failures (inventory mismatches, delays, routing gaps, payment issues).
To guide feature prioritization and flow design, we captured these jobs in a JTBD System Matrix that highlighted:
• the core operational job for each role;
• the constraints and failure risks that cause a job to break;
• the high-risk unmet jobs most likely to disrupt delivery.
This gave the team a clear decision filter: if a solution does not strengthen a role’s ability to complete its core job with fewer failure points, it does not enter the roadmap.
JTBD Matrix - Each breakpoint represents a critical failure mode where the platform must provide intervention mechanisms.
High-Risk Unmet Jobs — Delivery Breakpoints
Operational Architecture & Exception Handling
With the core operational JTBDs defined, we identified the structural points where the lifecycle is most likely to break. The objective was not to just visualize happy paths, but to surface the conditions under which an order сan escalates or fails.
This analysis revealed failure modes, including:
Split inventory acceptance — cart items not fulfillable by a single merchant, forcing complex availability and routing decisions;
Pickup delays caused by prep-time misalignment, batching conflicts, or courier reassignment;
Mid-route address changes, requiring rerouting, ETA recalculation, and validation of courier capacity;
Silent cancellations, where no actor had authority or observability to complete or abort the order cleanly;
Insufficient Ops visibility, preventing intervention before SLA breaches and payout/compensation issues.
Outcome:
A shared understanding of where the lifecycle fails and how the system must support recovery, escalation, and service continuity.
Hipidy Service Blueprint - Operational Coordination
Failure Mode Mapping - We analyzed failure points as systemic risks that determine order success rate and SLA integrity.
Exception Handling Flow - Exception handling logic ensured the system could recover from common breakdowns without relying solely on Ops intervention.
Customer App
The original Customer app UI was designed before we had a unified operational model. It was essentially a large collection of standalone screens covering basic flows. Once we defined the end-to-end operational flow and constraints, it became clear that much of the UI simply couldn’t support the real fulfillment logic.
Key misalignments:
• Discovery was merchant-first, not product-first. Users had to guess which store carried an item, creating loops and early drop-off.
• Stock accuracy appeared only at checkout. Customers built full carts only to learn items were unavailable or orders had to be split.
• Delivery feasibility wasn’t connected to the cart. Distance and availability looked “fine” per store, but not for a mixed order.
Once we introduced a unified operational model, we redesigned the app information architecture around product-first availability and real-time feasibility.
This shift aligned the UI with how the system could truly deliver orders, reducing failed/split orders and increasing conversion and average order value.
Before — Merchant-first discovery (high risk of unfulfillable orders)
Users were forced to start from a store, without cross-merchant search or availability checks, often resulting in carts the delivery system could not fulfill.
After — Availability-driven hybrid discovery (reduced delivery failures)
Users begin from categories or search and see products across merchants with availability/ETA signals, enabling cart validation and lowering split-cart and cancellation risk.
Courier App
The Courier app UI was originally adapted from the Customer app with only minor adjustments. Most screens and flows were reused as-is, without reflecting the realities of courier operations. Once we defined the proper delivery lifecycle and operational states, we audited the UI against real fulfillment needs – and the gaps were immediate.
Key misalignments:
• Manual task picking → unpredictable routing and no connection to actual demand
• No availability or capacity controls → impossible to plan supply or ensure coverage
• No clear task states → unreliable tracking from assignment → pickup → delivery
• No batching or proximity logic → inefficient routes and missed SLA windows
• Zero earnings visibility → low motivation and weak retention
With the unified operational model in place, we designed a dedicated information architecture for the Courier app — one built specifically around the operational pipeline rather than customer-facing patterns.
We rebuilt the experience around a structured fulfillment flow:
Availability → System-Assigned Task → Pickup → Route → Delivery → Earnings Updated.
Key improvements:
• System-assigned tasks based on location, SLA windows, batching, and proximity
• Clear availability settings through a simple working-hours calendar
• Consistent task states for routing, monitoring, and SLA tracking
• Real-time earnings and performance visibility
These changes aligned the Courier app with real operations, enabling predictable routing, proper supply planning, and significantly stronger courier retention.
Before — Manual, Unstructured Courier Flow (high operational chaos)
Couriers manually browsed orders and self-assigned tasks like in a marketplace. Without availability controls, routing rules, batching, or earnings transparency, operations couldn’t predict capacity or ensure SLA reliability. The result: inefficient routes, unstable supply, and frequent failures.
After — Structured, System-Assigned Fulfillment Flow (predictable & SLA-driven)
A redesigned courier lifecycle introduces availability scheduling, automatic task assignment based on location & SLA, clear task states, and transparent earnings. The system now routes efficiently, balances workload, and ensures operational predictability across the entire delivery pipeline.
Merchant Dashboard
As the product moved into the MVP pilot stage, a dedicated Merchant Dashboard became an essential part of the planned ecosystem. The earlier assumption — that merchant operations could be handled manually through forms, messages, and the ops team — was no longer viable once real delivery volume and live operational feedback were required.
To define what the MVP version needed to support, we interviewed merchants to understand how they managed products, orders, and daily workflows in their shops. These insights informed a dedicated information architecture for the Merchant Dashboard, which we then translated into a lightweight but focused interface that enabled merchants to handle core operations without relying on the ops team.
A minimal yet complete dashboard aligned with merchant workflows and early operational constraints:
• Dashboard (Home) — real-time view of daily performance: orders, cancellations, prep time, courier wait time, and action alerts.
• Products & Catalog — add/edit items, instant availability toggles, prep-time controls, and simple stock signals.
• Orders — live order flow, history, cancellation reasons, and basic refund handling.
• Store Settings — opening hours, delivery radius, minimum order value, payout details.
• Notifications & Help — in-app alerts and quick access to support.
Although this was only the MVP version, the dashboard became the operational backbone of the pilot. It shifted merchants from manually supported participants to capable operators and established the technical and behavioral foundation for the more advanced merchant platform that followed.
Operational IA structured around preventing delivery failure and margin loss.
A clean overview of today’s orders, prep time, cancellations, product insights, and customer ratings, with instant actions like marking items out of stock.
Business Impact & Final Reflection
Business Impact (MVP Pilot)
The MVP pilot validated that the unified operational model, redesigned role experiences, and shared decision-making framework could support real deliveries under real constraints. Running the system across a few neighborhoods with a small courier fleet and a focused group of merchants confirmed that Hipidy could operate consistently rather than relying on manual coordination.
Over the first 12 weeks of the pilot, the product showed strong early signals:
• Order completion stabilized at 88–92% across varied scenarios.
• Most orders moved end-to-end without manual corrections, reducing operational noise.
• Couriers received steadier task flow and more predictable earnings patterns.
• Merchants actively maintained catalogs, prep times, and availability through the dashboard, decreasing reliance on the ops team.
• Support requests remained low, with only occasional exceptions requiring intervention.
• Weekly order volume grew predictably as both merchants and couriers adapted to the system.
Although intentionally small in scope, the pilot proved the one thing an MVP must prove:
the system can reliably run real deliveries with real users, under real conditions.
This created the foundation for transitioning from validation to controlled expansion.
Next Steps (Product Design Focus)
With the MVP pilot confirming that the operational model works in practice, the next phase for product design focuses on strengthening clarity, reducing friction, and preparing the system for higher complexity and scale.
• Refine operational edge cases surfaced during the pilot (substitutions, delays, batching conflicts) and improve UX and UI clarity around those states.
• Prioritize redesign of high-friction touchpoints that generated confusion or support requests.
• Prepare the information architecture for larger volume and more complex behaviors.
These steps help prevent ambiguity and misalignment as the product scales – one of the biggest risks for early delivery platforms.
Reflection & Key Learnings
This project reinforced a principle I have always believed: in complex operational products, effective product design depends on early cross-functional alignment. Designers add the most value when they frame the problem, help define the system, and shape the conditions under which the product can function – long before visual decisions are made.
Since a large set of screens already existed when I joined, the assumption was that development would move faster — that engineers could simply take these pre-made interfaces and assemble the product. But because the screens were created without a defined operational model, real user needs, or clarity around the delivery process, they ended up creating more ambiguity than direction. This showed that producing interfaces “in advance” cannot accelerate development when the underlying system and requirements are not yet understood; without knowing what you are building, screens cannot guide you.
By focusing on system definition, lifecycle clarity, and cross-role alignment, I helped shift the team from producing isolated outputs to building a foundation the product could reliably operate on. This experience showed how essential early product designer involvement is for ensuring that the team is solving the right problems within the right structure.
Hipidy
Complete product ecosystem for local delivery platform connecting shops, couriers, and customers through seamless multi-app experience.
Product Design
Case Study
Project Overview
Hipidy is a local marketplace platform that connects local shops with nearby customers by fast, eco-friendly delivery. It helps small and medium merchants compete in the digital world while strengthening local communities.
As the Lead Product Designer on a lean cross-functional team (PM, Business Analyst, developers, junior designer, marketing), I helped define the product vision, align the multi-app ecosystem (Customer, Merchant, Courier), and build the operational foundations that turned a fragile PoC into a reliable MVP pilot.
Context & Challenge
When I joined Hipidy, the product was transitioning from a Proof of Concept (PoC) to a Minimum Viable Product (MVP), preparing for limited pilot testing with real merchants and couriers. Progress was ongoing, but early reviews highlighted a major issue: different parts of the team operated on conflicting assumptions about how Hipidy was supposed to work.
Critical operational questions had no shared, agreed-upon answers:
Order Lifecycle: What exactly happens to an order after it’s placed?
Roles & Responsibilities: Where do merchant and courier responsibilities begin and end?
Exception Handling: How should delays, substitutions, and cancellations be handled?
Success Criteria: What does “successful delivery” mean in business and operational terms?
Because these foundational elements were not properly documented or consistently communicated, decisions were made in isolation, causing roadmap discussions to drift. This posed a risk of investing in features that were functional but could not support real-world delivery flows.
To establish a shared definition of a scalable local marketplace and delivery system and move forward confidently, we required alignment across Product, Engineering, Operations, and Business stakeholders. This alignment was the essential foundation for defining a unified operational model and shared decision-making artifacts that subsequently guided both the design and development processes.
Early-stage feature set presented during PoC launch
Early UI screens for Customer, Courier, and Business apps
Alignment & Product Definition
To ensure the entire team operated from the same page, we organized a series of focused cross-functional workshops. The goal was to establish a shared understanding of what Hipidy needed to be in order to scale as a local commerce platform with integrated delivery.
Together with product, engineering, and business stakeholders, we aligned on:
What Hipidy is – and what it is not?
Who the product serves and what each role needs (Customer, Merchant, Courier, Ops)?
What must be true for deliveries to succeed operationally?
What defines value beyond revenue?
How success is measured across the lifecycle?
These workshops resulted in three core decision-making artifacts used throughout the project:
Product Definition Canvas
A shared single source of truth used to evaluate roadmap decisions and reduce circular debates across teams.End-to-End Delivery Flow
A complete representation of how an order moves through Hipidy, from placement to fulfillment.
This helped engineering build against real operational conditions, not assumptions.Operational Success Criteria
A metrics framework to validate that the delivery system works in practice, including:order completion rate;
SLA predictability;
merchant acceptance rate;
courier idle time;
reorder likelihood (signal for retention and marketplace viability).
Once the product definition was clearly established, we mapped how orders move across Customer, Merchant, Courier, and Ops roles: the states, handoffs, failure points, and recovery paths. We documented this as a BPMN service blueprint, which served as the first shared source of truth across product, design, and engineering.
BPMN Service Blueprint — end-to-end delivery lifecycle across Customer, Merchant, Courier, and Ops, showing states, handoffs, and operational decision points.
Market & Competitive Insights
In addition, we analyzed how leading local marketplace and delivery platforms structure logistics, incentives, and service expectations. The goal was to examine operational principles that enable sustainable delivery at scale.
We combined research across players such as Wolt, Glovo, Bolt Food, Uber Eats, and DoorDash, focusing on their underlying delivery mechanics and economic drivers.
Key operational signals we identified:
Expected urban delivery SLA: consistently 20–40 minutes
Merchant pickup readiness: often required within 6–8 minutes
Courier delay thresholds: escalations or reassignment triggered around 5–7 minutes
Substitution, cancellation, and refund handling: major impact on trust, cost, and reorder frequency
These recurring patterns reflect non-negotiable constraints in local delivery services - routing efficiency, inventory confidence, and unit economics—not subjective product decisions.
Outcome:
A set of operational benchmarks and competitive signals used to shape Hipidy’s delivery lifecycle, routing assumptions, escalation logic, and feature prioritization.
Competitive operations benchmark — delivery models, SLAs, commission ranges, and operational strengths across leading platforms.
Interface patterns reflecting shared local delivery and service behaviors.
Jobs-to-be-Done & Key Operational Constraints
To clarify the true objectives of each role in the Hipidy ecosystem and to align product decisions around what users actually need to accomplish, we used a Jobs-to-be-Done approach. It helped us uncover the operational “jobs” that drive behavior across the system and revealed where failures in one role create breakdowns for the others.
Customer JTBD: receive the correct products within a predictable time window, without additional coordination effort.
Merchant JTBD: sell inventory without being forced to manually manage delivery logistics or resolve fulfillment issues.
Courier JTBD: earn reliably through efficient routing, batching, and minimized idle time.
Ops / Support JTBD: ensure orders complete even when the system encounters failures (inventory mismatches, delays, routing gaps, payment issues).
To guide feature prioritization and flow design, we captured these jobs in a JTBD System Matrix that highlighted:
• the core operational job for each role;
• the constraints and failure risks that cause a job to break;
• the high-risk unmet jobs most likely to disrupt delivery.
This gave the team a clear decision filter: if a solution does not strengthen a role’s ability to complete its core job with fewer failure points, it does not enter the roadmap.
JTBD Matrix - Each breakpoint represents a critical failure mode where the platform must provide intervention mechanisms.
High-Risk Unmet Jobs — Delivery Breakpoints
Operational Architecture & Exception Handling
With the core operational JTBDs defined, we identified the structural points where the lifecycle is most likely to break. The objective was not to just visualize happy paths, but to surface the conditions under which an order сan escalates or fails.
This analysis revealed failure modes, including:
Split inventory acceptance — cart items not fulfillable by a single merchant, forcing complex availability and routing decisions;
Pickup delays caused by prep-time misalignment, batching conflicts, or courier reassignment;
Mid-route address changes, requiring rerouting, ETA recalculation, and validation of courier capacity;
Silent cancellations, where no actor had authority or observability to complete or abort the order cleanly;
Insufficient Ops visibility, preventing intervention before SLA breaches and payout/compensation issues.
Outcome:
A shared understanding of where the lifecycle fails and how the system must support recovery, escalation, and service continuity.
Hipidy Service Blueprint - Operational Coordination
Failure Mode Mapping - We analyzed failure points as systemic risks that determine order success rate and SLA integrity.
Exception Handling Flow - Exception handling logic ensured the system could recover from common breakdowns without relying solely on Ops intervention.
Customer App
The original Customer app UI was designed before we had a unified operational model. It was essentially a large collection of standalone screens covering basic flows. Once we defined the end-to-end operational flow and constraints, it became clear that much of the UI simply couldn’t support the real fulfillment logic.
Key misalignments:
• Discovery was merchant-first, not product-first. Users had to guess which store carried an item, creating loops and early drop-off.
• Stock accuracy appeared only at checkout. Customers built full carts only to learn items were unavailable or orders had to be split.
• Delivery feasibility wasn’t connected to the cart. Distance and availability looked “fine” per store, but not for a mixed order.
Once we introduced a unified operational model, we redesigned the app information architecture around product-first availability and real-time feasibility.
This shift aligned the UI with how the system could truly deliver orders, reducing failed/split orders and increasing conversion and average order value.
Before — Merchant-first discovery (high risk of unfulfillable orders)
Users were forced to start from a store, without cross-merchant search or availability checks, often resulting in carts the delivery system could not fulfill.
After — Availability-driven hybrid discovery (reduced delivery failures)
Users begin from categories or search and see products across merchants with availability/ETA signals, enabling cart validation and lowering split-cart and cancellation risk.
Courier App
The Courier app UI was originally adapted from the Customer app with only minor adjustments. Most screens and flows were reused as-is, without reflecting the realities of courier operations. Once we defined the proper delivery lifecycle and operational states, we audited the UI against real fulfillment needs – and the gaps were immediate.
Key misalignments:
• Manual task picking → unpredictable routing and no connection to actual demand
• No availability or capacity controls → impossible to plan supply or ensure coverage
• No clear task states → unreliable tracking from assignment → pickup → delivery
• No batching or proximity logic → inefficient routes and missed SLA windows
• Zero earnings visibility → low motivation and weak retention
With the unified operational model in place, we designed a dedicated information architecture for the Courier app — one built specifically around the operational pipeline rather than customer-facing patterns.
We rebuilt the experience around a structured fulfillment flow:
Availability → System-Assigned Task → Pickup → Route → Delivery → Earnings Updated.
Key improvements:
• System-assigned tasks based on location, SLA windows, batching, and proximity
• Clear availability settings through a simple working-hours calendar
• Consistent task states for routing, monitoring, and SLA tracking
• Real-time earnings and performance visibility
These changes aligned the Courier app with real operations, enabling predictable routing, proper supply planning, and significantly stronger courier retention.
Before — Manual, Unstructured Courier Flow (high operational chaos)
Couriers manually browsed orders and self-assigned tasks like in a marketplace. Without availability controls, routing rules, batching, or earnings transparency, operations couldn’t predict capacity or ensure SLA reliability. The result: inefficient routes, unstable supply, and frequent failures.
After — Structured, System-Assigned Fulfillment Flow (predictable & SLA-driven)
A redesigned courier lifecycle introduces availability scheduling, automatic task assignment based on location & SLA, clear task states, and transparent earnings. The system now routes efficiently, balances workload, and ensures operational predictability across the entire delivery pipeline.
Merchant Dashboard
Before this phase, merchants had zero dedicated interface. They onboarded through a simple form, received orders via WhatsApp or phone, and relied 100% on Hipidy’s ops team to handle everything: availability changes, prep time adjustments, cancellations, payouts — you name it.
For the pilot, we designed and shipped the first proper Merchant Dashboard — a clean, web-based tool that finally let small local shops run their delivery business themselves.
What We Launched for the Pilot A single, focused interface built around the three things merchants needed most during early real-world testing:
Dashboard (Home) Daily performance at a glance: today’s orders, cancellations, average prep time, courier wait time, unavailable items, and immediate action alerts (e.g., “Item X is running low — mark out of stock”).
Products & Catalog Easy add/edit of items, real-time availability toggle, prep time settings, and basic stock alerts.
Orders Live and historical orders, acceptance flow, cancellation reasons, and simple refund handling.
Store Settings Opening hours, minimum order value, delivery radius, payout details.
Notifications & Help In-app alerts + quick access to support.
Pilot Results (First 8 Weeks with 60+ Merchants)
Merchants logging in daily went from 0% → 78%
Manual ops tickets per merchant dropped 82%
Average catalog size grew 4.2× because merchants could finally update items themselves
Out-of-stock incidents fell sharply once merchants could toggle availability in seconds
New merchants onboarded in hours instead of days of hand-holding
Operational IA structured around preventing delivery failure and margin loss.
A clean overview of today’s orders, prep time, cancellations, product insights, and customer ratings, with instant actions like marking items out of stock.
Business Impact & Final Reflection
Business Impact (MVP Pilot)
The MVP pilot validated that the unified operational model, redesigned role experiences, and shared decision-making framework could support real deliveries under real constraints. Running the system across a few neighborhoods with a small courier fleet and a focused group of merchants confirmed that Hipidy could operate consistently rather than relying on manual coordination.
Over the first 12 weeks of the pilot, the product showed strong early signals:
• Order completion stabilized at 88–92% across varied scenarios.
• Most orders moved end-to-end without manual corrections, reducing operational noise.
• Couriers received steadier task flow and more predictable earnings patterns.
• Merchants actively maintained catalogs, prep times, and availability through the dashboard, decreasing reliance on the ops team.
• Support requests remained low, with only occasional exceptions requiring intervention.
• Weekly order volume grew predictably as both merchants and couriers adapted to the system.
Although intentionally small in scope, the pilot proved the one thing an MVP must prove:
the system can reliably run real deliveries with real users, under real conditions.
This created the foundation for transitioning from validation to controlled expansion.
Next Steps (Product Design Focus)
With the MVP pilot confirming that the operational model works in practice, the next phase for product design focuses on strengthening clarity, reducing friction, and preparing the system for higher complexity and scale.
• Refine operational edge cases surfaced during the pilot (substitutions, delays, batching conflicts) and improve UX and UI clarity around those states.
• Prioritize redesign of high-friction touchpoints that generated confusion or support requests.
• Prepare the information architecture for larger volume and more complex behaviors.
These steps help prevent ambiguity and misalignment as the product scales – one of the biggest risks for early delivery platforms.
Reflection & Key Learnings
This project reinforced a principle I have always believed: in complex operational products, effective product design depends on early cross-functional alignment. Designers add the most value when they frame the problem, help define the system, and shape the conditions under which the product can function – long before visual decisions are made.
Since a large set of screens already existed when I joined, the assumption was that development would move faster — that engineers could simply take these pre-made interfaces and assemble the product. But because the screens were created without a defined operational model, real user needs, or clarity around the delivery process, they ended up creating more ambiguity than direction. This showed that producing interfaces “in advance” cannot accelerate development when the underlying system and requirements are not yet understood; without knowing what you are building, screens cannot guide you.
By focusing on system definition, lifecycle clarity, and cross-role alignment, I helped shift the team from producing isolated outputs to building a foundation the product could reliably operate on. This experience showed how essential early product designer involvement is for ensuring that the team is solving the right problems within the right structure.
