Ntɛm
A three-sided marketplace connecting customers, independent merchants and riders through one coherent ordering and fulfilment system.
01 / The problem
7:10 pm, Tuesday. Ama gets home from work. Her daughter has a fever and needs paracetamol. There are no vegetables for tomorrow’s stew. She hasn’t eaten.
Three needs, three kinds of business, one evening. Today that means a pharmacy run, a market trip and cooking — or three separate apps and three separate deliveries.
Every quick commerce app in the market solves one category at a time. Ntɛm treats the evening as the unit of need rather than the category — which means one basket containing three merchants with radically different operating realities.
| Merchant | Item | Prep | Behaviour |
|---|---|---|---|
| Yaa's Provisions | Vegetables | ~2 min | Pick from shelf |
| Kofi's Chop Bar | Waakye + tilapia | ~20 min | Cooked to order |
| Adom Pharmacy | Paracetamol | ~3 min | Pick, may verify |
The design question: how do you present a single, honest promise on top of three incompatible timelines?
Role
End-to-end Product Designer
Scope
Research · IA · Interaction · System · Prototype
Platform
Android-first mobile ecosystem
Market
Accra & Kumasi, Ghana
02 / Market conditions
Two of my starting assumptions were wrong. Payment friction and data cost are the obvious angles for an African market — and neither survives contact with the numbers.
The finding that shaped the strategy
Melcom launched NOWin 2026 — 20-minute delivery from 65 owned stores. Every well-capitalised competitor is building a vertically integrated supply chain. Ghana’s retail depth, meanwhile, lives in provisions shops, chop bars and neighbourhood pharmacies that no aggregator can acquire.
Wedge 01 · Supply-side moat
Melcom sells its own stock. Ntɛm digitises everyone else’s. A platform that makes independent merchants operable builds a catalogue a single retailer structurally cannot match — which is why the merchant app is not a companion product, it is the product.
Wedge 02 · Demand-side experience
Single-vertical players cannot fulfil an evening that needs vegetables, dinner and paracetamol. The merchant network makes the multi-basket possible; the multi-basket makes the merchant network valuable. Neither works alone.
03 / Users
Two users of the same age can need entirely different interfaces; two users thirty years apart can need the same one. So each persona is defined by how they actually engage with the system — search-first, browse-and-compare, guided, interrupt-driven, glanceable.
The Fluent Shopper · 28
“I don't want to browse. I know what I need — I need it to be here in thirty minutes.”
The Deliberate Provider · 36
“If I see one price in the store and another at the end, I won't come back.”
The Assisted Newcomer · 54
“If I press the wrong thing, will my money go?”
Why Auntie Efua matters
Designing for her raised the floor for everyone. Every clarity decision made for her — plain labels, explicit confirmation, honest totals — measurably reduced friction for Ama and Kwame too. She is not an edge case. She is the reason the product is usable.
High SKU count, steady volume. Sets up in bulk, then manages exceptions.
Cooks alone. Must accept or decline in under five seconds, mid-service.
One-handed, phone mounted, in traffic. Navigates by landmark, not street.
New to the work. Needs the app to teach the job, not assume it.
04 / Architecture
A naive system delivers three times, charges three fees and knocks on the door across an hour. The fix is not a screen — it is how the order itself is shaped.
Each merchant owns a partition, not a slice of a flat list. The customer sees one basket; the system holds three independently addressable objects under it.
One order moving across three applications. The platform absorbs the complexity so the edges stay simple.
Categories lead and merchants follow. Ama knows she needs paracetamol, not which of eleven pharmacies stocks it — requiring users to understand the supply chain before they can shop would make the platform’s differentiator the customer’s problem.
05 / Interaction design
Most screens in a commerce app are solved problems. A product page is a product page. Three screens here are not, because no existing app has to answer what they answer.
Screen 01
One basket, one title. The plural would undo the entire premise — Ama is placing one order for one evening.
The store card is the partition made visible
Grouping is not cosmetic. It is the same boundary that later lets one store fail without taking down the order, so the user learns the structure while shopping calmly.
Price per unit, in local measures
1 olonka · GH¢25/olonka. Kwame buys in olonka, bowl and paint rubber, not kilograms. Metric units would be a translation, not a design.
Prep time on the card, not at checkout
Ordering hot food is a choice about time, and that choice belongs where it is made.
The delivery fee lives here
Late-revealed costs are the most common trust failure in commerce — and one fee for three stores is the clearest proof of value, so burying it would hide the argument.
Screen 02
An adaptive system is by definition invisible. If the customer can’t see it, it can’t build trust — and if you expose the algorithm, you’ve built a logistics dashboard rather than a shopping app. Naming the preference is the narrow path between them.
Screen 03 · the hard one
Money has already left. A child is sick. A rider is waiting. And the person on the other end may never have completed a purchase in an app before.
Scope before problem
“One item is not available.” The first three words say this is small. “There’s a problem with your order” spikes anxiety before she has read anything.
The merchant suggested it, and is named for it
Yaa knows her shelf; the platform doesn’t. The merchant app will not let her flag an item without either offering a substitute or explicitly confirming there is none.
The refund is a number, before the decision
GH¢4.00 comes back to your MoMo. Exact amount, named destination, present tense. An unquantified refund is a lost one.
Buttons are answers, not commands
“Yes, send the aubergine.” Each button contains its full consequence, so a skim cannot produce an expensive mistake.
Inaction is safe, stated plainly, and costs nothing
If she is busy with a feverish child and never opens it, the item is removed and she is refunded in full. She cannot lose by hesitating.
Most commerce apps default the other way: silence means the substitute ships. That optimises basket value at the cost of trust — the wrong trade in a market where one bad story travels a neighbourhood faster than any advertisement.
06 / Interactive prototype
Not a click-through. Three real apps sharing one order object — act as the merchant and the customer’s screen changes.
Switch apps with the tabs on the phone. The order follows you — accept as the merchant and the customer’s tracking screen updates.
Loading Ntɛm…
400 × 820 · Pixel-class Android
Try this
Customer — Build a basket across three stores, then pick a delivery outcome at checkout.
Merchant — Accept as Yaa, Kofi and Adom. Then mark an item out of stock and offer a substitute.
Customer — The exception is waiting on Tracking, with a live four-minute countdown.
Rider — Go online. The run is sequenced so the chop bar is collected last.
Do nothing when the substitution appears. It removes the item and refunds in full — inaction is always the free, safe outcome.
07 / Design system
Every quick commerce app in the region looks the same: blue or green, white, high-gloss, imported. A product whose differentiator is local supply cannot look like it was designed somewhere else. The palette comes from where the product operates — the clay-red of laterite roads, the deep green of plantain and garden eggs, the gold of late Accra afternoons.
Riders work outdoors in Accra sun and customers check ETAs on the street, so every pairing was computed against WCAG 2.1 rather than eyeballed.
| Pairing | Sample | Ratio | WCAG 2.1 |
|---|---|---|---|
| ink-900 on sand-050 | GH¢137.00 | 16.31:1 | AAA |
| green-600 on sand-050 | GH¢137.00 | 7.35:1 | AAA |
| white on clay-600 | GH¢137.00 | 5.54:1 | AA |
| clay-700 on clay-050 | GH¢137.00 | 6.47:1 | AA |
| red-600 on red-050 | GH¢137.00 | 4.64:1 | AA |
| gold-500 on white | GH¢137.00 | 2.34:1 | FAIL |
The gold problem
Gold scores 2.34:1 against white — it fails as a text colour and as a button fill. Darkening it until it passed would have produced a muddy brown that lost the quality worth having. So the constraint is documented and enforced instead: gold is a surface and an accent, never a text colour and never a primary button.
A design system’s job is to record where the brand and accessibility disagree, and to decide once, in public, rather than repeatedly and quietly in individual screens.
The three apps share tokens but not personality. Kofi accepts orders between serving customers, so density is respect for his time. Ibrahim reads at a glance while moving, so sparseness is safety. Ama browses, so imagery is the point.
The product is named Ntɛm, and the character ɛ (U+025B) is essential to Twi orthography alongside ɔ. Many popular UI typefaces lack these glyphs or fall back in ways that break the line. A product named in Twi cannot use a typeface that cannot spell its own name.
One pixel above the conventional 16, applied everywhere, measurably eases reading for Auntie Efua and costs the other personas nothing. Targets sit above the 44dp convention because she taps deliberately and imprecisely, and Ibrahim taps one-handed on a mounted phone. Accessibility gains are usually made in decisions this small.
08 / Process
The order reducer went through 21 assertions in Node before a single screen was built — including the one that matters: cancelling one store refunds exactly that store’s subtotal and leaves the other two partitions intact. If that hadn’t held, the substitution screen would have needed special-casing at every layer.
The rider never received a job. A run is only built once every merchant accepts — but the merchant app initially exposed only two of the three. The flow diagram had been correct and the implementation was not, which is the argument for prototyping in code rather than in frames.
Static mock data, no backend, no persistence. This is a concept project: the deliverable is the interaction model and the cross-app choreography, not the plumbing. Next step is moderated testing with Ghanaian users against the live build.
09 / Principles
Principle 01
Four routing models sit behind the checkout screen, chosen on prep-time variance, merchant proximity, distance and rider supply. Ama sees none of it — she answers one question: together, or as it comes? The engine can be rewritten without the interface changing, because the interface was never describing the mechanism.
Principle 02
Each merchant owns a partition rather than a slice of a flat list. That one decision is why failure isolation, per-store tracking, partial refunds and merchant privacy fall out of the model instead of being engineered individually. Cancel one store in the prototype and the other two stay intact.
Principle 03
When an item goes unavailable after payment, silence removes it and refunds in full. The system never spends her money on something she didn't confirm. Most apps default the other way, optimising basket value at the cost of trust — the wrong trade in a market where digital commerce is still earning credibility.
Principle 04
One app serves every fluency level through progressive depth rather than a simplified mode. Fluent users travel further per tap; nobody is segregated. The same pattern carries into the merchant and rider apps, where one shared core does the essential job and additional structure waits for those who need it.
Principle 05
A merchant marking something unavailable must suggest a substitute or explicitly decline one — she knows her shelf, the platform doesn't. The rider never meets the problem as a decision, only as an updated list. Complexity is absorbed in the middle so the edges stay simple.
Principle 06
Delivery fee in the basket, prep time on the store card, refund amount above the buttons. Late-revealed costs are the most common trust failure in commerce — and one fee for three stores is the clearest proof of the product's value, so burying it would hide the argument.
Continue exploring
