AZIBA: a fashion marketplace from zero to launch

Problem

Nigerian fashion commerce mostly happens on Instagram and WhatsApp. You find a look on a seller’s grid, DM for the price, pay into a bank account, and hope the parcel arrives. It works, but there is no consistent sizing, no returns, no single bag, and no way to trust a seller you have not bought from before.

AZIBA’s answer is curation plus fulfilment: a vetted set of independent brands in one catalogue, one checkout that can hold items from several of them, and Shipbubble handling delivery. Two goals pulled against each other and both had to be met. It had to feel like somewhere you browse for pleasure, and it had to behave like a marketplace that reliably gets a parcel to your door. All of it on web, iOS and Android, from one designer.

Evidence / research

I started from the journey a buyer goes through today: find a seller on Instagram, DM for the price, pay into a bank account, then arrange or wait for delivery. Every handoff in that chain is a point where trust can break: an unclear size, a seller who goes quiet, a parcel with no tracking. Those breakpoints became the design brief. Curation answers “can I trust this seller”, the measurement profile answers “will it fit”, and Shipbubble’s fulfilment answers “will it arrive”.

My role

Shipbubble is a logistics company, and AZIBA is the consumer product it built on its delivery rails. There was no product, no brand design language, and one designer. I owned the whole surface: information architecture, user flows, the responsive web storefront, the buyer app on iOS and Android, and the design system that keeps the three in step, from the first IA sketch to design QA at launch.

Constraints

One designer had to take three platforms from a standing start to launch in three months. A single checkout needed to handle several independent brands, their fulfilment information and sizing, while discovery still felt appropriate for fashion browsing.

Options considered

Two forks shaped the product. The first was the storefront: a catalogue-led search grid is the e-commerce default and the cheapest to build, but it treats fashion like groceries. An editorial, occasion-led storefront costs more to curate, but it matches how people here actually shop. The second was the platforms: a web funnel that pushes people to the app is the common pattern, but it splits the cart and the account. One store behind both shells meant more alignment work up front, and a bag that follows you between devices.

Decision

Use one information architecture and design system across platforms, with a shared account and cart. Group the bag by brand but resolve it into one checkout. Put sizing, dispatch and returns information close to the buying decision.

Design

One system, three surfaces

I drew the information architecture once, built one component library, and put a shared cart and account behind all three surfaces. Web and app are not a funnel and its goal, they are the same store with different shells. You can start a bag on a laptop and finish it on your phone, or the other way round. The app adds the native layer on top: push, an offline wishlist, saved payment methods.

The storefront is built to read like a magazine, not a search grid. Discovery is occasion-led, because that is how people here shop: “what do I wear to the owambe”. Shop-by-occasion sits on top of the plain catalogue, next to curated Edits and “The Aziba Journal”, so browsing always has somewhere to go that is not a filter.

aziba.co

Product and sizing

Returns are what kill fashion e-commerce, so the product page and the sizing system are built to prevent them, not just to process them.

Every product page states the dispatch window and the returns window on the page itself, before the bag, not buried in a policy link. Add to Cart sits next to Buy Now, with the gallery, colour and size selectors, wishlist, ratings and a “You May Also Like” rail.

Behind size selection is a measurement profile: height, weight, bust, waist, hips, and shoe size in US, UK and EU, with an illustrated how-to-measure guide. It feeds a size recommendation per item. The consent notice asks you to label a profile you are filling in for someone else “Sister” or “Father” rather than using their name. Data minimisation written into the copy.

aziba.co

aziba.co

One bag across many brands

An AZIBA order can hold items from several independent brands at once. The bag groups by brand and shows a subtotal per brand, so a mixed order never looks like a bug, and each brand keeps its own “Leave a note”. Checkout then resolves the whole thing into one payment, one coupon and one delivery choice, with tax and shipping broken out before the total and each shipping speed showing the date delivery starts from.

“Pay for me” generates a shareable payment link, so a friend or family member can pay for your bag. In this market they often do.

aziba.co

aziba.co

Same store, two doors

Because the cart and the account are shared, the app is not a separate destination to push people towards. The “Get the App” page says exactly that: the same catalogue and the same cart, plus the things a phone does better, push, wishlist sync and saved payment methods.

aziba.co

Collaboration / implementation

I worked with the founder / product lead and backend, mobile and web engineers, taking the design from initial information architecture through design QA at launch. The shared component library supported the three platform implementations.

Measurement

The design was built to move three numbers: checkout completion on a bag that can carry several brands at once, the return rate that the measurement profile exists to bring down, and repeat purchase, which is the real test of whether curation plus fulfilment beats buying through a DM. Those are still early, so I hold them as targets rather than results, with firm figures to follow once there is a stable stretch to report.

Result

AZIBA launched on the web and on the App Store and Google Play with 500+ products from 10+ independent sellers, all running on one design system across three platforms.

What I learned

The biggest lesson was how much marketplace design depends on making responsibilities clear. One bag can contain several brands, but the buyer still needs to understand sizing, dispatch, delivery and returns before paying. That shaped both the product page and the way the bag groups items by brand.

Designing across web, iOS and Android also reinforced the value of agreeing on the shared behaviour early. A component library helps with consistency, but the cart, account and checkout rules have to align too. Next, I would use checkout drop-off and return reasons to decide which parts of that experience need attention first.