First In-House UX Designer · 0→1 Commerce Foundations · Multi-Brand Scale
Role
First In-House UX Designer
Platform
Web + Mobile
Scope
Multi-Brand Commerce
Organisation
Honasa Consumer Limited
Multi-brand model
Mamaearth
Vitamin C
The Derma Co.
AHA · BHA
Aqualogica
Glow+ Dew
One backbone · three token sets · eight weeks
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
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.
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.
All three brands shared identical commerce logic. They diverged only in visual language.
Two designers, four engineers, three brands, eight weeks. The math only worked one way.
Considered
Give each brand its own build, its own components, and full freedom over layout and behaviour.
Why not: Three times the design and engineering effort, and every future improvement replicated three times. Impossible inside the seasonal window, and a maintenance trap after it.
Chosen
Shared commerce logic and components, with brand identity applied as a token layer above them.
Why it won: Brand teams gave up bespoke layouts in v1, which caused real friction. But it was the only architecture two designers could ship in eight weeks, and improvements now compound across all three brands.
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.
With no precedent and no slack in the schedule, these were the calls that decided what got built and what got cut.
The three brands differed in visual language and nothing else. Everything stable went into the shared backbone; everything that varied became a token.
In practice Commerce logic shipped once. Brand identity became a configuration.
Every requested feature was mapped against its revenue contribution. If it did not move a purchase forward, it moved to v2.
In practice V1 was PDP, cart, checkout, and order confirmation. Wishlists and loyalty waited a quarter.
Ingredient transparency drove purchases, so it could not live as a hardcoded special case that only one brand got right.
In practice Trust badges, ingredient highlights, and certifications shipped as shared PDP components.
Cutting scope without a written rationale reads as neglect. Cutting it with one reads as a roadmap.
In practice The deferred list became the v2 roadmap, funded off the back of v1 results.
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.
PDP, cart, checkout, and post-purchase flows, stable, shared, and independent of any brand identity. Same logic powers all three storefronts.
Commerce primitives, product card, line item, quantity control, CTA, composable into any flow. One set of components, theming handled by the layer above.
Color, typography, radius, and elevation tokens. Applying a new brand skin means updating a single configuration, no component-level redesign.
Each brand gets its own storefront surface: campaign imagery, hero art direction, promotional layouts, brand-specific only where it genuinely matters.
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.
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.
PDP focus
Purchase proof moved above checkout
68%
pre-checkout
Browse
PDP
Cart
Pay
Ingredient proof
Persistent drawer
Trust badges
Reusable system block
Sticky CTA
Always within reach
01 / Product Detail Page
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
Shared cart component
One structure, many skins
Mamaearth
Derma Co.
Aqualogica
02 / Cart
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
Checkout compression
The form became one focused page.
Before · six steps
More screens, more waiting, more abandonment before completion.
After · three decisions
Delivery
Address autocomplete
Payment
UPI · Cards · COD
Confirm
Review + place
03 / Checkout Flow
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
A single product card component, configured through three brand token sets. No structural change, just a token swap.
Mamaearth
The Derma Co.
Aqualogica

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.
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.
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.
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.
What it changed in how I work
Scalable systems are built by separating what varies from what doesn't, and making that separation explicit on day one. Every hard call in this project, the shared backbone, the token layer, the deferred features, was that one principle applied under pressure.
What I'd do differently
Set up Storybook and the final token architecture before launch instead of after it. The post-launch refactor cost a cycle that a week of upfront infrastructure work would have avoided.
What still needs proving
How long the no-bespoke-layouts rule survives. The friction with brand teams was manageable during the deadline, but the system has not yet weathered a brand team with time, budget, and a strong opinion.