Ninja Van • 2024

Designing for autonomy: Helping Ninja Van partners operate independently

Reducing workflow friction and internal dependencies through a partner-led self-serve platform

Overview

As Ninja Van rolled out its partner-led model across Southeast Asia, outsourcing pickups initially reduced costs, but also exposed new operational gaps. Third-party partners lacked the tools to run pickups independently, workflows became fragmented, and internal Ninja Van teams were pulled in daily to manage issues — cancelling out the time and cost savings the model was meant to achieve.
‍
This shift in operational reality made one thing clear: cost savings alone wouldn’t scale unless we first improved how efficiently partners could run pickups on their own.
As the sole designer on the team, I led end-to-end research and design efforts with cross-functional teams. Together with Product, we identified a key opportunity to improve operational efficiency by streamlining workflows and reducing reliance on internal Ninja Van teams through a self-serve partner portal.

Note: This is an ongoing project currently under development. As such, impact has not yet been measured — we plan to evaluate outcomes after rollout.

Objectives

Together with my product manager, I co-defined these objectives to make the partner-led model viable at scale:
  • User: Empowering partners to operate more efficiently through self-serve tools
  • Business: Lay the foundation for future scale and cost-efficiency
Vertical
Commercial, Operations

Role
Product designer

Scope
End-to-end design execution, design strategy, field research, usability testing, cross-functional collaboration

Timeline
September 2024 - Present

Countries
Philippines, Indonesia, Malaysia

Discovery

I co-led a contextual inquiry with my product manager, engaging 3 key stakeholder groups — the regional business team, and local operations teams in the Philippines and Indonesia — to uncover where operational breakdowns were occurring. We learned that:
  • Manual dependencies on internal Ninja Van teams were slowing partner operations
  • Limited visibility into how third-party partners operated day-to-day
  • The long-term scalability of the current partner support model was unclear
This led us to frame a key question:
How might we improve operational efficiency in a partner-led model by reducing workflow friction and manual dependencies?
To address this, I proposed a field study in the Philippines — where the newly launched partner model saw low adoption and early challenges — to gain clearer visibility into current operations and map on-ground partner workflows.

Research plan and execution

I led the end-to-end research from aligning on objectives and crafting the discussion guide, to field execution and translating findings into actionable product direction. I collaborated closely with the Philippines ops team to ensure research was grounded in operational realities.

The goal was to uncover operational breakdowns and surface what partners needed to operate more independently.
  • Conducted semi-structured interviews with 6 partners (managers and drivers)
  • Shadowed the 6 partner manager's drivers for their daily pickup over 3 days (split into 2 researcher teams)
  • Facilitated daily synthesis sessions with cross-functional stakeholders to align observations and spot patterns
The full cycle spanned 3 weeks of planning, 1 week of fieldwork, and 1 week of synthesis, resulting in an insight deck that directly informed our product strategy — focused on improving partner autonomy and reducing dependencies on internal Ninja Van teams.

Research findings

Current partner operations workflow

I mapped the full pickup workflow and uncovered recurring breakdowns. The diagram below highlights where high dependencies on internal Ninja Van team and lack of visibility were slowing partners down:
Note: There are two key systems referenced in the diagram above.
  • OPv2: A web-based tool used by Ninja Van employees to reroute or reassign drivers.
  • Driver App: Used by drivers to view assigned routes and pickup details, and to perform pickups by scanning parcels into the system.

Key insights

Insight 1: Partners have limited autonomy

Partners are unable to monitor or reassign drivers independently when disruptions happen on the ground.
  • Why it matters: Partners need to make real-time decisions to operate reliably, such as reallocating drivers when unavailable, or transfer waypoints (pickup location) to another driver to balance workload based on parcel volume.
  • Problem: They have no direct access to systems that support these functions.
  • Impact: They default to manual coordination via Telegram or WhatsApp, creating delays and heavy reliance on internal Ninja Van teams for routing and reassignment.

Insight 2: Lack visibility to be efficient

Partners do not have access to pickup or seller information, making it difficult to plan and respond proactively.
  • Why it matters: Partners can’t identify misrouted waypoints, pickup failures, or seller readiness.
  • Problem: They depend entirely on drivers to relay information manually, causing delays before partner managers can take any actions.
  • Impact: This results in inefficient manpower planning, wasted trips when parcels aren’t ready, and no digital trail to defend against seller disputes. Without visibility, partners struggle to meet SLAs and resolve issues quickly on the ground.
"I need the capability to monitor and reassign my drivers when necessary. If one of my drivers is unable to handle their parcel load, I want to be able to send another driver to rescue."
‍– Partner from Southern Caloocan City

Product direction

I supported my product manager in scoping a minimum viable product (MVP) to address the most critical gaps first while balancing impact with speed to market. The first phase focused on:
  • Route visibility and tracking
  • Reassign drivers or transfer waypoints between routes
  • Visibility into seller's information
By launching fast and learning in-market, we could reduce workflow friction and manual dependencies more effectively, enabling operational efficiency at scale and unlocking cost savings sooner.
After aligning on early design concepts with engineering, I co-led a discussion around implementation trade-offs. We collectively decided to build a standalone portal tailored for partners, rather than modifying the existing OPv2 platform to accommodate role-based access control (RBAC), due to the following reasons:
  • Security risks of partial access
  • Complexity of legacy codebase

Conceptualisation

The core principle behind the portal design is information parity between drivers and partners. Whatever data a driver can access in the Driver App, e.g. route and pickup details, should also be available to the partner.

The key difference is scope of visibility:
  • Drivers see only their assigned routes
  • Partners see an overview across all routes, drivers, and sellers assigned to them
By aligning visibility across both roles, this approach aims to reduce workflow friction and manual dependencies, supporting our goal of improving operational efficiency in a partner-led model.

Route visibility and tracking

Through field research, we uncovered a key operational gap: partners had no way of monitoring drivers or route progress unless drivers manually reported back. This caused delays in deciding when to step in, reassign, or deploy backups.
To address this, the MVP surfaced operational blind spots partners encountered daily:

Route page
  • Route status, start time, and progress: Show whether a driver has started their route, how far along they are, and if delays are occurring, enabling timely interventions.
  • Parcel count: Helps gauge route capacity and assign the right vehicle.
  • Waypoint count: Estimates route effort, aiding in daily workload planning.
Route detail page
  • Waypoint status: Flags failed or partial pickups, allowing partners to take early action, such as contacting the driver to understand the issue and decide on next steps.
  • Completion time: Serves as a digital trail to defend against seller disputes claiming no pickup attempt was made.
  • Time slot priority (Late/Urgent): Alerts partners to time-sensitive pickups, helping them reprioritise or reassign quickly to meet SLAs.
By making this data visible, we aim to enable partners to make more proactive, informed decisions, improving their overall operational efficiency.

Reassign drivers or transfer waypoints between routes

Another key operational friction: partners had no way of reallocating pickups when a driver was unavailable or falling behind. They relied on internal Ninja Van teams to manually reroute waypoints, which created delays in resolving disruptions on the ground.
To address this, the MVP surfaced workflow blockers that limited partner autonomy during disruptions:
  • Driver reassignment: Reassign an entire route to another driver, without going through internal Ninja Van team.
  • Transfer waypoints: Reassign specific pickup points between drivers to balance workload
Giving partners visibility alone wasn’t enough. If they still had to rely on internal Ninja Van teams to take action, we wouldn’t be reducing workflow friction. We aim to eliminate this dependency and empower partners to respond quickly and independently.

Visibility into seller's information

Lastly, another key blocker we identified: partners couldn’t contact sellers directly or verify parcel readiness before dispatching drivers. They had to rely on drivers to report issues after the fact. This often led to wasted trips or disputes when sellers claimed pickups weren’t made.
To address this, we gave partners access to key seller-level information:
  • Seller name and contact: Allows partners to proactively check if parcels are ready and follow up directly to resolve issues post-pickup.
  • Pickup address and parcel count: Helps partners validate what should be collected, cross-check against what was scanned, and identify if any parcels were missed.
  • Assigned driver: Creates accountability and a clearer handover trail, useful for investigating disputes.
Providing seller visibility not only supports proactive planning, but also enables partners to troubleshoot and resolve pickup issues independently.

Usability testing

Before launch, I created a prototype and conducted moderated remote usability tests with 6 partners — 2 each from the Philippines, Indonesia, and Malaysia — to evaluate whether the proposed partner portal could address shared operational gaps across different markets. I focused on understanding if any key information need was missing, how partners would use available information in context, and whether these early concepts addressed the pain points uncovered during discovery.

Key insight that refined our product understanding

The most pivotal finding from usability testing was a misalignment in assumptions around what partners truly needed:
  • What we assumed: Partners needed seller-level information to resolve pickup issues and follow up directly with sellers.
  • What we learned through testing: What partners really want is to understand why a pickup failed, not just that it failed. Since missed pickups affect their KPIs and how well they manage their teams, they need tools to trace what happened and take action — not just contact the seller. That’s why they care more about parcel-level details than seller info.
  • Why we missed this: We focused heavily on driver coordination in the Philippines which led us to the assumption. However, usability testing revealed a key gap where in markets like Indonesia and Malaysia, partners are more concerned about parcel-level outcomes.
Since the MVP is first launching in the Philippines, we prioritised route and driver tracking and waypoint reassignment features to support day-to-day pickup coordination. The insight around parcel-level auditing will guide future iterations as we expand to Indonesia and Malaysia, where operational needs differ.
Usability test session with one of our Philippines partner
Usability testing themes and insights synthesised in Dovetail
While core workflows were intuitive, testing uncovered areas that needed design refinements to reduce friction and improve efficiency:

Key insights that helped refine our designs

Lack of discoverability of filters

Users initially missed the filter option as it was tucked within a dropdown. By surfacing filters directly in the header row, we made them more immediately accessible, reducing friction and helping users find relevant pickup details faster.
Before
After

Unclear affordance of icon-only buttons

Icons without labels created friction in understanding actions, especially for logistics operators who tend to be cautious about clicking unfamiliar icons for fear of disrupting ongoing operations.
Before
After

Impact (as of April 2025)

Though still in the research and validation phase, this project has already shaped key outcomes and future direction.

Objective

  • User: Empowering partners to operate more efficiently through self-serve tools
  • Business: Lay the foundation for future scale and cost-efficiency

Key results (to be tracked post-launch)

Next steps

We are currently in the development phase.

We plan to roll out the portal to existing partners in the Philippines to further validate its effectiveness at scale. Following that, we aim to expand to Indonesia and Malaysia. However, one key blocker in these markets is the current practice of drivers sharing accounts, an operational hygiene issue we need to resolve before the portal can deliver its intended value. Addressing this will be critical to ensuring the portal’s success and usability across all regions.

Reflection

As the first product I’ve built from scratch, this project challenged me to think holistically, from defining the problem space to shaping solutions that are operationally grounded and scalable. It wasn’t just about designing features, but about co-owning product decisions, validating real-world workflows with users on the ground, and collaborating with engineering to weigh trade-offs.
© 2025 Dayna Wong. All Rights Reserved.