Case 01 of 06
One order, four apps.
The customer, driver, vendor and business apps behind a delivery service across Ethiopia, all on one design system. I’m the only designer on it.
This is the real Figma prototype, running live. Order food, follow the rider and rate the vendor, the way customers do.
Things to try
These are the real Figma prototypes, embedded live, so they need a stable connection and can still feel slow or skip a step. For the full picture, open the Figma file. Every screen, state, the design system and the components are there.
Loads on tap, not on scroll
Keeps this page fast for everyone who only reads the case study.01Overview
klik delivers food, groceries, parcels, medicine and more across Ethiopia. The core idea of this work: whatever a customer tells us, like an allergy, travels with the order to whoever is holding it next.
02The problem
A customer with a garlic allergy was sent food containing it. The allergy was saved in the customer app, but nothing carried it to the person cooking the order.
Saves “Garlic” in Preferences
Sees the items, not the allergy
Hands over a sealed bag
03Research
01Customers would put allergies in the order note.
Vendors pack from the item list. At rush hour nobody reads the note.
02One spinner is enough while payment runs.
Mobile money confirms on a separate USSD prompt, so people thought the app had frozen.
03Each app could be designed on its own.
The handoffs between apps are where things break: allergies, payment status, parcel handover.
04What we learned
At rush hour, vendors pack from the item list. Free text at the bottom of an order rarely gets read.
With no sign of what is happening, a pending payment looks exactly like a frozen app.
Riders and customers both needed a clear moment when a parcel changed hands.
The rule we took into every app
If a detail matters to the customer, it has to reach whoever is holding the order.05What I changed
The customer declares allergies once. The vendor meets them twice: as tags on the incoming order before accepting it, and as a Critical alert while packing it.
Vendors packed from the item list. An allergy the customer saved in Preferences never reached the kitchen.
The allergy now rides on the order. It shows as tags before the vendor accepts, and again as a Critical alert while packing.
06Four apps, one job each
Drivers clock in at stations, run multi-stop parcel routes with a call before arrival and a photo at handover, and see a weekly ranking. Vendors accept orders against a timer. Businesses send parcels in bulk.
Order, track, rate
Stations, routes, handover photo
Accept on a timer, pack, hand off
Bulk parcels and team accounts
07Paying with mobile money
Mobile money confirms payment on a USSD prompt outside the app. The app was waiting on something it couldn’t see, behind one spinner.
Processing, paid and failed each get their own state, so the customer always knows where to look next.
08How it changed
I designed klik from its first release. Each version answered what the last one taught us, so the screens below are the same product growing up.
v1.0The first release
Customer and business apps, built fast to prove that Addis would order this way.
v2.0Four apps
Vendor and driver apps joined. Each one grew its own patterns, and the handoffs started to break.
v2.1One system, now
One design system across all four apps, light and dark, with allergies carried from order to kitchen.
09Results
Allergy complaints dropped after the tags and Critical alert shipped.
Fewer “did my payment go through?” support tickets once each state had its own screen.
Vendors started pointing to the allergy tags themselves when packing.
The listing screenshots I designed for the App Store and Google Play. Nine frames, one feature each.
klik v2.1, built on Figma variables. One set of tokens drives all four apps, light and dark, with a Brand mode that switches between Customer red and Business blue.
Every screen and state, the components and the design system, in the file I designed it in.
Next project, 02 of 06
FX League