Before opening Figma, I need to understand the domain well enough to recognize what I don’t know.

I read the brief, explore terminology and the surrounding market using AI, search, and videos, then return to the brief with sharper questions for the team.

When I worked on a Trends discovery tool, my early questions were basic on purpose: What does it mean to explore trends? Who does this work, and what are they trying to learn? What is the terminology they use? Getting comfortable with the language helped me prepare for more meaningful conversations.

I use AI to explore existing products, identify competitors, and find publicly available user feedback. This helps me understand common pain points, user expectations, and established UX patterns.

I ask AI to organize the findings and provide links to original reviews, screenshots, and product examples so I can verify the information myself.

The goal isn't to copy competitors or treat AI-generated summaries as research findings. It's to build context, understand existing patterns, spot opportunities, and identify questions worth exploring further.

I recently designed Leave-management functionality for a payroll platform. Because employees across many types of companies use these tools, I expected to find useful public feedback about existing experiences. I used several AI tools to investigate reported problems and desired functionality, and to highlight recurring problems and feature requests.

The resulting synthesis explored the leave request, approval, and review journey, including potential issues with understanding leave balances, seeing how a request affects remaining days, choosing dates, tracking approval status, and correcting a submitted request.

Desk research is a starting point. When I have access to real users, I prefer to speak with them. I prepare interview questions based on the brief and early research, then ask AI to suggest blind spots or additional questions.

On the Trends Discovery Tool, I wanted to understand what prospective users were really trying to accomplish, rather than assuming the original brief described the right solution. The interviews helped me evaluate the direction before committing to a detailed interface.

I map the initial user flow, usually in Figma. This is a stage where I do much of the thinking myself: connecting user goals, business rules, edge cases, and the sequence of actions. AI can suggest alternative routes or point out missing states, but I decide which flow makes sense for the product.

When the stakes or uncertainty warrant it, I take the early direction back to users or the team before investing in more detailed design. Not every small change needs the same amount of validation.

Before building a polished prototype, I use AI as a brainstorming partner. I might ask Figma Agent or Claude for different interaction concepts or ways to structure the experience. Some suggestions are useful; others fall apart as soon as I test them against permissions, data states, or product logic.

The value is in expanding the set of options, not letting the tool choose the direction.

There are two different starting points.

1. For an existing product, I work within the established design system.
2. For a new product, I build the foundations: colors, typography, design tokens, and reusable components.

Figma Agent significantly speeds up this process. I provide visual references, design direction, and an initial structure, and let it handle much of the repetitive work.
But speed doesn't automatically mean quality. I review the results, refine components, check consistency, and ensure the system is well-structured, tokens are code-friendly, and the system is scalable as the product grows. If needed, I do manual fixes.

I find it useful to treat AI as a junior design partner: it can do a lot of the groundwork, but I still provide direction, review the details, and take responsibility for the quality of the system.

My starting point depends on the project’s maturity, complexity, and deadline.

Code-first: For a small feature in an established product, or when I want to explore a working interaction quickly, I may start directly in Claude Code. I set up the project in VS Code, provide the design system and references, and turn research findings and requirements into project rules. Other AI tools can help me clarify prompts.

Figma-first: For more complex work, I prefer to establish the core screens in Figma, use Figma Agent to extend the flow with existing components, and then move into Claude Code for a live prototype. This gives me more control over visual decisions and more space to think through states and edge cases before implementation.

In practice, I move back and forth. A working prototype can expose a missing state; a Figma revision can clarify a behavior that was difficult to describe in prompts. AI-generated output also needs review: it may introduce unwanted motion, inconsistent components, or interactions that don’t match the intended flow.

I create live prototypes, usually as a draft option. I use Claude Code through VS Code, and share them with users or team members, often deployed through Vercel. A clickable or working experience helps reveal problems that static screens hide. I observe where people hesitate, where states are missing, and where the interaction doesn’t match expectations.

I may also show alternative static designs in Figma or quickly create a variation for discussion. The prototype is a tool for learning, not proof that the implementation is production-ready.

Once I have a working design, I use AI as an extra pair of eyes to review it.

I ask it to identify missing steps, overlooked edge cases, gaps in user flows, and situations that might cause confusion or frustration. It's especially useful for challenging the happy path and exploring what happens when things don't go as expected.

I also ask AI to review my designs against WCAG accessibility guidelines, looking for potential issues with contrast, navigation, interaction states, and other accessibility requirements.

Of course, AI doesn't catch everything. I review its suggestions, decide which issues are relevant, and verify accessibility concerns rather than treating an AI review as a complete audit.

For me, it's another way to challenge my own assumptions and improve the quality of the experience before testing it with real users.

When all design iterations are done and I have the final version, at handoff, I make sure the team can understand the intended behavior, not just the appearance of a screen. Figma Agent helps speed up specifications, and I can add supporting instructions or references to the GitHub repository.

I still review the documentation for missing states, ambiguous interactions, and inconsistencies between the design, prototype, and implementation notes.

After launch, I review the implemented feature to make sure it works and behaves as intended. I also collect user feedback, identify opportunities for improvement, and iterate on the experience based on what we learn from real usage.

I can ask AI to research, summarize, brainstorm, generate components, prototype interactions, and draft specifications. But I still own the important judgments: whether the evidence is trustworthy, which problem matters, what the product should do, which trade-offs are acceptable, and whether the result works for real people.

My process isn't fixed. Some projects need more research, others need more prototyping, and sometimes the best decision is to step away from AI and talk to a person.

What has changed is how quickly I can move between understanding a problem, exploring possibilities, and testing ideas.

For me, that's the real value of AI in product design. Not replacing the design process, but creating more room for the parts that require experience, judgment, and collaboration.
And I'm sure this workflow will look different a year from now.