Atomic design pattern library
Figma
InVision DSM
Sketch
Built a token-driven design system for Mumzworld that replaced 184 unique colors with a documented palette, mapped recurring patterns into a shared library, and gave product and engineering one vocabulary across web and app — cutting the time from concept to implementation by more than half.
Industry
E-commerce · Mother & Baby · GCC
Stack
Atomic design pattern library · Figma · InVision DSM · Sketch
Mumzworld is the indispensable online extension of a mum's life. The system goal was to make her feel comfortable, empowered, and safe at every touchpoint — without engineering rebuilding the same components in slightly different ways each time. The design system below became the foundation; the three applied sections that follow show what got built on top of it.
The Problem
An audit of the live site surfaced 184 unique colors and 299 total background colors across the interface. The visual brand felt scattered, perceived quality suffered, and engineers had no single reference for what "primary" actually meant. Each new feature added another variant; nothing was retired.
The deeper issue was structural. There was no shared vocabulary between design and engineering. Product owners thought in features, designers in screens, engineers in components — and the gaps between those mental models showed up as duplication, drift, and rework. Customer-facing surfaces (post-purchase comms, order tracking, multi-role features like gift registry) all suffered the same root cause: every team was reinventing the wheel.
How I Framed It
The system needed to do three jobs in one: standardize the brand expression, document the recurring patterns, and give engineering a checklist for how each element should behave.
Step 1 — Design principles. We asked how we wanted users to feel: comfortable, secure, in control. The aesthetic decisions (color, typography, spacing, tone) flowed from that emotional target — not from a designer's preference.
Step 2 — Pattern map. We laid printed flows side by side on a board and tagged the components that recurred. The ones used most by customers got the deepest documentation; the rare ones got noted and deprioritized.
Step 3 — Naming and scope. Each component shipped with a scope checklist — anatomy, states, edge cases, behavior — co-authored with product owners and engineering, not handed over.
Key Decisions
Audit the chaos before designing the system
Context: The temptation was to skip straight to the new tokens. Without measuring what was already there, we'd just be adding a 185th color.
Choice: Two-week audit pass first — every screen across web and app, every unique color and pattern catalogued. The 184 → 299 number wasn't a vanity statistic; it was the argument that won engineering buy-in.
Trade-off: Two weeks of "no visible output" before any system work started. Worth it for the leverage in every subsequent decision.
One system across web and app, not two
Context: Web and mobile were on separate roadmaps with separate component libraries. The easy path was to leave them parallel.
Choice: One source-of-truth foundation, with platform-specific consumers. Type ramp, color, spacing, and motion principles were unified; surface-level implementation diverged only where the platform demanded it.
Trade-off: Slower initial rollout — coordinating both teams added meetings. Paid back the first time a brand refresh propagated to both surfaces in days instead of months.
Document patterns collaboratively, not as a handoff
Context: Design systems often get written by designers in isolation, then "shipped" to engineering — who then ignore them.
Choice: Each pattern's scope document was co-authored in a working session with product owners and engineers. By the time it was published, all three roles had already agreed on the contract.
Trade-off: Heavier meeting load early in each component's lifecycle. The components that came out of that process were the ones that actually stuck.
Built a token-driven design system for Mumzworld that replaced 184 unique colors with a documented palette, mapped recurring patterns into a shared library, and gave product and engineering one vocabulary across web and app — cutting the time from concept to implementation by more than half.
Applied — Order Tracking (68% Call-Centre Reduction)
Customer care was drowning. Customers couldn't see where their orders were, called in droves, lost faith, and asked for refunds. The fix wasn't a bigger support team; it was a tracking page customers could actually trust.
Two structural moves, both leaning on the output pattern library:
Manage expectations before purchase, not after
Context: Most order-tracking redesigns only touch post-purchase. The real frustration starts when a customer's PDP-stage expectation doesn't match the actual delivery experience.
Choice: Improved the delivery-promise highlight on the PDP. Made the checkout screen show expected shipments with estimated delivery dates per item, broken down by shipment type (Yalla / Standard / Extended).
Trade-off: Touched surfaces outside the original brief. Negotiating PDP changes across two more squads added two weeks. The pre-purchase signal turned out to be the highest-leverage change in the whole project.
Break orders down by shipment, not by line item
Context: Customers think in shipments ("when does my box arrive"), but the order management system thinks in line items. The old page reflected the OMS view.
Choice: Order list and details rebuilt around shipments. Highlighted exceptions (pending phone confirmation, missing address, payment failure) using the page-notice and inline-notice patterns from the output pattern library.
Trade-off: Required a non-trivial schema change on the OMS side to surface shipment groupings cleanly. Worth it — the customer's mental model now matches the UI.
Call-centre volume dropped by 68% within two weeks of launch. Customers were getting their answers from the tracking page itself instead of calling.
Applied — Gift Registry (Three Roles, Three Scenarios)
Planning an occasion — a wedding, a baby shower, a birthday — is hectic. A registry should take the burden off, not add to it. We weren't designing for one user: three roles all needed the same feature to work — a non-owner who wants to create a registry; an owner who wants to manage hers; and a non-owner who wants to find a friend's registry and buy something off it.
Three scenarios, three entry surfaces:
Scenario 1 — Wishlist an item to get back to it later → trigger a dialog and start a new registry from a moment of interest.
Scenario 2 — Planning a baby shower mid-browse → "Add to registry" secondary button on the PDP, no need to break flow.
Scenario 3 — Found a banner or link to the registry hub → main registry page as the canonical entry point.
Build for three roles, not one
Context: It's tempting to design the registry as a single-user feature and bolt on the buyer experience later. That always produces a buyer flow that feels like an afterthought.
Choice: Each role got a documented persona, a user-story sheet, and a flow — designed in parallel, not sequentially. Owner onboarding, buyer discovery + purchase, and the browser's "find my friend's list" path all built together.
Trade-off: Longer up-front design phase. Compensated by avoiding the typical "the buyer's flow is broken because we didn't think about it" rework cycle.
The instinct that emerged — design for the secondary user (the buyer) at the same priority as the primary user (the owner) — became a default for every multi-role feature I've designed since.
Result
Design and engineering ship faster because they're not re-litigating the same decisions on every project. New product surfaces inherit the system rather than reinventing it. The brand expression is consistent across web and app — and the perceived-quality gap the audit surfaced is closed.
184 → 1 core palette — Unique colors
6 — Named output patterns shipped
68% in 2 weeks — Call-centre volume reduction (Order Tracking)
3 roles, 3 scenarios — Multi-role template (Gift Registry)
Most importantly, the system became the canonical reference. When a new designer joined the team, the system answered their first hundred questions before they had to ask.
More Projects
