How I AIHow to build prototypes that actually look like your product | Colin Matthews
CHAPTERS
- 2:51 – 3:41
Why AI prototypes fail inside real companies (and the fix: component-first)
Claire frames the adoption problem: AI prototyping tools often produce generic UIs that don’t match a company’s brand or design system, which frustrates designers and engineers. Colin introduces a simple, transferable solution: build a component library first, then assemble prototypes from those components rather than generating full screens from scratch.
- •AI prototyping empowers PMs but outputs often don’t match brand/design systems
- •Mismatched prototypes reduce internal buy-in and create “unasked-for work”
- •Component libraries are the bridge between AI speed and product fidelity
- •Approach is tool-agnostic (not specific to v0, Bolt, etc.)
- 3:41 – 5:18
Creating a component library from screenshots in v0
Colin walks through his core workflow in v0: use a reusable prompt that instructs the model to extract components from a screenshot rather than recreate whole views. He iteratively feeds screenshots page-by-page to expand the library with consistent, reusable UI building blocks.
- •Use a dedicated prompt to force “components only,” not full page recreation
- •Iterate by sending multiple screenshots and asking to “continue adding components”
- •Extract foundational elements (logo, search, nav, cards, ratings, etc.)
- •Goal is a clean list of components that can be reused across prototypes
- 5:18 – 6:16
Team-wide consistency: sharing component libraries as reusable assets
Claire and Colin highlight the compounding benefits of a shared component library. Instead of each person producing inconsistent, one-off prototypes, the team can reuse the same primitives for a consistent visual language and fewer downstream misunderstandings.
- •Component libraries enable consistent look-and-feel across many prototypes
- •Sharing the library helps multiple teammates prototype with the same style
- •Visual consistency reduces stakeholder distraction and improves feedback quality
- •Building modularly can reduce errors when AI stitches screens together
- 6:16 – 8:30
Forking the library to assemble new screens (Airbnb homepage demo)
Colin demonstrates creating a new prototype by forking the component library project, keeping the library intact while composing new views. He prompts the tool to create an Airbnb homepage from the existing components, adding missing elements only when necessary.
- •Use “fork” to copy the project without modifying the base library
- •Prompt: “Create a homepage for Airbnb” to assemble from existing components
- •AI primarily reuses library components; creates new ones only if missing
- •Demonstrates rapid composition from “Lego pieces” rather than raw generation
- 8:30 – 11:36
How close is ‘good enough’? Fidelity targets and routing details
They discuss fidelity expectations: not pixel-perfect, but close enough that users immediately recognize the product and can focus on the proposed feature. Colin also shows practical prototyping gaps like routing setup, then navigates to a listing/detail page to validate component reuse.
- •Aim for recognizable product realism, not pixel-perfect replication
- •Common imperfections: icon sets, imagery, spacing nuances
- •Key goal: avoid distracting stakeholders with “foreign-looking” UI
- •Routing may require explicit instructions; detail pages reuse relevant components
- 11:36 – 12:25
When to use other tools: introducing Magic Patterns
Claire asks about alternatives to repeated screenshot prompting. Colin introduces Magic Patterns, describing it as a more convenient workflow for building high-fidelity, product-like prototypes—then previews how it can “inject” prebuilt components behind the scenes.
- •v0 flow works, but can require repeated prompting to expand components
- •Magic Patterns is positioned as a more streamlined component workflow
- •Demo goal: generate a ChatPRD-like UI quickly from predefined primitives
- •Shows how far visual fidelity can go with better component foundations
- 12:25 – 15:39
Magic Patterns demo: generating a ChatPRD-style AI chat UI
Colin prompts Magic Patterns to create an AI chat experience for PRDs, and the tool assembles the interface by installing components and wrapping them with a new composite component. They inspect the generated parts (sidebar, messages, input, menus) and tweak elements like removing an unwanted image.
- •Prompt-driven generation backed by a repository of prebuilt components
- •Tool installs UI components automatically, then creates a wrapping interface component
- •Inspectable building blocks: sidebar, chat messages, input, options menu
- •Lightweight editing workflow (e.g., deleting unwanted UI elements)
- 15:39 – 17:51
Extracting real components directly from a live website (Chrome extension)
Colin reveals the Magic Patterns Chrome extension workflow: click any UI element on a live product, extract its HTML/styling, and convert it into a reusable component in a library. This bypasses the need to ask engineers for cleaned-up front-end code just to prototype.
- •Select a UI element in the browser and ‘pull it out’ into Magic Patterns
- •Convert extracted HTML/styling into a reusable, data-ready component (e.g., table)
- •Workflow: extract → convert to component → add to library → reuse everywhere
- •Reduces reliance on design/front-end engineers for prototype-ready components
- 17:51 – 20:12
Versioning and upgrading components: improve primitives, not pages
They move from extraction to long-term maintainability: publish components, iterate on them over time, and upgrade older prototypes to the latest component versions. Claire connects this to a broader lesson—optimize the primitives (components) rather than endlessly tweaking each composed prototype.
- •Publish components and maintain them as durable team assets
- •Upgrade older prototypes to ‘latest’ component versions over time
- •Assign ownership to improve component fidelity without losing work in one-off files
- •Shift mindset: improve components first; composed apps benefit downstream
- 20:12 – 23:44
Forks, baselines, and variants: a sane workflow for iterative prototyping
Colin shows how Magic Patterns supports forking prototypes on a visual canvas, enabling side-by-side exploration without breaking a baseline. He advocates naming conventions like “baseline” and “var 1/2/3” to manage branches cleanly and reduce prompt overhead.
- •Use a visual canvas to manage multiple prototype chats/threads at once
- •Create a baseline prototype, then fork copies for exploration
- •Label variants (baseline, var 1, var 2) with short descriptors
- •Forking reduces prompting to 1–2 messages because you start from a strong base
- 23:44 – 25:05
Operational advice: checkpoints, versions, and avoiding ‘vibe coding’ disasters
Claire generalizes the workflow lesson for all AI tools: make checkpoints when something works, fork for risky experiments, and share stable baselines with the team. Colin adds that structured starting points prevent the error-prone experience many have when they begin from scratch in tools like Bolt or v0.
- •Make copies/checkpoints early to avoid losing good states
- •Fork before exploring uncertain changes so you don’t break the main prototype
- •Baselines help teammates succeed without battling repeated tool errors
- •Consistent UI + strong primitives improves onboarding and adoption across teams
- 25:05 – 28:10
Rolling this out with humans: team dynamics, empathy, and role clarity
Claire asks about organizational friction—egos, roles, and responsibilities. Colin emphasizes empathy: don’t dump a fully baked prototype on designers; instead treat AI prototypes as communication tools that broaden who can contribute ideas, while keeping designers and engineers in control of production decisions.
- •Start with empathy; avoid undermining designers with “clean this up” handoffs
- •AI prototyping expands who can express ideas (ops, CS, non-product roles)
- •Position prototypes as communication artifacts, not role replacements
- •Engineering can reuse code if helpful, but it’s optional—not forced
- 28:10 – 30:29
Prompting when the model won’t listen: ‘explain first, don’t code’
When tools behave unpredictably (like failing to delete an element), Colin’s go-to tactic is to force a reasoning step: ask the AI to explain what’s happening without writing code. Claire reinforces the pattern with a hypothesis-ranking variant for debugging errors.
- •Default tactic: ‘Explain why this is happening. Don’t write any code.’
- •Use the same pattern for UI issues and for error debugging
- •Planning/analysis before changes increases success rate
- •Hypothesis ranking can further structure troubleshooting
- 30:29 – 32:07
Wrap-up and where to learn more: courses, team training, and links
Colin shares where listeners can go deeper: his Maven course on AI prototyping for PMs and a team-focused workshop offering that helps groups leave with component libraries and baseline prototypes. Claire closes with standard show outro and ways to follow the podcast.
- •Maven course: AI prototyping for PMs (tips, tricks, and technical communication)
- •Team workshop: one-day training to produce assets (components + baselines)
- •Additional channels: LinkedIn and Substack
- •Podcast closing: like/subscribe, reviews, and where to find episodes
