Fynd Commerce
Agentic AI
Enterprise SaaS
B2X Commerce
Led end-to-end UX for Fynd’s AI-native commerce platform—from merchant copilot and AI-generated storefront sections to order workflows, payments and refunds.
Year
2023 - 2026
Services
End-to-End Product Design, AI UX Strategy, Platform Architecture, Research, Design Ops
At a glance
The Platform: Fynd Commerce is an AI-native unified commerce platform built to serve 300M+ customers. At scale it processes 360M+ orders a year, peaks at 1.5M orders per day, and serves 20K+ stores across 2,600+ brands, with ₹34,003 Cr in gross transaction value (FY 2025-26).
My role: Design DRI for Fynd Commerce Platform, leading design across OMS, logistics, payments, catalog, storefronts and extensions. Now Product Architect with a Product Design Manager remit, I combine hands-on UX architecture and prototyping with team leadership.
Team: I lead 5 product designers across distinct platform modules. I personally owned the UX and prototypes for Sidekick, the AI Theme Editor, Order Flow Builder and high-stakes OMS, Refunds and Multi-MOP flows. I directed and reviewed Catalog, Storefronts and Logistics, with individual designers holding module ownership. Engineering owned production implementation, AI models and backend execution.
Case Study Scope: Rather than breaking down every platform module, this case study focuses on my charter to architect Fynd's AI-native transformation layer. It also highlights my foundational work as Design DRI for OMS and Payments, showcasing the core platform differentiators, such as the deterministic Order Flow Builder, that let Fynd resolve complex orders and logistics at enterprise scale.
Problem (why AI, now)
Two recurring design challenges shaped the work:
High-frequency tasks are manual (search, configuration, exception handling).
High-stakes actions need clear review and approval before changes are committed.
I visited Diesel, GAS, Superdry and Celio stores and spoke with staff using our OMS. Their pain points and feedback informed the FCP 2.0 / Novus work. Understanding how operators handled real orders gave me a practical starting point for the platform's workflows and AI interfaces.
I framed the AI transformation as a product system problem: How can we reduce setup and operational effort while making proposed changes understandable and reviewable before they affect the business?
Strategy: “Supervised Autonomy” (agentic, but accountable)
I set a North Star design vision for a cross-device commerce platform serving a broader range of enterprises and aligned it with our CEO. The vision was approved, but FCP 2.0 was later put on hold as the business prioritised large enterprises. The specific AI features described here are distinct from that full revamp.
The guiding interaction principle was simple: AI should propose. Humans should approve. Systems should execute.
Propose a change.
Preview it before commitment.
Reject the proposal, or approve it to commit the change.
Execute the approved action.
The implemented flow did not provide a general post-approval undo. Broader permissions, detailed diffs and rollback controls remained design directions.
Intervention 1: Sidekick (Merchant Copilot)
I led the UX architecture for Sidekick, turning the static admin dashboard into an “actionable workspace.”
Action-oriented UX: Sidekick is the merchant-facing experience powered by a separate copilot. I designed how merchants request, preview and approve actions for tasks such as product creation, campaigns and collections; engineering implemented the execution behind those interactions.
Context for review: I focused the UX on making a proposed action legible before commitment, so merchants could understand what they were being asked to approve.
Designing the review moment: The important decision was to make preview and approval part of the action itself. Merchants could reject a proposal before it changed the platform. This gave the interaction a clear point of commitment.
Intervention 2: AI Theme Editor (Prompt → Custom Section)
Our ecosystem is undergoing a major architectural shift from Vue to React. I focused the AI Theme Editor on turning raw prompt outputs into merchant-safe, shippable React UI.
The original vision was prompt-to-storefront. One prompt, one finished multi-page store. We built it and it worked as a generator: the output was structurally sound. What it could not do reliably was hold a brand. Generated pages needed enough correction that merchants were spending the time we had saved them on bringing the result back in line with their brand system.
So I changed where the AI was allowed to act rather than trying to make it act better. Full-page generation did not ship. Instead the capability was folded into the existing theme editor as prompt-based custom section generation, and that is what went live.
Zero-to-Code Custom Sections: merchants describe a component in natural language and the AI generates the Data Source (GraphQL/REST), HTML template and Custom CSS behind the scenes, while the merchant keeps no-code control over layout and behaviour. An inline Enhance Prompt feature strengthens thin inputs before generation.
Why sections and not pages: a section is small enough that a merchant can look at it and know whether it is right before it ships. A generated storefront is not. Scoping the unit of generation down was what made generative UI safe to put in front of enterprise brands.
Design constraints: I used brand tokens, responsive rules and content bindings as requirements for the generated sections. The output still needed review and refinement before use; section generation did not remove that responsibility.
Across the theme editor, design-to-live time came down by roughly 40%, measured through internal before-and-after testing.
The principle I took from it: with generative UI, scope the blast radius before you improve the model.
The Deterministic Foundation: Order Flow Builder
While the future of FCP leans heavily into agentic AI, enterprise commerce still demands strict deterministic logic for fulfilment. I conceptualised and designed the zero-to-one MVP for a node-based Order Flow Builder within the OMS, letting sellers construct custom operational journeys.
The fork: we already had a rule engine. I pushed for a node-based canvas because operators needed to see the order states and transitions together, discuss a journey with their team and submit it for admin review. The existing implementation did not provide that review flow. The canvas made those relationships visible, while maker-checker separated configuring a journey from approving it to go live.
Visualising the state tree: I architected a drag-and-drop canvas where operations teams map exact fulfilment states (Placed, Manual Invoice, Pack) and assign strict admin approval loops to sensitive transitions.
Power-user tooling: to remove the engineering bottleneck, I designed contextual side panels exposing Form Builders, JSON payloads and dynamic pre/post-hooks. Sellers get code-level control over their logic wrapped in a usable interface.
The review console I rebuilt. My first version organised the admin approval queue by object type, with primary tabs for Request order, Flow and Sub-flow and status filters beneath. It looked organised and it was structurally wrong: an admin's job is "what needs my review now," and I had buried that under two levels of navigation and split it across three tabs. A review with the group PM and engineering lead surfaced it, along with a second problem. My model let sellers create conditions and state trees independently, which sounds flexible and actually meant you could build a journey that couldn't run. Engineering raised it as a build cost. What they had found was an incoherent model. The rebuild collapsed the console to two tabs, Review and Default flows, and enforced one condition to one state tree, compiled into a stepper. Pairing each condition with its state tree prevented that specific configuration mismatch.
Where the toggle lives. Active and inactive originally sat directly on the listing. Switching a flow off can stop orders being placed from the storefront and halt orders already in process, so I moved it behind an intentional action with a warning that states what will happen. The principle I've used since: the ease of an action should match its blast radius.
The Boltic Evolution: The Order Flow Builder became a foundation of Boltic's Workflow product. The connection was the node-based workflow design developed for the OMS. Boltic reported 477M+ cumulative platform workflow executions—a measure of the broader platform's scale.
Platform Core: OMS & Logistics
The AI interfaces depended on clear operational workflows underneath them. As Design DRI, I led the UX direction across the commerce platform, with hands-on ownership in OMS and Payments and design direction and review across the other modules.
The original OMS was built for fashion e-commerce: one hardcoded order journey serving every seller. It worked until the platform stopped having one kind of seller. Pharmacy, food delivery, malls with third-party sellers and small sellers running their own logistics all needed fulfilment logic the system had no concept of. Three of the features that closed that gap:
Omnichannel Order Ingestion: unified flows letting merchants inject offline, walk-in traffic directly into the digital OMS. This bridged a critical omnichannel gap, converting traditional retail footfall into trackable digital order volume.
Click & Collect Orchestration: the end-to-end UX for in-store pickup. I translated complex backend logic into simple front-line operational interfaces managing store readiness, pickup SLAs and real-time exception handling. Now live for Pizza Hut Malaysia, aDawliah and SGH Viva.
Multi-Piece Shipments: the visual logic for complex fulfilment edge cases, enabling split deliveries and partial fulfilment while keeping communication unified for the end customer. Including the state nobody designs for: when no delivery partner supports a split shipment, the seller gets three exits rather than an error message. Revert to a single package, assign a partner manually, or self-ship.
The Impact: Fynd reported 30% shorter delivery timelines, 27% lower delivery costs and 50% lower RTO rates for its OMS. These are platform outcomes across the work of several teams; my contribution was workflow design and design leadership, while engineering owned the algorithms and implementation.
Platform Core: Payments & Refunds
The other foundational layer that demanded heavy operational lifting before AI was money movement. Fynd Commerce supports 8+ payment gateways, multi-MOP transactions across online and offline rails, and a refund engine that reconciles across all of them. Inventory mistakes are recoverable. Payment mistakes erode merchant trust permanently.
I owned the Payments UX architecture end-to-end and personally designed the refund flows, where money actually moves and design judgment had to be tightest.
The hard problem: refunding a split-tender order
A customer pays INR 30,000 across three rails: credit card, store wallet and cash. They return half the order. The refund is now a three-way reconciliation problem with regulatory, technical and operational constraints stacked on top.
My first design let agents flexibly redistribute refund amounts across any combination of Store Credit, Bank Transfer or Settle Offline. It looked clean. It broke in three places.
Engineering: partial reallocation across MOPs created reconciliation states the backend couldn't deterministically resolve.
Finance: The product policy required online amounts to return to source unless the source was unavailable. Arbitrary Store Credit fallback did not fit that policy.
Operations: agents were making allocation decisions that should have been rule-driven upstream.
That engineering constraint turned out to be the most useful thing that happened to the feature. The question stopped being how to let the agent allocate and became why the agent was allocating at all. The system already knew exactly how the customer had paid: every mode, every amount, every transaction ID. It just wasn't asking.
The redesign: governance as configuration, not action
Split Refund Mode became an explicit toggle, defaulted off. One consolidated refund-to-source by default, per-MOP routing only when explicitly enabled.
Refund destinations governed by MOP type. Online payments couldn't be redirected to arbitrary offline modes. The routing followed the finance-approved product policy.
Settle Offline became a first-class flow with structured proof upload, transaction ID capture and acknowledgment, generating audit trails inline rather than retroactively.
The Impact: The shipped refund experience made the agent's job selection rather than manual allocation. Support reported fewer refund-related tickets after launch. The design lesson was to make the permitted refund routes clear in the interaction, instead of asking operators to reconstruct the policy for each order.
Tradeoffs and constraints (what made this real)
I made deliberate product calls to keep the AI trustworthy and shippable:
Trust over magic: I explicitly chose an approval-first UX over full background automation, to protect merchant trust and limit the blast radius of AI hallucinations.
Architecture as a constraint: treated the Vue-to-React migration as an enabling constraint, designing the AI tooling to operate strictly within the bounds of the new React theme ecosystem.
Scoping: focused the early AI interactions on specific merchant tasks with preview and approval before commitment. Higher-stakes financial actions need a separate review of controls and recovery.
Configurability has a cost I underestimated. The Order Flow Builder gave sellers real power, and in practice it meant our support team was building and maintaining custom journeys on their behalf. The right fix isn't less power, it's a better starting point: journey templates by vertical, so a pharmacy seller edits a working pharmacy journey rather than opening a blank canvas. I moved the burden rather than removing it.
What shipped vs what’s next
Shipped / In Active Rollout:
Prompt-Based Section Generation: an AI tool inside the theme editor translating natural language ("testimonial carousel") into section-level GraphQL, HTML and CSS for review and refinement, with an inline Enhance Prompt feature that strengthens thin inputs before generation. This is the shipped form of the prompt-to-storefront vision, scoped from pages down to sections.
Embedded Generative AI: auto-generation scaled across the ecosystem, from product catalogs to extensions, generating descriptions, interactive layouts and images.
AI Sidekick (Supervised Autonomy): the merchant-facing experience, powered by a separate copilot, for requesting and reviewing actions such as creating products and orchestrating campaigns before approval commits the change.
Execution Foundations: the proposal, preview and approval interactions that make the point of commitment explicit to the merchant.
Order Flow Builder: shipped inside the OMS and became a foundation of Boltic's Workflow product.
Further design directions:
Expand Sidekick's action surface across OMS, catalog and storefront ops.
Standardise agent permissions, preview diffs and rollbacks across all platform modules.
Evaluate bounded autonomous actions only where permissions, monitoring and recovery controls can be tested for the specific use case.
What I'd push for:
Journey templates by vertical. Configurability currently depends on our support team building journeys for sellers. Templates would move that burden back into the product: a pharmacy seller edits a working pharmacy journey rather than opening a blank canvas.
Instrumentation as a design deliverable. Adoption per feature, support-ticket volume by flow, and time-to-first-successful-custom-journey for a new seller. That last one is the metric that would tell me whether configurability worked or just relocated the work.
Learnings
I'd prioritise a visible action history in a future iteration of Sidekick, then evaluate whether operators can understand what was approved and what happened next.
Module ownership only works when the design system is tight enough to absorb independent decisions. Ours wasn't early on. I'd invest in system alignment in sprint 1 itself.
I'd test merchant understanding and confidence before launch: can operators explain what they are approving, identify an unwanted proposal and recognise when a change has been committed?
With generative UI, scope the blast radius before improving the model. Full prompt-to-storefront generation produced structurally sound output that didn't reliably hold a brand, and merchants spent the saved time correcting it. Shipping section-level generation instead of page-level was the decision that made the capability usable. Constraining where the AI could act mattered more than making it act better.
I wanted a closer measurement loop for the features I designed across a platform serving 2,600+ brands. Post-launch usage data sat with product and client teams rather than with design. I'd instrument adoption per feature, support-ticket volume by flow, and time-to-first-successful-custom-journey from day one. That last one is the metric that would have told me my configurability trade-off wasn't working.
