The whole loop.

I work in enterprise consulting, so my users are the domain experts I’m designing for, and experts are hard to research the usual way. When someone has done the same work for twenty or thirty years, the knowledge has gone invisible to them. It’s instinct, not something they can narrate on command. Ask them to walk you through it and they struggle, and a slide deck makes it worse, because there’s nothing concrete to react to. So I stopped asking them to describe their work and started showing it back to them, even a rough or a wrong version, because a person who can’t explain their own process on demand can instantly tell you what’s wrong with a version of it sitting in front of them. The prototype isn’t how I present an answer. It’s how I get the real question.

I start with research, but I don’t let it sit there as slides. I pull artifacts out of it, the rough pieces I can actually build on. Then I use those to put together a working prototype that shows the full vision. I hold off on locking the scope on purpose, because I’ve learned that the prototype is what exposes the real constraints, and scoping before you’ve seen them is just guessing. The point isn’t to be right on the first try. It’s to have something real in front of people early.

Because the moment a client or a stakeholder can click through the thing, the conversation changes. They stop giving me feedback about how it looks and start telling me the part that matters. The logic underneath. How their process actually runs. What depends on what, where the blockers are, which data sources are a mess, what’s fragmented and why. That’s the conversation I need, and a static screen never gets me to it.

That feedback is what lets me draw the real user flow and the real process map instead of the guessed one. Then I take it back into the prototype and make it true. And where it counts, I wire in real models, Gemini and others, so the people I’m showing it to aren’t imagining what an agentic feature would feel like. They’re using one.

Putting something real in front of people this early means I fail earlier too, and on purpose. I hit the walls while they’re still cheap to hit. I find out the actual scope, the actual logic behind each step, and the actual state of their data long before any of it turns into an expensive surprise.

When I hand a prototype to a developer, it isn’t a picture of a working thing. It works. I build it with mock APIs and mock data standing in for the real ones, so the whole flow behaves the way it will in production. I also build the project’s context right into the code, so the developer’s own AI agent understands what the project is and how it’s meant to work before they touch it. They don’t rebuild my work to understand it. They swap the mocks for their real APIs and keep going.

What that kills is the QA loop nobody enjoyed. The weeks that used to disappear into padding that was a few pixels off, a radius that didn’t match, a color that had drifted from the spec. All of it is already correct in the code, so it never becomes a ticket. That frees the developers to spend their time on the part that’s actually theirs and actually hard, making it secure, making it scale, wiring in the real data, holding it to the approved libraries. On the last project my developer put the saving at six to eight weeks. Handing over static Figma screens never got us there, because a static screen can’t carry intent, and no amount of dev-mode inspection or daily walkthroughs makes up for that. Working code does.

The hard parts of the interface work the same way. The complex interactions and the motion, the things that usually get watered down in translation, I design them and I code them, so nothing has to be reverse-engineered from what I meant.

A lot of my time used to go into the same setup work at the start of every project, and into catching the same mistakes at the end. So I built my own skills to take that off my plate, and then off my studio’s plate too.

Setup

Starting a new project used to mean building the whole working environment from scratch every time. The setup skill does it for me. It spins up the harness with the right skills already loaded, the registries, the design system, and the design guidelines written in, so I can start on the actual problem instead of the scaffolding.

Design review

When you build with an AI agent, it drifts. It’ll quietly hardcode a color or a spacing value, or rebuild a component that already exists instead of reusing the one in the system. The design-review skill checks the work against the design system and the existing components and flags exactly where it’s drifting, so the drift gets caught before it ships.

Vibe to prod

A prototype that looks finished isn’t the same as one a front-end developer can actually use. The vibe-to-prod skill audits the codebase against that bar, tells me what falls short and why, and once I approve the fixes, it makes them. What comes out the other side is code that’s genuinely ready to hand off.

I don’t marry one tool. I use whatever fits the job, and I’ll run more than one AI tool against the same codebase when it helps, so a limit or a weakness in one never leaves me stuck waiting. Staying in motion sounds like a small thing. Over a project it’s the difference between momentum and dead time.

I also move freely between Figma, Figma Make, and code. I’ll take a design out of Figma, into Figma Make, into working code, and back into Figma design when I need to, without treating any one of them as a dead end. The work isn’t trapped in whichever tool it started in.

I run AI workshops for the designers in our Gurgaon studio, and the goal isn’t to teach them a tool. It’s to get them past the fear first. A lot of designers still see AI as the thing that replaces them, and until that flips, no tutorial lands. So I start there, with AI as something that gives you leverage rather than something that takes your job.

Then I show them the thing that actually convinces people, which is my own workflow. Not theory, the real process I use every day, the one that works for me. For a lot of them that’s the moment agentic design stops being a buzzword and turns into something they can picture doing themselves.

And I made it repeatable instead of a one-off talk. The setup, design-review, and vibe-to-prod skills I built for myself are the same ones I hand the studio, so a designer who just got convinced in a workshop has a real place to start the next morning.