Designing both sides of a marketplace

Naming the sides at Zart

I lead mobile design at Zart, a marketplace in Nigeria that connects people with vetted plumbers, electricians, carpenters and painters. The brief said booking app. I argued that booking a stranger is easy and trusting one is hard, and the team built a trust platform instead.

A customer uses Zart a few times a year. A tradesperson uses it every working day. So the product has a customer mode and a tradesperson mode. The customer picks a trade, sends a request with the details and a photo, and follows the job. The tradesperson gets a dashboard of jobs, a schedule, messages and a wallet that pays out to a bank. The two share the same jobs, data and stages, but not the same screens. Those names became how the team described the product, and they settled most arguments about what belonged where.

Operator mode at Zart is not a third side. It is the tradesperson together with Zart's operations team, and verification shows why. A tradesperson submits a photo, a government ID, a utility bill and a guarantor form. The operations team checks them. Only then does a badge appear on the profile, with the evidence behind it. I turned those steps into flows and states engineering could build. The customer sees one badge. Behind it is a manual queue that grows with every tradesperson who joins. It is one of the two things customers never see that took me the most work.

Zart also has no general inbox. Every message belongs to the job it is about. Tradespeople had been juggling calls and chats with no record, and details got lost. There was also the business. It was important for the design to cushion Zart from losing out through a general inbox, where it would have little or no control over what was shared. It has happened before: contact details get swapped, and the job leaves the platform. A conversation that is not about a job has nowhere to go.

Running the business from the shop

In 2024 I was the product designer on Everything African, a UK online shop where the African diaspora buys groceries, fresh produce and ready meals. Here the operator is the team running orders, working from the same system as the shop.

The product page carries the operator's promises. Each variant shows its price and how many are left. A toggle lets the shopper ask for it cut to order, before Add to Basket. The basket totals the weight beside the price, so delivery is worked out before checkout, and the order arrives the next working day.

Each promise is kept behind the screen. The inventory holds a stock count for every variant, and the operations team keeps it current, or the trust runs the other way. Cut to order becomes a preparation step before dispatch. Each order moves through one set of stages from paid to delivered, and delivery updates are structured notes, not phone calls. The customer's status and the operator's queue read from the same order, because perishable goods leave no room for two systems disagreeing.

The cost was an interface that carries states and controls a customer never sees. That is more to design, and more to keep simple. The inventory and the order stages shipped as I designed them.

Becoming the operator

Ansarr is my own. Researchers fund studies, and educated respondents answer them on their phones and are paid in naira. I designed and built all of it, and it is coming to Google Play and the App Store.

Researchers and respondents share one app, switched by a link on the Profile tab. The operator's side is not in the app at all. It is a web admin, and I use it.

The respondent is promised things on screen. A study page says plainly that the researcher never sees their name or contact details. Where a name would be, the researcher sees a code, like JPEG5S. After a respondent submits, the wallet shows the reward as pending, paid automatically if nobody reviews it in five days.

The admin is where those promises are kept. From it I search users and set their verification level, pause, resume or close a study, and approve or reject submissions by the same code the researcher sees, never by name. Bans are reversible, and a banned account cannot move money. Accounts that share a device have their cash-out held for review. The admin is intuitive for Ansarr, and simple to use. One overview shows the people, the studies and their responses, and the money: in escrow, in wallets, paid out and in fees.

The other thing that took the most work is the escrow refund when a study closes. On screen, closing a study is one tap. Behind it, the study cannot close while a response is still waiting for review. The researcher reviews each one or approves them all, and only the money held for responses that never came goes back to the researcher's wallet, so a pending reward survives the study closing. On Ansarr, money only moves inside the database: every balance change happens in one database function that checks who owns what, and the refund is one of them. That is what made it hard: it runs there, alongside approvals and the five-day automatic payment on the same study.

Start with what makes it work

My advice to a team designing its first two-sided product is about the MVP. Get the first functionality that makes the app work, rather than bombarding it with features that might not be used later.

On a marketplace, part of what makes it work sits on the side the customer never sees. At Zart that made the first version bigger, not smaller: verification, stated expectations and job tracking were the product, not features for later. A badge is only worth showing if someone checked. A stock count is only worth showing if someone keeps it current. A respondent's code only protects them if the name behind it never reaches the researcher.

That side is not a feature for later. It is where the customer's trust is made.