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.

For this concept, that meant mapping the full lifecycle of a clinical note from creation in the EHR through to coordinator action, and identifying exactly where coordinators 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.

For clinical AI tools specifically, this step is non-negotiable. You cannot design a credible human-in-the-loop review workflow without understanding how other teams have approached AI 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. Healthcare workflows are too domain-specific for AI to navigate reliably.

This is where the workflow becomes genuinely different from traditional design practice. I feed the product proposal document into Lovable 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 care coordinator considers primary versus supporting detail. I restructure visual weight and progressive disclosure based on how coordinators actually think about patient priority.

Accessibility — AI-generated UIs consistently underperform here. Color contrast, type sizing, and information density all require active correction in clinical environments where mistakes have real consequences.

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.