How I AIHow to build prototypes that actually look like your product | Colin Matthews
CHAPTERS
Why AI prototypes fail inside companies: brand mismatch and low adoption
Claire frames the core problem: chat-based prototyping tools empower PMs, but their outputs rarely match an organization’s design system, which frustrates designers and engineers and reduces adoption. Colin previews a component-first approach to make AI prototypes look and feel like the real product.
- •AI prototyping shifted capability from specialists (Figma/coding) to broader teams
- •Common failure mode: prototypes don’t match brand/design patterns
- •Mismatched visuals create friction with engineering/design stakeholders
- •Goal: prototypes that communicate ideas without distracting UI inconsistency
Component-first prototyping: build the LEGO set before the screens
Colin introduces the main concept: start by creating a reusable component library rather than generating full pages/views. This approach is tool-agnostic (works beyond v0/Bolt) and improves consistency, reuse, and reliability when assembling new screens later.
- •Component libraries are the foundation for consistent prototypes
- •Prompting must explicitly request components, not reconstructed views
- •Tools often default to generating full pages—requires firm instruction
- •Reusable components enable team-wide consistency across prototypes
Creating a component library from screenshots in v0
Colin demonstrates a workflow in v0 where he repeatedly feeds screenshots to extract UI elements into individual components. Over time, the library grows by iterating: “continue adding components” from page-to-page screenshots.
- •Use a dedicated “create component library from screenshot” prompt
- •Iteratively submit screenshots of different app areas to expand coverage
- •Extract foundational elements (logo, nav, search, cards, ratings, etc.)
- •Build a shared library others can reuse for consistent prototypes
Prompt techniques to reliably extract components (not whole pages)
They discuss how prompting affects outcomes: the model often tries to recreate entire views unless constrained. Colin emphasizes being explicit and persistent so the output becomes a list of components rather than a composed application.
- •Use strict instructions: “Only create components; don’t recreate views”
- •Expect occasional noncompliance; reassert constraints when needed
- •Screenshot-driven extraction helps align styling and structure
- •A prompt library of proven templates increases repeatability
Assembling an Airbnb homepage from the component library (via forking)
Colin shows how to fork the component library project to preserve the pristine components while generating new screens. He prompts the fork to “Create a homepage for Airbnb,” and the system composes a new page using existing components, adding missing ones as needed.
- •Forking keeps the component library unchanged while enabling experimentation
- •The model assembles screens primarily from existing components
- •Missing elements can be created on-demand without breaking the library
- •Result: rapid prototyping with consistent visual language
Quality bar: not pixel-perfect, but unmistakably ‘the product’
Claire asks about fidelity; Colin clarifies the target is recognition and credibility, not perfect replication. The purpose is to keep reviewers focused on the new idea (e.g., an AI feature) instead of being distracted by an unfamiliar UI.
- •Pixel-perfect is hard (icons, imagery, micro-details may differ)
- •Aim for high familiarity so stakeholders recognize the product instantly
- •Better than generic wireframes: brand-aware, context-rich prototypes
- •Primary goal: communicate new feature ideas without UI mismatch noise
Reducing errors by improving modular components (stitching vs. spaghetti)
Colin notes prototypes become more stable when built from modular parts because the AI mostly “stitches” rather than invents large structures. This improves the onboarding experience for teammates who otherwise hit repeated errors in tools like v0/Bolt.
- •Modular components reduce complexity and error rates
- •Stitching known primitives is easier than generating entire apps
- •Improves teammate experience: fewer failures, quicker iteration
- •Better structure yields more predictable AI behavior
Magic Patterns: generating product-faithful UI from a prebuilt component set
Colin introduces Magic Patterns and demonstrates prompting it to build an AI chat interface resembling ChatPRD. Behind the scenes, it installs predefined components and wraps them into higher-level UI, enabling fast iteration with strong brand alignment.
- •Magic Patterns can assemble UI using an existing component repository
- •Demonstration: “AI chat to help with PRDs” built with injected components
- •Tooling can add wrapper components (e.g., chat interface) as needed
- •Fast cleanup/edits possible directly in the UI (e.g., deleting elements)
Chrome extension workflow: extract components directly from a live website
Colin shows the Magic Patterns Chrome extension: click an element on the real site, extract the HTML/styling, then convert it into a reusable component and publish it to a library. This bypasses the common bottleneck of asking engineers to package UI for prototyping.
- •Select UI elements on the live product and extract them instantly
- •Convert extracted HTML/styling into a proper reusable component
- •Publish components to a shared library for repeated use
- •Avoids engineering effort to manually separate styling from logic
Versioning and upgrades: treat components as evolving team assets
They discuss managing components over time: improve individual components and propagate updates into older prototypes via “upgrade to latest.” This reframes effort from one-off prototypes to reusable assets maintained for long-term leverage.
- •Iterate on components rather than repeatedly redoing full prototypes
- •Upgrade older prototypes by pulling the latest component versions
- •Assign ownership to improve visual fidelity and consistency over time
- •Component investment compounds across many prototypes
Forks, baselines, and variants: a disciplined workflow for exploration
Colin demonstrates a Figma-like project canvas where each chat/prototype can be duplicated and forked. Claire highlights best practices—checkpoints, versions, and forks—to prevent vibe-coding chaos and enable side-by-side comparison of variants.
- •Create a labeled baseline prototype, then fork into variants (var 1/2/3)
- •Use copies to explore without breaking the main version
- •Canvas view enables managing multiple prototypes and comparing options
- •Starting from strong baselines reduces prompting to 1–2 messages
Team dynamics: introducing AI prototyping without triggering role conflict
Claire asks how to implement this in real organizations; Colin emphasizes empathy and positioning prototypes as communication tools, not replacements for designers/engineers. He advocates widening who can prototype (ops, CS) while letting engineering adopt outputs only if useful.
- •Avoid dumping fully baked prototypes on designers to ‘clean up’
- •Frame prototypes as shared communication artifacts, not role replacement
- •Enable broader ideation across the org (ops, CS, non-product roles)
- •Engineering can sync to GitHub if desired, but it’s optional
When AI won’t listen: debugging by forcing explanation before code
Colin shares his most reliable tactic: ask the AI to explain why something is happening and explicitly instruct it not to write code. Claire adds a variant: ask for top hypotheses in priority order—useful for errors and stubborn UI changes.
- •Prompt pattern: “Explain why this is happening. Don’t write any code.”
- •Use for errors and unexpected behavior (planning before acting)
- •Asking for ranked hypotheses helps narrow root causes
- •Prevents overeager agents from making premature code changes
Wrap-up: where to learn more and how Colin helps teams operationalize this
Colin shares resources: a Maven course on AI prototyping for PMs and a team workshop offering that delivers 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, technical communication)
- •Team offering: one-day workshop to build assets and define roles
- •Emphasis on leaving with component libraries + baseline prototypes
- •Links: team site, plus LinkedIn/Substack for ongoing content
