Shippa: Shipbubble's fleet app

Problem

Shipbubble’s web app gets a merchant’s shipment to the right courier. Shippa is the other half: the app the courier’s own riders use to actually run the delivery, from the moment a pickup lands on their phone to the moment cash is in their wallet.

The rider’s job is a chain: accept the assignment, prove the delivery happened, collect payment on the merchant’s behalf, and withdraw what they have earned. If any link breaks, whether a customer is unreachable or cash is handed over with no record, the delivery or the payment stalls. The design problem was to hold that chain together in one order-to-payout flow, including the deliveries that don’t go to plan.

Evidence / research

I scoped the app from the rider’s working sequence: an assignment request, the pickup, the recipient’s confirmation, cash-on-delivery collection, and wallet settlement. Each step is a point where a delivery or a payment can stall, so each one needed its own state, its own next action and its own record.

My role

I designed the rider app end to end: order flows, proof of delivery, COD payments, wallet withdrawals and design QA.

Constraints

The design had to be delivered in one month, on iOS and Android, using the component library shared with Shipbubble’s merchant web and buyer apps. Delivery status, customer payment and rider payout needed distinct states, including failure and verification steps.

Options considered

Two choices shaped the app. For collection, cash alone was the simple option, but it leaves no record and puts the risk on the rider, so the design lets the customer pay by transfer or card instead. For proof of delivery, a single “delivered” button would have been fastest, but it is only the rider’s word. I paired a photo with a PIN read back from the customer, so delivery is confirmed by both sides.

Decision

Organise the app around the rider’s job: assignment, delivery confirmation, collection and payout. Keep a payment timeline on each order, capture a reason when delivery fails, and require OTP confirmation for withdrawals.

Design

The job, end to end

A rider’s day comes down to three things that all have to hold up: get assigned the right pickup and delivery, prove the delivery happened, and get paid, including cash collected on a merchant’s behalf. Shippa is built around that sequence rather than around a features list.

Home shows what the day looks like at a glance: an online toggle, assigned, completed and pending pickups for the period, and the wallet balance one tap from being withdrawn. A rider can also log an order themselves, capturing the customer’s details, the cash-on-delivery amount, the delivery fee and the seller’s bank details, for jobs that come in outside the normal dispatch.

A new assignment arrives as a request, pickup and delivery address, and whether it is a cash-on-delivery order, that the rider accepts or declines before it becomes a job. Accepted jobs carry everything needed to run them: pickup and delivery contacts with one-tap calling, the package manifest with weight and quantity, the COD amount to collect and from whom, and any handling notes.

Completing a delivery takes a photo as proof and a PIN read back from the customer, so “delivered” is something the receiving customer confirmed, not just something the rider clicked.

Not every delivery goes through. A rider who cannot complete one picks a reason, customer unreachable, cancelled, address not found, rather than leaving the job stuck with no record of why.

Getting paid for cash collected

Cash-on-delivery is where trust gets tested. The COD list tracks every order by payment state, pending or collected, with a “request payment” action that pushes the customer to pay by transfer or card instead of handing over cash. A transfer shows the exact amount, account and reference to pay against, and every order carries a payment timeline, pending, collected, settled, so a disputed payment is not a phone call, it is a record.

Wallet and payout

Everything a rider earns, deliveries and COD collected, lands in one wallet with a running transaction history. Withdrawing is a choice of amount and a bank transfer out, confirmed by an OTP, so a payout is never one tap away from a mistake.

Collaboration / implementation

I worked with the product manager and engineering team, using the design system shared with Shipbubble’s web and buyer apps. My contribution included design QA across the rider flows.

Measurement

The design was built to move three numbers: riders active, delivery completion time, and the share of COD collected through transfer or card rather than cash. Those are still early, so I hold them as targets rather than results, with firm figures to follow once there is a stable stretch to report.

Result

Shippa is live on Shipbubble’s fleet on iOS and Android, running the whole order-to-payout loop: assignment, proof of delivery, COD collection and wallet payouts, on the design system shared with the web and buyer apps.

What I learned

Designing Shippa made me think more carefully about what “done” means. A parcel can be delivered while its payment is still pending, and a collected payment can still be waiting for settlement. Those states need their own language and next actions. The payment timeline and delivery confirmation flow became as important to the design as accepting a new job.

On a next iteration, I would prioritise testing interrupted deliveries and payment recovery with riders. Those moments would help me judge whether the app gives enough guidance when the normal sequence breaks.