2026 Taager
Taager.com Platform Revamp
A merchant web app redesigned around the everyday work of selling online: managing orders, reading sales, and acting on both.
Taager’s merchants run a business inside the web app: they source products, place orders for their customers and watch what sells. The old interface had grown feature by feature until the most common tasks took the longest routes. The revamp started from the work, not the screens.
01
Context and problem
The platform served thousands of active merchants, most of them on mid-range Android phones and shared laptops, switching between Arabic and English. Support tickets clustered around three jobs: finding an order, understanding why a payout changed, and knowing which products were worth promoting.
Session recordings showed the same pattern: merchants opened four or five pages to answer one question. The information existed, but it was organised around database tables rather than merchant decisions.
02
Research
I ran twelve remote interviews with merchants across three cities and shadowed four of them for a day each. Metabase gave us the order and payout funnels; Mixpanel and Clarity gave us where people hesitated and rage-clicked.
The synthesis produced five daily jobs and a clear ranking. Orders and payouts were daily; product discovery was weekly; account settings were almost never. That ranking became the navigation.
- 12 interviews, 4 shadowing days, 2 survey rounds
- Funnel baselines for order placement, order tracking and payout review
- A shared glossary so product, support and engineering used the same words
03
Approach and key decisions
Four decisions shaped the product. Each one was tested with merchants before engineering started.
A home built from today’s work
The dashboard became a short list of things that need attention today: orders to confirm, payouts that moved, products running low.
Orders as one continuous record
Status, customer, courier and payout live in one timeline per order, so support and merchant look at the same page.
Numbers with a reason attached
Every sales or payout figure links to the orders that produced it. No more unexplained totals.
A bilingual system from day one
Components were designed and built for RTL and LTR together, with type and spacing tokens shared across both.
04
Design system and build
I built the component library in Storybook alongside the engineers, in TypeScript, with tokens exported from Figma. Designing in code surfaced edge cases early: long Arabic product names, zero-state payouts, slow networks.
Releases went out behind flags to ten percent of merchants first. We watched the funnels for a week before each wider rollout.
05
Outcome
Illustrative figures. Replace with measured outcomes before publishing.
fewer steps to find and act on an order
drop in payout-related support tickets
merchant satisfaction after rollout
components shipped in the shared library
The new home screen answers the question I used to open five tabs for.
Interview participant · sample
What I’d carry forward
- Rank jobs by frequency before touching navigation.
- Numbers without a drill-down create support tickets.
- Designing in code with the team removed a whole class of handoff bugs.
→ Next project
Taager Merchant AI Assistant
Contextual help for sellers while they work inside the platform, from drafting a customer reply to explaining a payout.
