People ask me how I actually use AI tools in my design process. I split the work three ways. The first 10% is mine. The middle 70% is where AI does the heavy lifting while I steer. The last 20% is mine again.
The first 10% is yours
Do the first 10% yourself. That means getting all the requirements, all the context, and all the human elements the machine can't reach: feelings, reactions, politics, business constraints.
This first part is the most important, and I see a lot of people skipping it. It never goes well.
This is where you find the exact problem you're trying to solve, who you're solving it for, and why. If it's very early, write it down as a hypothesis.
The tools here are light. I start with paper and pen. Writing the problem out by hand makes me slow down and say it plainly. Then I'll put my notes into Grok Bot and ask it to poke holes in how I've written the problem, or tell me what I haven't said yet. That helps me write it down more clearly. The context itself still comes from people: the conversations, the reactions in the room, the constraints nobody wrote down. No model has access to that.
Then you go through rounds of learning and keep coming back to that question. If it's proved wrong, rewrite it. Going back to the beginning when something is incorrect is normal. Your confidence rating changes, and you move forward again from a stronger point of view. Product gets built in circles, and that's how it's supposed to work.
The middle 70% is where AI helps most
Once that's done, hand it to AI and have it go through 50 variations of UI. You can try 100 if you really want to. You get options that used to take too much energy to make.
For me, most of this happens in Claude Code and Codex. They generate the variations, and they build out the ones worth testing.
You, the human, still figure out the information architecture that makes sense, and you do the picking. I work mine out in Figma, then use it to judge which variations hold up. The tools will happily give you 50 versions of a screen. They won't tell you which order the information should come in for the person using it.
Pick the top 10 worth building out. Build them, and test all 10 with users. With design sandboxes you can now connect member IDs and test with real data, so your results are much richer. Say you end up with two winning variants. Keep going until you isolate one.
If testing shows the problem was framed wrong, go back to the first 10% and rewrite it. That's the same loop from the beginning, and it's normal.
The last 20% is craft
Before it goes out to 100% of your audience, the craft has to be perfect. That's the last mile.
Check every detail the machine might have missed. I go back into Figma and look at spacing, type, and states with fresh eyes, and I use Claude Code or Codex to fix what I find directly in the code. Audit it, test it, make it perfect, and then launch it.
This is the part people want to hand off, and it's the part I'd hand off last. The machine got you to something that works. Making it feel right is still your job.
Why I split it this way
This is how I recommend using AI tools across your product development lifecycle if you want high-quality results that nobody tags as AI slop.
Using AI for the sake of using AI doesn't interest me. I use it for what it's actually good at, and I don't force it into the parts of my work where I think it does a horrible job.
About the author
Ashwarya Subhluxmi has 12+ years of design experience in fintech, leading teams building AI products and marketplaces used by millions of people. She writes about design leadership, AI-native product design, and what changes for design orgs when agents join the team. ADPList Top 50 UX Coach, 2026. She advises early-stage founders and is based in the San Francisco Bay Area. uxbyash.com · LinkedIn