Skip to content
All work

Zeli Admin

Zeli is a fashion shopping app for Myanmar that I founded. It sells two kinds of stock in one cart: trend pieces imported through our own warehouse at the Muse border, and clothes from local Myanmar brands. I designed the admin console that runs all of it, and wrote every flow as a spec a developer can build from.

Role
Product Designer & Founder
Product
Back office for a cross-border fashion app
Platform
Web admin (Laravel Filament)
Status
Designed, in development

Each screen on this page runs live, with sample data. Click the black buttons: the order moves, the price re-calculates, the QC photos go out.

The challenge

One order can hold two very different journeys, and money moves before goods do.

  • Two kinds of stock, one cart

    An imported dress takes nine steps to reach Yangon. A local brand's top ships across town the same day. Both can sit in one order, and the customer should see one order.

  • Money before goods

    Imports need a 50% deposit before anything is bought, the rest is cash on delivery. Local brands are cash on delivery. Nobody should buy a thing until the deposit is in.

  • Trust across a border

    Customers buy from photos of items they cannot touch. The warehouse checks every piece and sends real photos back before it travels on.

What I designed

The whole back office, in the order the team works it.

7
Sections, matching the sidebar
20
Flows, each with its own spec
32
Screens, most of them clickable
13
Business rules, shared by every flow
  • Sales

    Orders, MMQR payment exceptions, returns and refunds.

  • Catalog

    Products, pricing rules, categories, size charts and goes-with rules.

  • Marketing

    Vouchers, flash sales, bundles, looks, home content, push and campaign pages.

  • Fulfilment and partners

    Purchasing from suppliers, the Muse warehouse, and the local brands who sell on Zeli.

Order to doorstep

One order, split into shipments that each move on their own.

When an order holds imported and local items, it splits itself: one import shipment, and one shipment per local brand. Each shipment shows only the next action for the person who owns that step, as one black button. The order's own status is never set by hand; it is worked out from its shipments, and every change is written to a log nobody can edit.

  1. 01Pay

    A dynamic MMQR code, valid 15 minutes, any bank or wallet app.

  2. 02Buy

    The deposit lands, and a purchasing task opens for the buyer.

  3. 03Check

    The Muse warehouse checks the item and sends photos.

  4. 04Deliver

    A truck to Yangon, then a rider who collects the rest in cash.

Try it: press the black button in each shipment. The order status, the deposit and the log follow.

Payments

Only the exceptions reach a person.

There are no payslip screenshots to check. Every order gets its own MMQR code with the amount inside, and the provider's callback matches it to the order on its own. The Payments team only sees what could not be matched, sorted by what went wrong, with two choices: accept or refund.

ExceptionWhat the team does
  • Short or overThe amount does not match. Ask for a top-up, or refund the difference.
  • Paid lateThe code had expired. Reopen the order, or refund.
  • Paid twiceKeep one, refund the other.
  • No order foundAsk the payer, then link it to an order or refund.

Pricing

The price is a formula, not a guess.

Import prices come from settings, not from someone typing a number. Supplier cost plus China shipping, times the exchange rate, plus freight and packaging is the landed cost. A markup per category and a rounding step give the price in the app. When the yuan moves, one number changes and every product re-prices. The crossed-out price follows a rule too: only a real past price, never more than 40% off.

(cost ¥ + shipping ¥) × rate + freight Ks = landed → × (1 + markup) → round up to 500

Change the rate or the markup. The breakdown, the app card and its discount label update as you type.

Quality check

The customer sees the item before it crosses the country.

Every imported piece stops at our warehouse in Muse. The team photographs it, measures it and checks the label, then the customer gets a push with the photos. They approve, or report a problem and start a return. If they say nothing for 24 hours, it approves itself, so a quiet customer never holds up a truck.

Take the photos and tick the checks to send them. The customer's side starts its 24-hour clock.

Handoff

Every flow is a spec, not a picture.

I designed the console on a canvas in Claude, flow by flow, in the order of the sidebar. Each row is a spec on the left and its screens on the right, with numbered pins on each screen that match the spec. A developer can build a flow without asking me what a button does.

Part of the specWhat it answers
  • Who, trigger, done whenWho uses the flow, what starts it, and how we know it is finished.
  • How it worksEach step, who does it, and which screen it happens on.
  • StatesEvery state, what it means, and who moves it to the next.
  • Screen annotationsNumbered pins on the screen, explained one by one.
  • Data and APIThe endpoints and tables the flow needs.
  • Edge cases and open questionsWhat can go wrong, and what is still to decide.

My role

  • Founded Zeli and set the business model
  • Wrote the business rules: deposit, delivery, returns, discounts
  • Designed the pricing formula and its settings
  • Designed all 32 admin screens and their prototypes
  • Wrote 20 flow specs with states, APIs and edge cases
  • Set the rules the customer app must follow

Tools

ClaudeClaude CodeLaravel FilamentFlutterMMQR
KL

Klink

Leading product design since the founding stage

KDS

Klink Design System

One set of components, any brand color, light and dark