Designing a logistics platform to move goods across Africa, one delivery at a time
GoFlex is a three-sided logistics platform connecting senders, riders, and admins to move goods across Nigeria, starting in Lagos. As sole product designer, I owned the experience end-to-end — from problem framing through onboarding flows, delivery matching, payments, and the rider-facing operations tools.
Project type
Product design
Location
Geneva, Switzerland
Role
Staff product designer + cross team coordenation
Company
Sonar
Industry
Dev tools
Timeline
6 months
The problem
How might we let senders move goods point A to B seamlessly?
SMEs contribute over 48% of Nigeria’s GDP, but poor infrastructure and a fragmented supply chain make it hard and expensive to move goods reliably. Senders lose money on unreliable delivery. Would-be riders have no simple way to turn spare time and a vehicle into income. Existing players — Uber, Jumia Logistics, Glovo, GiG — each solve a slice of this, but none combine price-sensitive delivery for SMEs with a trustworthy, verified rider network built for African cities.
Who we’re designing for
Three user groups, three very different needs
Senders
Mostly companies who need affordable, reliable delivery and visibility into where their item is at every step.
Delivery riders
Individuals looking to earn extra income, who need a simple, trustworthy way to find work, get paid, and stay safe on the road.
Admins
Internal operators who need visibility and control over pricing, zones, riders, and platform health.
Design constraints shaped early decisions: users needed only basic literacy and a smartphone; riders additionally needed to navigate maps and own a vehicle. English as the primary language, built for Nigeria first, with room to scale across African markets.
Show Image
Design process
Mapping the ecosystem
Before any screens, I mapped how senders, riders, admins, and money needed to move together — including edge cases like receiver-side payment (in-app registration, shared payment link, or USSD short code) and drop-off to a third party when the receiver isn’t available.
Information architecture
With three apps, three user types, and dozens of interdependent features (onboarding, matching, payments, wallet, admin controls), the risk was sprawl. I built an IA to structure how features, screens, and permissions nested within each app — grouping content around what each user needed to see first (e.g., senders: send an item; riders: accept an offer; admins: monitor the network) and pushing secondary functions (wallet bill-pay, knowledge center, gamification) into clearly labeled, discoverable secondary layers.
Key decisions
Instant vs. scheduled delivery
Before any screens, I mapped how senders, riders, admins, and money needed to move together — including edge cases like receiver-side payment (in-app registration, shared payment link, or USSD short code) and drop-off to a third party when the receiver isn’t available.
Key design decisions
Instant vs. scheduled delivery, made explicit upfront. Rather than a single generic “book delivery” flow, senders choose their delivery type early — setting expectations for cost and timing before they invest effort in the rest of the flow.
A shared security code as the trust anchor. The same 6-digit code appears to sender, rider, and receiver at different points in the journey. One simple mechanic covers pickup verification, delivery confirmation, and third-party drop-off — without adding separate UI for each case.
Geofenced visibility for riders. Riders only see requests within their zone. This kept the matching experience relevant and reduced decision fatigue, rather than surfacing every open request across Lagos.
Wallet as a platform, not just a balance. Beyond delivery earnings, the wallet doubles as a bill-pay surface — airtime, data, electricity — for riders and senders, turning a transactional feature into a reason to open the app daily.
Admin as a control room, not an afterthought. Zones, base fares, per-km and per-time fees, and delay levies all needed to be tunable without a deploy. I designed the admin app around the levers ops teams would actually need to pull as the network scaled city by city.
Show Image
Outcome & status
[Add specifics once available — e.g., prototype validated with X riders/senders in Lagos, launch timeline, waitlist signups from prelaunch landing page, or current build stage.]
Reflections
Designing three interlocking apps at once meant every decision on the sender side had a ripple effect on riders and admins. The biggest lesson was to design the shared primitives first — verification, zones, pricing logic — before polishing any single screen, since those primitives ended up touching every flow in the product.
Design process
Mapping the ecosystem
Before any screens, I mapped how senders, riders, admins, and money needed to move together — including edge cases like receiver-side payment (in-app registration, shared payment link, or USSD short code) and drop-off to a third party when the receiver isn’t available.
MÁRCIO MOREIRA
©
Márcio Moreira
2026