SnaQ

Context

Delivery apps here are built for somewhere else.

Ordering food in Accra runs on conventions the big delivery apps do not have a field for. You pay with MoMo, not a card. You tell the rider you are opposite the Shell station, because the street number will not help him. The kitchen sometimes finishes the tilapia before your order reaches it. SnaQ is a full prototype of a delivery app that treats those as the normal case rather than the edge case, built screen by screen and clickable end to end.

Problems

The hurdles, named plainly.

Four things get in the way of an order arriving correctly.

• Addresses do not find you. Formal street addressing is patchy, so a delivery lives or dies on a landmark and a line of directions. Most apps offer a single street field and a map pin, then leave the rest to a phone call.
• Payment is mobile money first. Card forms sit at the top of checkout and MoMo is buried as an alternative, which is the wrong way round for the majority of orders. Splitting a bill between MoMo and cash on delivery is common and supported nowhere.
• The price moves. Fees appear one screen at a time, so the number you agreed to at the cart is not the number you are charged at the end.
• Kitchens run out. Somebody has to decide between a substitute and a refund, and that conversation happens on the phone, after the rider has left, with nothing written down.

Approach

Design principles

Browsing

A menu you can read at arm's length.

The menu opens on full-width category banners rather than a grid of thumbnails: a photo of the food on one side, the category and its delivery time on the other. Tapping one opens that category under a header built from the same photo, so the transition is continuous. Search replaces the banners in place instead of opening a separate screen.

Ordering

Each dish asks the right question.

A rice plate and a bowl of soup are not priced the same way, so they do not ask the same thing. Rice comes with every sauce and the shito free, and says so. Soup includes the soup and charges for the meat, so the meat is a required choice and the button stays disabled, reading "Choose your meat", until one is picked. The running total sits on the button itself, where it cannot scroll out of view.

Introducing

A checkout that commits to its own number.

The cart lists subtotal, delivery, service fee and any discount as plain rows, each one tappable for a single line explaining what it pays for. Payment comes after the order button, not before it: the sheet opens already on the customer's default method, which is MTN MoMo out of the box, sends a mock approval prompt to the phone, and can split the bill between MoMo now and cash to the rider. The address the order is going to carries the landmark and the directions, because that is what the rider reads.

• Shows the whole price before checkout, and the receipt repeats it line for line.
• Defaults to mobile money with MTN, Telecel and AirtelTigo as first-class options.
• Splits a bill between MoMo and cash, with the two amounts always adding up to the total.

After the order

Proof, not promises.

Tracking plays a thirty-minute delivery out in about a minute. At "Order packed" the rider's photo of the sealed order appears, which is something concrete to point at if an item is missing later. If the kitchen runs out of a dish, tracking asks the customer to choose a swap at the original price or a refund, and either outcome is written onto the receipt. Once it arrives, the rider can be tipped on the same MoMo number.

Alternatives

The routes not taken.

The menu began as the usual search bar over a grid of cards, which looked tidy and told you nothing: every category was a word in a scrolling row of chips. The banners cost more vertical space and earn it by showing the food. Kitchens nearly became a filter rather than a place, too, until it became clear that opening hours and a loyalty card need somewhere to live.

Reflection

Project takeaways.

• Local conventions belong in the data model. Adding a landmark field late would have meant touching the address form, the cart, the order, the receipt and the printable invoice. Designing it in from the start made it one field that travels.
• One source of truth for money. Fees are computed in a single module and stored on the order, so the cart and the receipt cannot drift apart. That constraint removed a whole class of bug before it existed.
• Ask, do not assume. The substitution flow is the part people react to: a swap the customer approved is a different experience from a swap they discovered on arrival.