Pick-up Code — Fixing the Pharmacy Payment Loop

The problem

Pharmacy partners were dispensing Wellahealth medications and not confirming it in the app. The consequence was delayed payment. The consequence of delayed payment was deprioritised orders. The consequence of deprioritised orders was patients not getting their medication. Everyone assumed the pharmacists were simply being negligent. The research told a different story: the confirmation step asked the busiest person in the room to stop what they were doing, pick up their phone, and complete an admin task with no immediate benefit to them. The product had been designed for Wellahealth's operational needs, not for how pharmacies actually worked.

What I did

• —

  Research setup: ran a mixed-methods study — 100 pharmacy partner surveys to understand scale and patterns, followed by 10 in-depth interviews to understand the lived experience. Interview participants were recruited to represent three distinct pharmacy sizes: single-counter independents, small chains, and hospital-linked pharmacies. Each had a different failure mode.

• —

  Key insight: surveys showed that 78% of pharmacists said they intended to confirm but 'forgot.' Interviews revealed that 'forgot' was doing a lot of work. Confirmation happened after the customer left the counter. By then, the pharmacist had seen three more customers, taken a phone call, and mentally closed the transaction. The confirmation step needed to happen at the moment of dispensing — or not at all.

• —

  Journey mapping: mapped the full HMO enrollee journey across 5 stages — Initiation, Negotiation, Enrollee Activation, Fulfilment, and Reconciliation — with a parallel pharmacist journey overlaid. This made visible what spreadsheets had hidden: the confirmation gap wasn't one problem, it was three independent gaps that happened to compound each other.

• —

  Competitive audit: reviewed confirmation and verification patterns across healthcare (medication dispensing in the NHS, US pharmacy POS systems), finance (M-Pesa agent confirmation, OTP flows), and logistics (last-mile delivery confirmation by Jumia and DHL Nigeria). The common pattern across high-performing systems: confirmation is a byproduct of a step the user was going to take anyway.

• —

  Ideation and solution selection: facilitated a cross-functional workshop with pharmacy operations, product, and engineering. Generated 12 concepts, converged on 4 viable approaches, and evaluated each against three criteria — pharmacist effort, enrollee accessibility, and technical feasibility. The Pick-up Code concept won on all three: it made confirmation a byproduct of identifying the customer, which pharmacists were already doing.

• —

  Wireframing: designed three versions of the code entry flow — a QR scan, a manual 6-digit entry, and an NFC tap. Sketched each as a low-fidelity flow and walked them through with 4 pharmacists. QR scan was fastest but immediately rejected: 'not all customers have smartphones.' NFC was unfamiliar. Manual entry won — slightly slower, but universal and immediately understood.

• —

  Prototype and usability round 1: built a mid-fidelity prototype of the full pick-up code flow and tested with 8 pharmacy staff. Finding: the code entry screen asked for confirmation before submission — a standard UX pattern — but pharmacists were interpreting it as an error state. Removed the confirmation modal and replaced it with an immediate success state. The flow tested cleanly in all subsequent sessions.

• —

  SMS design: the code was delivered to enrollees via SMS. Early testing revealed a critical problem: the message was splitting across two texts on some networks, and the code was landing in the second message. Some users received only the first. Worked through 6 copy iterations with the engineering team to compress the message to under 160 characters with the code appearing in the first 60. Tested across 4 Nigerian networks before sign-off.

• —

  Ledger balance — the hidden problem: during testing, a separate issue emerged. Pharmacists were checking their wallet balance before deciding whether to prioritise Wellahealth orders. Several said they had 'no money in their account' — but their balance was positive. Further investigation showed they were seeing their total balance, which included assured-but-locked funds. They couldn't withdraw it, so to them it wasn't real money. Designed a three-part balance display: total, locked (with release date), and withdrawable. Added a plain-language explainer on first view. Post-launch, payment anxiety dropped measurably in qualitative follow-up.

• —

  Usability round 2: ran a second round with 10 participants on the high-fidelity prototype — 7 pharmacists and 3 Wellahealth operations staff. Zero critical issues. Two minor copy changes. Signed off for development.

Results