How I AI: Colin Matthews' Workflows for Prototyping with Your Brand's UI

AI-generated prototypes often fail when you show them to a real team. The workflow may function, but the interface looks generic enough that everyone debates the fake UI instead of the idea being tested. Colin Matthews' workaround is simple: build the design system first, then let AI assemble screens from components that already match your product.

Instead of prompting v0 to create a homepage, Colin starts by extracting interface building blocks from screenshots. In this episode of How I AI, Colin, a product manager and founder who teaches on Maven, walks through the workflow he uses to build reusable component libraries, pull UI elements from production apps with Magic Patterns, and prototype from a stable baseline. He demonstrates the process with Airbnb examples and my own ChatPRD interface.

Colin's approach is deliberately structured: build reusable components from screenshots, extract styling from ChatPRD with the Magic Patterns extension, and protect working baselines with forks and checkpoints before experimenting.

Build a reusable component library before generating screens

Getting AI prototypes to look on-brand is still difficult. Most generators default to polished but generic interfaces. Colin flips the workflow. Instead of generating full pages, he first creates a component library containing buttons, cards, search bars, navigation, ratings, booking modules, typography, and other reusable patterns.

He describes these as the Lego bricks of the product. Once they exist, future prototypes inherit the same visual language automatically. The goal is recognizable fidelity, not pixel-perfect replication.

The prompt that pushes v0 away from full-page generation

Instead of starting with a prompt like "create a homepage," Colin begins by instructing the AI to create a component library based on a screenshot of an existing product. He uses a detailed master prompt that sets the stage for the entire project. This first instruction is what guides the AI away from its default of building full pages.

Colin's master prompt tells v0 to stop building full views and focus on reusable components. The on-brand component-library workflow shows how he expands that library one screenshot at a time before assembling full pages.

You are tasked with creating a component library based on a screenshot, using NextJs, React, and Tailwind CSS. All components should be custom-made to match the screenshot as closely as possible. Follow these instructions carefully:
1. Analyze the provided screenshot
2. Identify distinct UI components in the screenshot. These may include, but are not limited to:
◦ Buttons
◦ Input fields
◦ Navigation bars
◦ Cards
◦ Modals
◦ Typography elements
3. For each identified component:
a. Create a React functional component
b. Use Tailwind CSS classes to style the component, matching the visual design in the screenshot
c. Ensure the component is responsive and accessible
d. Add any necessary props for customization
e. Include a brief comment describing the component's purpose
4. After creating all individual components, create an index page that imports and displays each component with example usage.
Remember to use only custom-made components and Tailwind CSS classes. Do not use any external libraries or pre-built components. Strive to match the visual design in the screenshot as closely as possible while maintaining good coding practices and component reusability.

Expand the library one screenshot at a time

After the first pass, Colin feeds the model screenshots from other parts of the product. In the demo, he uploads Airbnb screens containing property cards, search bars, ratings, booking sections, navigation tabs, and listing layouts.

The follow-up prompting is simple. He repeatedly tells the model to continue adding components. The system analyzes each screenshot and adds reusable patterns to the shared library.

The process is intentionally incremental. Instead of recreating an entire application in one shot, he gradually builds enough coverage for future prototypes to feel believable.

Protect the source library with forks

Before generating a prototype, Colin forks the component library project. The copy becomes a sandbox for a specific exploration while the original library stays reusable.

This prevents experiments and debugging attempts from destabilizing the main project. Colin treats the component library like shared infrastructure rather than a disposable prototype.

Generate full screens from existing components

Only after the library exists does Colin ask the AI to create a full page. In the Airbnb example, the prompt stays lightweight because most of the work already happened upstream in the components.

create a homepage for Airbnb

This workflow feels different from typical AI prototyping. Instead of inventing an interface from scratch, the model assembles the page from existing components and creates new elements only when needed.

The resulting homepage looked immediately recognizable as Airbnb. Some spacing and imagery still drifted from the real product, but the interface carried enough visual identity that the discussion focused on the feature instead of the mockup.

Colin noted that these tools are already good at wireframing, but teams often reject the outputs because the defaults feel disconnected from the actual product. Even approximate brand fidelity changes how seriously people engage with a prototype.

The modular structure also improves reliability. Colin said he sees fewer broken layouts once the primitives are in place.

Extract production UI directly from your live product

The screenshot workflow still requires manual prompting and curation. Colin also demonstrated a faster path using the Magic Patterns Chrome extension, which pulls interface elements directly from a live product and converts them into reusable React components.

It felt like a bridge between AI prototyping and production UI systems.

Capture components from the browser

Inside ChatPRD, Colin opened the Magic Patterns extension, selected a table interface from the live app, and extracted it in seconds.

You click the interface element, capture it, then send it into the shared component library. The extension grabs the HTML and styling information from the page.

Turn extracted code into reusable React components

After extraction, Magic Patterns rebuilds the captured interface into a reusable React component that can accept dynamic data.

Colin showed the underlying prompt, which included large portions of the source HTML and CSS. The AI restructures that output into something reusable inside the prototype environment.

The result is not just a screenshot clone. It becomes a component that can be imported and reused across prototypes.

Extracting production UI changes who can participate in prototyping, while stripping away business logic that would make the component hard to reuse. The live-website component workflow covers capture, conversion, cleanup, and reuse inside a prototype library.

Improve the components instead of endlessly fixing screens

One of Colin's most useful ideas is that teams should improve the primitives instead of repeatedly patching finished prototypes.

In practice, this means investing in cleaner components and reusable patterns. Once those exist, prompts become shorter, outputs become more stable, and future prototypes inherit the improvements automatically.

Keep prototypes manageable with forks and deliberate debugging

AI-generated prototypes become chaotic once experiments, fixes, and exploratory prompts accumulate in the same workspace. Colin relies on forks, naming conventions, checkpoints, and separate debugging passes to keep projects usable over time.

He said he spends less time debugging when the system stays modular and organized upfront.

Use baseline versions instead of endlessly editing one prototype

Magic Patterns includes a visual canvas similar to a Figma board. Each prototype exists as its own frame with the underlying chat history attached.

When Colin reaches a version that represents the product well enough, he labels it as the baseline and duplicates it before exploring anything new. His naming convention is intentionally simple:

• Baseline: the stable version that reflects the current product experience.
• Variation 1: a fork exploring one direction or feature.
• Variation 2: a separate branch testing another approach without affecting the baseline.

This lets you explore multiple creative directions in parallel without ever losing your stable starting point. It's like a modern version of design_final_v2_FINAL_really_this_one.psd, but with all the power of interactive code.

Separate diagnosis from implementation

One of Colin's strongest prompting habits appears during debugging. When the AI introduces a bug or behaves unpredictably, he does not immediately stack more implementation instructions into the chat.

Instead, he asks the system to explain what is happening first. He uses the same pattern for runtime errors, layout issues, and broken interactions.

1. Diagnose first: ask the AI to explain the issue and identify the likely cause without generating code.
2. Implement second: once the explanation makes sense, ask the AI to apply the fix.

His default debugging prompt is intentionally plain: explain what is happening and do not write code. I use a similar hypothesis-first pattern. The systematic prototype-debugging workflow separates diagnosis from implementation so another speculative fix does not deepen the rabbit hole.

Tried to delete this but it didn't work. Can you explain why? Don't write any code.

This explain, then solve pattern works for visual glitches, runtime errors, and pretty much any other unexpected behavior. It’s like asking the AI to think before it acts. You get much more reliable results than when you let it just jump straight to writing code.

Build the system before the screen

The broader takeaway is that AI prototyping becomes more useful once teams stop treating each prototype as a standalone artifact.

Reusable components, protected baselines, structured debugging, and controlled forks make outputs easier to evaluate and extend. They also lower the barrier for non-designers and non-engineers to communicate ideas through working interfaces.

Colin framed these workflows as communication tools, not replacements for designers or engineers.

The operating model is straightforward: invest in reusable components, protect the clean baseline, fork before experimenting, and debug through explanation before implementation.

That structure reduces prompting later because the AI assembles from known primitives instead of improvising every screen from scratch.

What feels most worth copying here is not a single tool or prompt, but the mindset shift.

If your team already prototypes in v0, Cursor, Bolt, or Magic Patterns, even a modest component library improves consistency and lowers friction during reviews. The extraction workflow is especially useful for internal tools and established products where visual familiarity matters more than pixel perfection.

Human judgment still matters. Someone has to decide which components deserve refinement, when a generated interaction is misleading, and where fidelity matters more than speed. But Colin's workflow makes AI prototypes feel much closer to real product exploration and much less like disposable demo ware.