Hipidy
Complete product ecosystem for local delivery platform connecting shops, couriers, and customers through seamless multi-app experience.
Project detais
Case Study
Product Design
Delivery Service
Project Overview
Hipidy is a local commerce platform that connects neighborhood shops and retailers with nearby customers, offering a fast and convenient way to browse, order, and receive products. The platform emerged during the COVID-19 pandemic, when consumer behavior rapidly shifted toward on-demand shopping and contactless delivery. Hipidy aimed to help small and medium businesses stay competitive by promoting eco-friendly logistics and empowering local communities to thrive in the digital marketplace.
I worked as part of a cross-functional team that included a Product Manager, Developers, a Junior Designer, and a Marketing Specialist.
Together, we collaborated closely throughout the process to define the product vision, improve the user experience, and create a clear foundation for Hipidy’s growth.
Timeline
12 weeks
Role
Lead Product Designer (from discovery to delivery)
Team
6 members
Scope
Research, user flows, feature prioritization, visual system, design system
Year
2021
Context & Challenge
When I joined the Hipidy team, the product was already in active MVP development. Progress was being made, but during early reviews it became clear that different parts of the team were operating on conflicting assumptions about how Hipidy was supposed to work as a delivery ecosystem.
Critical questions did not have shared answers:
What exactly happens to an order after it’s placed?
Where do merchant and courier responsibilities begin and end?
How should delays, substitutions, and cancellations be handled?
What does “successful delivery” mean in business and operational terms?
Because these points were not documented or consistently communicated, decisions were frequently made in isolation. Roadmap discussions drifted, and the risk of investing in incompatible or fragile delivery logic increased over time.
To move forward confidently, we needed alignment across product, engineering, operations, and business stakeholders so that every decision was grounded in the same understanding of how Hipidy must function as a delivery system.
This set the foundation for the next phase: a shared product definition and a unified operational model.
Alignment & Product Definition
To move forward with clarity, we organized a series of focused, collaborative alignment workshops. The goal was not to reset the product, but to ensure that decisions were grounded in a shared understanding of what Hipidy needed to be in order to work as a real delivery ecosystem.
Through these workshops, we shifted the perspective from viewing Hipidy as an operational logistics system – coordinating demand, merchant inventory, courier fulfillment, and exception handling. This provided a more reliable foundation for evaluating features, technical priorities, and business trade-offs.
Together with product, engineering, and business stakeholders, we established a single mental model of:
What Hipidy is — and is not?
Who the product serves and what each role needs?
What must be true for delivery to succeed operationally?
What success means?
The alignment process resulted in three core decision-making assets used throughout the project:
Product Definition Canvas — a shared operational definition of the system, used to evaluate every roadmap decision. This eliminated circular debates and significantly reduced design churn.
End-to-End Delivery Flow
The first complete representation of how an order moves through Hipidy from placement to resolution. This allowed engineering to design against reality, not assumptions.Operational Success Criteria
Metrics to verify whether the delivery system actually works, including:order completion rate
SLA predictability
merchant acceptance rate
courier idle time
re-order likelihood (signal for retention and local commerce viability)
These outcomes enabled faster decisions, reduced ambiguity, and provided the clarity required for the next stage of development.
System Mapping (BPMN + Sequence)
Once the product definition was clear, we mapped Hipidy as a logistics system, we defined how orders move across Customer, Merchant, Courier and Ops roles; what states they go through; where failures occur; and how the system recovers from them.
We documented this in a BPMN-inspired service blueprint and a sequence diagram, which became the first shared source of truth for product, design, and engineering.
Outcome:
A transparent operational model that prevented random feature decisions and enabled a scalable product architecture.
BPMN Service Blueprint — end-to-end delivery lifecycle across Customer, Merchant, Courier, and Ops, showing states, handoffs, and operational decision points.
Sequence Diagram — interaction logic between roles and services, defining when and how the system authorizes, updates, reroutes, or escalates an order.
Market & Competitive Insights
In addition, we analyzed how leading 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, rather than their visual patterns.
Key operational signals we identified:
Marketplace commission ranges: typically 20–35%
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 last-mile commerce—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 last-mile logistics and service behaviors.
JTBD / User Key Constrains
To make product decisions based on real delivery constraints, we replaced persona-driven thinking with a Jobs-to-be-Done approach focused on the operational roles that determine whether a delivery can succeed end-to-end.
We concentrated on four core roles in the Hipidy ecosystem, each with a job that cannot fail without breaking the delivery chain:
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 highlighting:
the core operational job for each role
the constraints and failure risks that make the job collapse
the high-risk unmet jobs most likely to break a delivery
This created a clear decision filter across product, engineering, and operations:
If a solution does not strengthen one of these roles’ ability to complete its 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 modeled Hipidy’s delivery system to identify 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 fails, escalates, or survives.
This analysis revealed failure modes that were invisible in interface prototypes, 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
These breakdowns were documented not as systemic risks impacting:
order success rate and fulfillment reliability
SLA predictability and customer trust
merchant participation and repeat revenue
courier earnings efficiency and retention
Outcome:
A shared, end-to-end understanding of where the delivery 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 not as UI friction, but 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.
Redesigning Product Discovery to Reduce Operational Failures (Customer)
Analysis of delivery failure modes showed that Hipidy’s original discovery model forced customers into a merchant-first journey.
This looked usable on screens, but it routinely produced carts that were not operationally fulfillable.
Key failure patterns:
customers could not discover items across merchants, leading to drop-off,
limited stock created split-cart scenarios and sourcing conflicts,
delivery ETA was tied to a store, not a product, reducing accuracy and trust.
To reduce these failure conditions, we redesigned discovery around a hybrid model:
Category / Search → cross-merchant products (availability-driven entry);
Merchant → catalog (for loyalty, brand trust, or specific inventory).
Stores stopped being the mandatory starting point and became a property of availability, not a navigation constraint.
Before checkout, the cart is validated to ensure it can be fulfilled by a single merchant or a safe multi-merchant batch under SLA constraints.
Outcome:
A discovery approach aligned with operational reality: fewer split-cart failures, higher order success rate, and a stronger foundation for inventory-based substitution and smart merchant recommendations.
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.
Merchant Operations Dashboard (IA + key dashboards)
Once Hipidy reduced the risk of forming unfulfillable orders on the customer side, the next source of failure emerged on the merchant execution level.
Even a valid cart could still collapse later due to:
stock volatility and out-of-stock events,
prep-time / capacity mismatches causing SLA breaches,
cancellation cascades increasing support and compensation costs,
margin erosion driven by unprofitable SKUs and substitutions.
The operational hierarchy is structured around four core levers that directly influence order success and profitability:
🔹 Orders & Exceptions — detect cancellation patterns, refund exposure, and failure causes before they escalate.
🔹 Products & Stock — manage SKU availability, low-stock risk, and substitution rules to reduce OOS-driven cancellations.
🔹 Performance & Capacity — monitor SLA stability, prep-time constraints, peak-hour load, and operational bottlenecks.
🔹 Growth & Promotion — shape demand toward SKUs with healthier margins and better fulfillment reliability.
Outcome:
Merchants gain the ability to intervene before an order fails, protecting SLA, contribution margin, and customer trust—transforming Hipidy from a marketplace that reacts to failure into one that prevents it.
Operational IA structured around preventing delivery failure and margin loss.
Prototype & System Outcomes (Customer + Courier flows)
Following the definition of Hipidy’s operational architecture, we developed two prototypes — Customer and Courier — with one objective: to verify whether the system could support a complete and resilient delivery lifecycle under real operational constraints.
These prototypes were used to validate critical assumptions across inventory availability, timing dependencies, routing logic, order handoffs, exception handling, and overall delivery continuity.
The prototypes allowed us to confirm whether the system could:
Complete an order end-to-end
Customer request → inventory validation → merchant confirmation → courier assignment → routing and handoff → delivery completion.Detect and manage operational failures
Delays, substitutions, rerouting, cancellations, and other events that threaten order completion and SLA integrity.Support product access across multiple merchants
Reducing split-cart scenarios, sourcing failures, and unnecessary operational load.Maintain courier efficiency and predictable earnings
Batching, capacity awareness, idle time reduction, and routing adjustments based on location and timing.Scale operational logic without redesigning core flows
Creating the basis for future automation of inventory sync, smart assignment, substitution rules, and escalation protocols.
Customer Prototype Validated:
Product-first access model enabling reliable sourcing across merchants
More predictable delivery formation and timing dependencies
Reduced probability of dead-end orders due to unavailable inventory
Courier Prototype Validated:
Feasible routing and batching mechanics
Handoff and handover logic that avoids unnecessary idle time
Early detection and escalation of risks that threaten delivery success
Outcome
The prototypes demonstrated that Hipidy could function as a delivery system, not merely a set of disconnected ordering steps. The operational model proved capable of:
higher order completion reliability,
more predictable SLA performance,
reduced merchant and courier uncertainty,
lower dependency on manual Ops intervention per order.
In short, the prototypes confirmed that the architecture could support real deliveries under real constraints, establishing the foundation for a market-valid MVP.
Business Impact & Final Reflection
Following the definition of Hipidy’s operational architecture, we developed two prototypes — Customer and Courier — with one objective: to verify whether the system could support a complete and resilient delivery lifecycle under real operational constraints.
These prototypes were used to validate critical assumptions across inventory availability, timing dependencies, routing logic, order handoffs, exception handling, and overall delivery continuity.
The prototypes allowed us to confirm whether the system could:
Complete an order end-to-end
Customer request → inventory validation → merchant confirmation → courier assignment → routing and handoff → delivery completion.Detect and manage operational failures
Delays, substitutions, rerouting, cancellations, and other events that threaten order completion and SLA integrity.Support product access across multiple merchants
Reducing split-cart scenarios, sourcing failures, and unnecessary operational load.Maintain courier efficiency and predictable earnings
Batching, capacity awareness, idle time reduction, and routing adjustments based on location and timing.Scale operational logic without redesigning core flows
Creating the basis for future automation of inventory sync, smart assignment, substitution rules, and escalation protocols.
Customer Prototype Validated:
Product-first access model enabling reliable sourcing across merchants
More predictable delivery formation and timing dependencies
Reduced probability of dead-end orders due to unavailable inventory
Courier Prototype Validated:
Feasible routing and batching mechanics
Handoff and handover logic that avoids unnecessary idle time
Early detection and escalation of risks that threaten delivery success
Outcome
The prototypes demonstrated that Hipidy could function as a delivery system, not merely a set of disconnected ordering steps. The operational model proved capable of:
higher order completion reliability,
more predictable SLA performance,
reduced merchant and courier uncertainty,
lower dependency on manual Ops intervention per order.
In short, the prototypes confirmed that the architecture could support real deliveries under real constraints, establishing the foundation for a market-valid MVP.
