Loop
- Role
- Product manager and design lead
- Program
- theBuild, SynClab, Team 1B, LogiTech
- Context
- 14-week PM program, 8-week build, one-week sprints
- Pilot market
- Kaduna, Nigeria
- Outcome
- Reached week-4 demo day
Overview
How do you add proof without changing who delivers?
Sellers in Nigeria deliver on trust alone. A rider says it arrived, the customer says it did not, and nobody can prove anything.
Role and constraints
I was product manager and, in practice, design lead: I wrote the PRD, directed two designers, audited every design pass and wrote the information architecture handoff.
Constraints
- An 8-week build
- A student team
- Low-end Android phones on patchy 2G and 3G
- No reliable street addresses in Kaduna
The insight
The seller’s existing relationship with her rider is the asset, not the problem. GIG, Kwik, Sendbox and Fez all ask her to switch riders. Loop adds tracking and proof around the rider she already trusts.
This idea drove most decisions, including rejecting a rider marketplace.
Impact
40+
story points delivered across the sprints before demo day
15
UX decisions documented, each with the alternative I rejected
Week 4
reached demo day with blockchain proof-of-delivery implemented
Decisions
Three decisions carry the story.
Decision
01
Riders never create accounts
- Decision
- The seller adds a rider by name and phone, and Loop sends a one-time link.
- Why
- A rider works for five or six sellers, so signing up for each would be the friction Loop exists to remove.
- Risk it created
- A mistyped digit sends a live link to a stranger.
- Answer
- An “Is this you?” screen showing his name and the seller’s shop name, a visible Declined status, and deactivation that truly kills the link.
Decision
02
A 30-second Undo with a permanent audit trail
- Decision
- A rider can undo a mistaken tap for 30 seconds.
- Why
- Silently erasing history would make the record less trustworthy, which is the product’s whole promise, but punishing honest slips would be wrong.
- In the record
- The mistake and the undo both stay in the seller’s history, and the customer only sees the corrected status.
Decision
03
Photo plus a 6-digit code to mark Delivered
- Decision
- I specified that Delivered requires both a photo and a code the customer reads out.
- Why
- A photo proves a delivery happened somewhere, the code proves it happened to the right person.
- Rejected alternative
- A photo-only override when the code is missing, because it would turn two-factor proof into optional proof in exactly the disputed cases.
- Instead
- The code is sent to the customer by SMS when the rider arrives.
Information architecture audit
I wrote an eight-page handoff for two designers, “Rebuilding the Dashboard’s Bones”, assuming no IA background. These are the four problems I found in the original dashboard.
Four problems
- Two kinds of cards pretending to be one. Three passive number cards sat beside a navigation shortcut with the same weight.
- A label that lied. A status pill said “Assigned”, but sellers never assign anyone. It teaches the wrong model of the product.
- Duplicated information. Rider names appeared in two places with no stated relationship.
- Urgent and routine at the same weight. “Needs a look” looked like “Delivered”.
The fix
| Layer | Purpose |
|---|---|
| Layer1. Needs Action | PurposeComplaints, unclaimed deliveries, pending riders. Top of the screen. |
| Layer2. At a Glance | PurposePure number cards, nothing clickable. |
| Layer3. Today’s Detail | PurposeActive deliveries. |
| Layer4. Shortcuts | PurposeRiders snapshot with a “See all” link. |
The rule: never put a shortcut at the same weight as a passive number. New Delivery moved into the persistent top bar so it is reachable from every page.
What changed my mind
| Decision | What changed |
|---|---|
| DecisionSMS alert on every new-device login | What changedRemoved as over-engineered for the risk |
| DecisionDrop-off hidden until pickup | What changedShown before claiming, since hiding it only moved the problem to a worse moment |
| DecisionCombined accept-and-start tap | What changedSplit into Claim and Picked Up |
| DecisionOptional handover code | What changedRequired, paired with a photo |
| DecisionWizard-of-Oz pilot | What changedCut |
Design leadership
I audited the designers’ work in ranked passes and tied each finding to a named principle (Fitts’s Law, Jakob’s Law, Nielsen’s heuristics), so the designer learned the reason, not only the fix.
Recurring issues: wrong terminology, screens that contradicted the product model, invented statuses, and rules that regressed across passes. AI-generated first drafts were fast but needed a review against the PRD every time.
Outcome
Loop stopped at week-4 demo day. The demo showed the seller, rider and customer views end to end with seeded data, and blockchain proof-of-delivery was implemented. A wallet and per-order tracking fee were being considered. The cohort ended and the team did not continue.
I ran one seller interview that confirmed two pain points: riders making side stops, and nobody able to prove who is right in a dispute. No pilot ran, so I make no claims about adoption.
What I would do differently
- Interview more than one seller before specifying 29 sub-flows.
- Run a card sort on the dashboard grouping before the designers rebuilt it.
- Put the Undo window in front of real riders instead of reasoning about it.
- Put a working tracking-link prototype in front of three sellers before building any backend.
