One System. Three Brands. Eight Weeks.
Built and scaled first-party commerce experiences across Mamaearth, The Derma Co., and Aqualogica by establishing a shared component backbone with brand-level token overrides — shipping all three storefronts on a hard 8-week deadline.
Organisation
Honasa ConsumerMamaearth parent co.
Role
First UX Designer0→1 commerce foundations
Timeline
8 WeeksHard seasonal deadline
Platform
Web + MobileAll three brands
Scope
Multi-Brand D2CPDP · Cart · Checkout
The Situation
Three brands, no owned channel, and a tight window.
Honasa Consumer operated Mamaearth, The Derma Co., and Aqualogica almost entirely through third-party marketplaces. Every sale funnelled through Amazon or Nykaa — taking their commission and their customer data with it.
I joined as the first in-house UX designer with a mandate to build owned D2C storefronts before the next seasonal sale window. No design system, no shared components, no prior UX process — and eight weeks on the clock.
- Revenue generated almost entirely through third-party marketplaces; margin pressure was compounding
- No customer data ownership — the brands couldn't identify repeat buyers on their own platform
- Three brands with distinct visual identities but identical commerce logic and a shared backend
- No existing design process, component library, or handoff workflow across the portfolio
The Problem
Build three storefronts with one team.
The real design problem wasn't the UI — it was the math. Two designers, four engineers, three brands, and an 8-week window. Building each storefront independently was impossible. The only viable path was a system that made brand identity a configuration layer above shared commerce logic.
C1
No Precedent
Zero existing process, design system, or component library to build on.
C2
Three Brand Voices
Distinct visual identities and customer expectations — all non-negotiable.
C3
8-Week Hard Launch
A seasonal sale window set the deadline. There was no flexibility.
C4
Tiny Team
2 designers supporting 4 engineers across three parallel brand builds.
C5
Speed vs. Quality
Every decision forced a tradeoff between craft and the clock.
C6
Marketplace Risk
Delayed launch meant another quarter of full marketplace dependency.
Key Insight
All three brands shared identical commerce logic — they diverged only in visual language. That meant a single shared backbone with a brand token layer was the only architecture that could ship three storefronts in eight weeks.
What I Led
From blank slate to shipped system.
01
Research Sprint
5-day compressed discovery: marketplace analytics, competitor audits, customer interviews, brand constraint sessions.
02
System Architecture
Defined shared component boundaries, brand token schema, and the MVP scope that would actually ship in the time available.
03
Parallel Design
Designed all core flows — PDP, cart, checkout, post-purchase — across three brands simultaneously using the shared system.
04
Handoff & Launch
Delivered annotated specs, responsive guidelines, and edge case docs per component. Staged release across all three brands.
System Architecture
A shared backbone, a configurable surface.
Commerce logic is stable and shared. Brand identity is a token layer above it. Decoupling these two is what made three brands buildable by two designers in eight weeks.
L1
Core Commerce Logic
PDP, cart, checkout, and post-purchase flows — stable, shared, and independent of any brand identity. Same logic powers all three storefronts.
L2
Shared Component Library
Commerce primitives — product card, line item, quantity control, CTA — composable into any flow. One set of components, theming handled by the layer above.
L3
Brand Token Layer
Color, typography, radius, and elevation tokens. Applying a new brand skin means updating a single configuration — no component-level redesign.
L4
Brand Storefront
Each brand gets its own storefront surface: campaign imagery, hero art direction, promotional layouts — brand-specific only where it genuinely matters.
Key Decisions
Shared Commerce Backbone with Brand Token Overrides
Problem
Building separate commerce experiences per brand would mean 3× the design and engineering effort. Any future improvement would need to be replicated three times, creating compounding maintenance cost.
Decision
Designed a single component library where all commerce logic — PDP, cart, checkout, post-purchase — lives in shared components. Brand identity is applied through a token layer covering colors, typography, and imagery only.
Tradeoff
Reduced flexibility in early stages. Brand teams couldn't request bespoke layouts. This created friction initially but was essential for long-term maintainability and the only way the 8-week deadline was achievable.
Impact
All three storefronts shipped in 8 weeks with one designer and two engineers per brand sprint. Changes to core flows now propagate to all brands simultaneously.
MVP Scoping: Revenue-Critical Flows Only
Problem
Stakeholders wanted wishlists, product recommendations, loyalty programs, and bundle offers in v1. Delivering all of this would push the launch past the sale window.
Decision
Mapped every requested feature against its estimated revenue contribution. Kept only PDP, cart, checkout, and order confirmation. Documented the rationale for every deferral explicitly.
Tradeoff
Delayed personalization and discovery features by one quarter, which frustrated some stakeholders initially. But core flows shipped on time with high quality and no post-launch critical bugs.
Impact
On-time launch across all three brands. The deferred feature list became the v2 roadmap, funded directly off the back of v1 results.
Trust Signals as System-Level Components
Problem
Research showed ingredient transparency was a primary purchase driver for Mamaearth customers. Other brands hadn't thought about this systematically, risking inconsistent trust signals across the portfolio.
Decision
Built ingredient highlights, trust badges, and certification displays as reusable PDP components available to all brands — not hardcoded per brand as one-offs.
Tradeoff
Required more upfront component design time and engineering spec work. But avoided brand-specific components that would be impossible to audit or improve across the portfolio.
Impact
All three brands adopted trust components in v1. Mamaearth saw measurable improvement in PDP-to-cart conversion. Other brands adopted the pattern in subsequent releases independently.
Core Flows
Where the design decisions showed up.
01 / Product Detail Page
The purchase decision happens here.
Research showed 68% of drop-offs happened at the PDP — not checkout as originally assumed. Design energy went into ingredient transparency, trust signals, and a sticky CTA that reduced scroll-to-purchase friction.
Key Focus
Ingredient panel · Trust badges · Sticky CTA
Insight
68% of drop-off happened before checkout
02 / Cart
A single cart component, themed three ways.
The cart unified product thumbnails, quantity controls, and cross-sell slots into a cohesive component that could be themed per brand without structural changes. One build, three appearances.
Structure
Thumbnail · Quantity · Cross-sell · Summary
Theming
Brand token swap — no structural duplication
03 / Checkout Flow
From six steps to three.
Single-page checkout reduced form steps from 6 to 3 across all brands, with address autocomplete and persistent order summary reducing cognitive load at the highest-drop-off stage.
Reduction
6 form steps → 3 across all brands
Key UX
Address autocomplete · Persistent summary
Tokens in Action
Same system. Three distinct brands.
A single product card component, configured through three brand token sets. No structural change — just a token swap.
Mamaearth
The Derma Co.
Aqualogica
The Shift
From marketplace dependency to owned channel.
Before
Revenue without ownership.All sales through Amazon and Nykaa — their commissions, their customer data, their discovery algorithms. The brands were growing but building on rented ground.
After
Owned channel, owned data.All three brands on first-party storefronts. Purchase data, customer identity, and repeat-buyer relationships owned by Honasa — with a shared system that makes every future improvement compound across brands.
What Changed
A system that kept paying back.
The 8-week launch was just the start. The shared architecture made every subsequent brand addition and improvement faster than the one before.
New brand onboarding time
Time to launch a new brand on the system.
Initial (v1)
8 weeks
Next brand
3 weeks
M.01
8 weeks
All three brand storefronts shipped within the seasonal sale deadline — with no post-launch critical bugs.
M.02
3 weeks
Aqualogica Glow onboarded onto the system — down from 8 weeks for the initial three brands.
M.03
Zero ramp-up
Two designers onboarded in Q2 with no from-scratch ramp — the system documentation became onboarding material.
How We Got There
Eight weeks, end to end.
Week 1–2
Discovery
Stakeholder interviews, competitor audits, analytics review, and constraint mapping across all three brands.
Week 3–4
System Architecture
Defined shared component boundaries, brand token structure, and MVP feature scope through a prioritization matrix.
Week 5–6
Design & Prototype
Designed all core flows across three brands simultaneously using the shared system. Internal reviews with brand teams and engineering.
Week 7
Engineering Handoff
Component-by-component spec delivery with edge case documentation, responsive specs, and interaction notes.
Week 8
Launch
Staged release across Mamaearth, The Derma Co., and Aqualogica storefronts. Real-time monitoring and rapid iteration.
Post-Launch
System Iteration
Token architecture refactor, Storybook setup, and v2 roadmap scoped from live user behavior data and brand team feedback.
Key Reflection
Scalable systems aren't built by adding features — they're built by ruthlessly separating what varies from what doesn't, and making that separation explicit at the very start.
Keep reading