Overview
A design system isn't just a component library — it's the foundation that determines how fast a product team can move and how consistent the product feels to its users. For noon's seller-facing products, that consistency was missing.
I built the Sellerside design system from the ground up: establishing design tokens and foundations, then building out a full component library used by both designers and engineers across the Seller Lab product.
The Problem
A growing product without a shared foundation
As the Seller Lab product grew — Catalog, Onboarding, Navigation, and more — design inconsistencies accumulated. Different parts of the product used different spacing, colours, and component patterns. Designers were recreating the same elements from scratch, and engineers were implementing multiple versions of the same component.
Every new feature added to the debt. There was no single source of truth.
What I built
Foundations + 20+ components
The system covers two layers: design foundations (the tokens and rules) and a production component library.
Component library
ButtonsBadgesAlertsBannersTabsFile UploaderEmpty StatesTour / TutorialTooltipInput FieldTableCheckboxProgressStepperCombo BoxNavigationPaginationAvatarChipSwitchToggle Button
Process & Key Decisions
Building something teams will actually use
Decision 01
Audit first — don't start from scratch if you don't need to
Before designing a single new component, I audited what existed across the product. Many elements were consistent enough to standardise rather than replace — which reduced the disruption of adoption and gave teams familiar components to start from.
Decision 02
Document usage intent, not just spec — components need to explain themselves
A component without documented usage guidance gets misused. Every component was shipped with variant documentation, do/don't usage examples, and notes on when to use it vs. an alternative. The goal was to reduce designer-to-engineer back-and-forth.
Decision 03
Prioritise the components that appear most — table, input, and navigation first
Rather than building the full library before releasing anything, I prioritised components by frequency of use across the product. Table, Input Field, and Navigation were built and adopted first — they appeared in nearly every flow — before moving to lower-frequency components.
Decision 04
Maintain a change log — systems break silently without one
Every update to the system was tracked in a structured change log with version notes, what changed, and what it affects. This let teams know when to update their designs and gave engineers a clear reference when implementation diverged from the Figma spec.
The Work
Key screens
📸 Component library overview — export from Figma Sellerside DS file
Component Library
20+ production components — each with full variant coverage, usage documentation, and do/don't guidance.
📸 Foundations (Colours, Typography, Icons) — export from Figma Sellerside DS file
Design Foundations
Colour tokens, typography scale, icon set, layout grid, spacing, shadow, and border radius — the shared language across the product.
Impact & Outcomes
A shared foundation that scales
20+
Production-ready components built, documented, and shipped
6
Design foundations established — colours, typography, icons, layout, shadow, border radius
✓
In active use across all Seller Lab products — Catalog, Onboarding, Navigation, and more
↑
Add metric — e.g. adoption rate, design velocity improvement, or consistency score