How I rebuilt a design team from the inside — and then shipped an AI layer on top of it

Updated 4 October 2026.

Around early 2023, while we were planning FCP 2.0 and its AI roadmap, I began an initiative to give designers clearer domain ownership. This was before my formal appointment as Product Design Manager in April 2024.

The AI planning made a team problem harder to ignore. The idea was right, but when I looked at how we worked across commerce domains, I knew we needed clearer ownership before adding another layer of complexity.

Not because we lacked skill. Because we lacked architecture.

The team was organized by seniority. Designers picked up tasks. Nobody owned a domain. When a decision needed to be made, it floated between designers and PMs, then back into Figma limbo. To ship an AI system that would touch inventory, fulfillment, pricing, and storefronts simultaneously, I needed designers who could think like platform owners. I had designers who were waiting to be told what to build next.

The first thing I wanted to change wasn't a product screen. It was how we shared responsibility for the product.

Ownership is not a title. It's a behavior you have to architect.

The restructure was simple to describe and hard to execute: five designers, five domains. Catalog. OMS. Payments. Logistics. Storefronts and Extensions. Each designer became the design DRI for their module — responsible for research, information architecture, execution, and stakeholder communication end-to-end.

I led the overall UX direction and alignment across module boundaries, while each designer owned their domain.

What changed wasn't the org chart. It was the daily behavior.

The expectation changed: designers should come to reviews with a position on their domain, raise inconsistencies early and discuss trade-offs with PMs. Ownership meant thinking beyond the next assigned screen.

That's what real ownership produces. Not better wireframes. Better judgment, applied earlier.

Vague requirements are a structural failure, not a PM failure.

The PRD problem was everywhere. PMs shipped requirements that were technically complete and contextually empty. Edge cases were undocumented. Corner states were assumed. Designers opened Figma before they understood the problem.

I didn't blame the PMs. I changed the process.

We built a structured alignment loop — a review gate at each phase where the PM, their manager, and the module designer co-authored requirements before any design work began. Edge cases had to be documented and signed off before a single frame was opened. The gate wasn't bureaucratic; it was a forcing function that made everyone accountable for the same definition of the problem.

The quality change was immediate. Not because designers got smarter, but because the context pipeline stopped leaking.

The operational foundation had to be right before AI could touch it.

You cannot layer intelligence on top of broken operations. This is obvious in retrospect. It wasn't obvious enough in the industry conversation around AI in 2022.

We worked on the OMS and logistics workflows. Fynd reports 30% shorter delivery timelines, 27% lower delivery costs and 50% lower return-to-origin rates for its OMS. My contribution was the workflow design.

The Order Flow Builder — a node-based workflow editor I designed for the OMS — became a foundation of Boltic's Workflow product. Boltic reported 477M+ cumulative platform workflow executions. What mattered to me was that a pattern designed for one operational use case could inform a broader product.

That work gave us a stronger foundation for designing the AI interfaces.

One principle, applied everywhere.

Our guiding design principle was simple: AI proposes. Humans approve. Systems execute.

We called the approach Supervised Autonomy. In the shipped flow, AI proposed a change for preview. The user could reject the proposal or approve it to commit the change; there was no post-approval undo.

My position was that trust in AI systems is earned through accumulated correct previews, not through hoping users don't notice errors. The preview-first pattern wasn't just UX — it was the trust-building mechanism.

What shipped, and what we learned.

The broader FCP 2.0 vision received CEO approval, but was later put on hold as large-enterprise priorities took precedence. The shipped AI features were more specific than that full revamp.

Sidekick is the merchant-facing experience powered by a separate copilot. I designed the interfaces and prototypes; engineering owned the production implementation and backend execution.

The AI Theme Editor shipped prompt-based custom section generation, with generated sections that users could refine. Internal before-and-after testing indicated approximately 40% less design-to-live time for the Theme Editor. The Zero-to-Code Component Builder generated GraphQL, HTML and CSS for sections; those outputs still needed review and validation.

The AI surfaces crossed module boundaries. Domain ownership gave us a clear person to work through each dependency with, bringing the right product context into design discussions.

The structure made the complexity visible in time to do something about it.

The actual leadership lesson.

I've thought a lot about what the most important design decision I made on Fynd Commerce was. It wasn't Sidekick's preview UI. It wasn't the supervised autonomy loop. It wasn't even the individual module features.

It was the team structure.

The work of a design leader isn't the AI layer. It's building the conditions where the AI layer becomes possible — where designers have the context, the ownership, and the architectural confidence to make the right calls before the problem is visible on a screen.

That's the sequence I'd repeat: give designers context and ownership, then use that foundation to take on more complex product work.