DeliveryPage — Samuel Omoraiyewa

[IMAGE — A wide cover image showing 2-3 surfaces together (e.g. Partner Dashboard + Mobile App side by side), giving an at-a-glance sense of the scope of the project before anyone reads a word.]

The Problem

[IMAGE — Optional. A simple before/after or concept visual showing the old model (locked into one delivery option) vs the DeliveryPage model (partner choice). Skip if you don't have this; not essential.]

Before DeliveryPage, customers had no choice in how their orders were delivered. They were locked into whatever delivery arrangement a business had, with no visibility into pricing or delivery windows, and no say in the matter.

DeliveryPage's answer was to become the bridge: onboard delivery partners directly, let them manage their own pricing and availability, and give customers a say in how their package gets to them — without the business absorbing the operational risk of running logistics itself.

That single decision — DeliveryPage as bridge, not operator — shaped almost every design decision that followed.

The System

DeliveryPage serves delivery partners on one side and customers on the other:

Delivery Partners — execute deliveries, managed through the Partner Dashboard
Customers — place and track orders via the Mobile App and Web Dashboard, which function as parallel experiences rather than divergent ones
Landing pages for each surface, focused on conversion and positioning rather than product decisions

Both the Partner Dashboard and the customer-facing Mobile App/Web Dashboard carried real design decisions — the Partner Dashboard around serving different business sizes on one surface, the customer side around handling edge cases and keeping the experience consistent across devices.

[IMAGE — A simple diagram (boxes + arrows is fine) showing how Delivery Partner → Partner Dashboard and Customer → Mobile App / Web Dashboard flow through DeliveryPage as the bridge. This can be a quick Figma diagram, doesn't need to be fancy — it just needs to orient the reader before the decisions section.]

Design Decisions: Partner Dashboard

1. DeliveryPage as bridge, not operator

Delivery partners set their own prices, routes, and availability windows. Rather than DeliveryPage dictating terms, partners operate with autonomy — DeliveryPage's role is to connect them to demand, not manage their business for them.

[IMAGE — The screen where delivery partners set their prices, routes, and availability. Shows the autonomy point directly.]

2. Splitting Shipments by origin, not filtering a unified list

Partner businesses range from small operations with no in-house logistics to established businesses running their own fulfillment alongside DeliveryPage orders. The first approach was a single shipment list with filters to separate marketplace orders from a partner's own shipments — in practice, this added tabs and filter logic that smaller partners had to navigate just to find orders that mattered to them.

[IMAGE — If you still have this early version saved anywhere (old file, screenshot, even a rough sketch), it's worth including. Seeing the "before" makes the "after" land harder. If it doesn't exist anymore, skip this one and let the final version speak for itself.]

The dashboard was restructured around two distinct sections instead: Shipments, for orders originating from DeliveryPage customer orders, and Direct Shipments, for a partner's own in-house fulfillment. A partner with no direct shipments never sees that section at all — the interface stays simple by default rather than requiring a mode to be toggled. Established partners get a dedicated space to manage their own logistics alongside marketplace orders, without either use case cluttering the other.

[IMAGE — Side-by-side or a short sequence showing both tabs, and ideally the empty state for a Startup Sam-type partner who has no Direct Shipments yet, to show the section simply not appearing/being empty.]

3. Curating partner autonomy against customer experience

Giving partners free rein over pricing and availability created a risk: customers could end up choosing between too many options, or options that weren't genuinely competitive. Rather than restricting what partners could set, the dashboard surfaces a curated selection of three delivery options to the customer at checkout — partners retain full control over their own pricing and terms, while customers are protected from being overwhelmed or exposed to weak options. Autonomy on one side, curation on the other.

[IMAGE — The customer-facing screen (mobile or web) showing the curated 3 delivery choices at checkout. This closes the loop visually: partner sets terms → customer sees a clean, limited choice.]

Design Decisions: Customer Experience (Mobile App & Web Dashboard)

4. Handling weight discrepancies without blocking the order

Delivery pricing is tied to the weight a customer declares at checkout. When a package's actual weight exceeds what was entered — a user error, not a partner dispute — the order isn't silently held or cancelled. Instead, the customer gets an "Action required" notification with a choice: top up the payment difference to proceed, or cancel and receive a refund. The customer stays in control of the resolution rather than the system making the call for them or the order stalling with no clear next step.

[IMAGE — The notification itself, followed by the screen where the customer chooses to top up or get refunded.]

5. Making the web dashboard feel like the app, on purpose

Rather than treating the Web Dashboard as its own product with its own conventions, it was deliberately designed to mirror the Mobile App's structure and interactions as closely as responsive layout allows — same flows, same terminology, same mental model. Since there are no functionalities exclusive to either surface, a customer who's used the app shouldn't have to relearn anything switching to web, or vice versa.

[IMAGE — Same flow (e.g. order tracking) shown on both surfaces, side by side, to make the consistency visible.]

Other Surfaces

[IMAGE — One representative landing page screen.]

Landing pages — conversion and positioning-focused, not a source of product decisions.

Reflection

DeliveryPage doesn't have outcome data attached yet. Looking back, the strongest work spans both sides of the product: the Partner Dashboard, where two genuinely different business types had to be served by one surface, and the customer experience, where edge cases like weight discrepancies had to be resolved without leaving the customer stuck or the order in limbo. Across both, the harder problem was less about visual design and more about deciding where to give people control and where to protect them from complexity they didn't need to see.

If revisiting this today, the next test would be validating whether the curated three-option selection at checkout is actually the right number, or whether customer behavior data would justify showing more or fewer choices.