How I Build
with AI

Every project starts the same way: I get as close to the real work as possible. I sit with stakeholders, shadow their workflows, and ask questions until I understand not just what they do but why they do it that way and where it breaks down. I'm looking for where people lose time, miss context, or make decisions with incomplete information.

I survey the competitive landscape to understand what tools exist, how they approach the problem, what they get right, and where they fall short. AI accelerates the initial scan, but I go hands-on for anything that matters — requesting demos, reading research documentation, and talking to people who use competing products. When AI is embedded in the product itself, this step also means understanding how other teams have approached trust, explainability, and error handling.

I consolidate everything — stakeholder needs, research findings, and my own synthesis — into a product proposal document. This is a detailed requirements artifact covering what the product does, who it's for, what problems it solves, and what it explicitly does not do.

I share this with stakeholders for alignment before writing a single line of interaction design. Sign-off here prevents expensive rework later.

I map the user journey through the proposed product, covering both current state and ideal state, to pressure-test the requirements against real workflow logic. This stays human-led. Workflow logic is too domain-specific and context-dependent for AI to navigate reliably.

This is where the workflow becomes genuinely different from traditional design practice. I feed the product proposal document into an AI prototyping tool and generate a clickable, visually structured prototype. What would have taken two to three weeks in Figma takes hours. But the output isn't done.

This is where my background as a trained designer and healthcare domain specialist becomes the product:

Information hierarchy — AI doesn't know what a user considers primary versus supporting detail. I restructure visual weight and progressive disclosure based on how the actual user thinks about their work — what needs to catch the eye immediately versus what lives in a secondary panel.

Accessibility — AI-generated UIs consistently underperform here. Color contrast, type sizing, and information density all require active correction. The right defaults depend on the context of use — device type, lighting conditions, user stress levels — not on what an AI produces by default.

Complex interactions — Some interactions require disproportionate prompting effort. Knowing when to stop prompting and instead document the interaction spec for engineering is itself a skill.

I run two distinct review cycles with different goals and different versions of the prototype.

Engineering review — Focused on feasibility, edge cases, and handoff clarity. I adjust scope here if I get pushback on complexity.

Stakeholder review — Focused on whether the product solves the right problem and whether the workflow feels right. I show enough to communicate primary user actions clearly.

From aligned prototype to engineering handoff, I produce the full PRD, break requirements into features, prioritize MVP versus future versions, and generate Jira tickets via a Claude integration. I manage engineers through execution, updating prototypes when scope changes and maintaining a living product roadmap.

After launch I run a structured audit covering what shipped, what worked, what didn't, and where the AI model can be improved based on human override patterns. Override rate is one of my most important signals — it tells you where the AI is miscalibrated and what training data you need.