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

There was a meeting in early 2023 that I still think about.

We were scoping the first AI surface for Fynd Commerce — a merchant copilot that would convert natural language into complex operational workflows. The idea was right. The timing felt right. But when I looked at how our team was structured, I knew we weren't ready to ship it.

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 — up to me, sideways to a PM, 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.

That meeting ended without a decision on the AI layer. I walked out knowing the first thing I had to fix wasn't a product problem.

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 kept two things for myself: macro-level UX architecture authority, and sign-off on any structural decision that crossed module boundaries. Everything else was theirs.

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

Before the restructure, designers came to standups with status updates. After, they came with positions. One designer — who owned the OMS module — started flagging inconsistencies between the order flow logic and what the PMs were speccing three sprints ahead. She wasn't asked to do that. She did it because it was her domain, and she felt the weight of that.

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 spent the better part of a year getting the OMS and logistics workflows right. The outcomes were meaningful: 30% reduction in delivery timelines, 27% cost reduction, 50% drop in return-to-origin rates. But the number I care about more than any of those is this: the Order Flow Builder — a node-based deterministic logic system we designed for the OMS — proved so architecturally sound that it was spun out entirely into Boltic.io, an enterprise automation platform now executing 477 million workflows with 105% YoY growth.

That spinout wasn't planned. It happened because the architecture was right. Right enough that it had a life outside the system it was built for.

That's when I knew we were ready for the AI layer.

One principle, applied everywhere.

The AI strategy started with a single constraint I imposed on every surface we designed: AI proposes. Humans approve. Systems execute.

We called it the Supervised Autonomy loop: Observe → Propose → Preview → Approve → Execute → Audit + Rollback. Every AI interaction on the platform runs through this sequence. No exceptions.

The internal debate was real. Engineers wanted to ship full automation on low-stakes tasks. Some PMs felt the approval step added friction. 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 it proved.

Sidekick — the merchant copilot — converts natural language into complex operational workflows with role-based permissions and 1-click rollbacks. It runs on the supervised autonomy loop. The AI Theme Editor reduced design-to-live time by 40%; the Zero-to-Code Component Builder generates production-ready GraphQL, HTML, and CSS from natural language.

None of this would have shipped cleanly with the original team structure. The AI surfaces touch every module. If designers didn't own their domains deeply, the cross-module dependencies would have been invisible until they broke in production.

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.

The platform is more capable now because the team was restructured first. That's the sequence. And it's not reversible.