Uwaga: Poniższe notatki powstały na podstawie prezentacji Colin Matthews poświęconej AI prototyping. Wszystkie przemyślenia, obserwacje i strategie pochodzą od prowadzącego oraz jego doświadczeń z nauczania ponad 500 product managerów.

TL;DR

Biblioteki komponentów to klucz do jakościowego AI prototyping – pozwalają utrzymać spójność wizualną bez ręcznego poprawiania każdego prototypu
Trzy metody budowy bibliotek: zrzuty ekranu (najłatwiej), rozszerzenia Chrome, kod (najwyższa jakość)
Strategia baseline and forks umożliwia testowanie wielu wariantów bez przebudowywania od zera
Sześciostopniowy cykl rozwoju produktu pokazuje konkretne miejsca dla AI prototyping – od discovery (20 min) po przekazanie programistom
Na etapie discovery iteruj na promptcie, nie na prototypie – pierwsze wersje to jednorazowe szkice do wyrzucenia
Kod z AI prototyping służy komunikacji, nie implementacji – wartość leży w dokumentowaniu wymagań i interakcji
AI prototyping to błogosławieństwo dla systemów projektowych – naturalnie zachęca zespoły do spójności wizualnej

Główne wyzwania zespołów

Colin Matthews identyfikuje dwa kluczowe problemy, z jakimi borykają się zespoły próbujące wykorzystać AI prototyping. Po pierwsze, jakość wizualna prototypów często okazuje się niewystarczająca do pokazania klientom czy senior stakeholderom. Po drugie, większość organizacji zmaga się z brakiem uporządkowanych procesów zespołowych, co skutkuje pracą w silosach zamiast efektywnej współpracy.

Matthews zauważa, że wiele zespołów utyka na „poziomie pierwszym” – indywidualnych eksperymentach z narzędziami jak v0 czy Bolt. Jednak prawdziwa wartość pojawia się dopiero na „poziomie drugim”, czyli przy wdrożeniu ustrukturyzowanych procesów dla całego zespołu.

Biblioteki komponentów – fundament jakościowego prototypowania

Dlaczego komponenty zmieniają wszystko

Matthews podkreśla fundamentalną rolę bibliotek komponentów w podnoszeniu jakości AI prototyping. Komponenty pozwalają utrzymać branding i spójne stylowanie bez konieczności ręcznego poprawiania każdego prototypu. Choć inwestycja w bibliotekę wymaga początkowego wysiłku, w rezultacie tworzy się zasoby wielokrotnego użytku.

Prowadzący porównuje to do systemów projektowych w Figma – nikt nie zaczyna projektowania od zera za każdym razem. Podobnie AI prototyping powinno opierać się na gotowych, sprawdzonych komponentach.

Praktyczny proces tworzenia biblioteki polega na założeniu pustego projektu-kontenera w narzędziu AI, następnie iteracyjnym dodawaniu kolejnych komponentów przez dostarczanie serii zrzutów ekranu z istniejącego produktu.

Trzy ścieżki budowy bibliotek

Matthews przedstawia trzy metody tworzenia bibliotek komponentów, różniące się poziomem wysiłku i jakością rezultatów:

Metoda	Wysiłek	Jakość	Najlepsze dla
Zrzuty ekranu	Niski	Podstawowa	Zespoły startujące z AI prototyping
Rozszerzenia Chrome	Średni	Średnia	Zespoły chcące automatyzacji
Kod	Wysoki	Najwyższa	Zespoły techniczne, małe firmy

Metoda 1: Zrzuty ekranu (niski wysiłek)

Ta metoda nie wymaga wiedzy technicznej i działa z każdym narzędziem. Matthews zaleca rozpoczęcie od strukturalnego prompta, następnie wklejenie zrzutu ekranu interfejsu. Jednak zwraca uwagę na typowy problem – AI często reprodukuje cały ekran zamiast tworzyć listę komponentów. W takim przypadku konieczny jest dodatkowy prompt korygujący.

Metoda 2: Rozszerzenia Chrome (średni wysiłek)

Magic Patterns to jedyne narzędzie oferujące bezpośrednią ekstrakcję komponentów ze stron internetowych. Matthews prezentuje swój przepływ pracy: zaznaczenie elementu UI, automatyczna ekstrakcja stylingu i przekształcenie w komponent wielokrotnego użytku. Prowadzący lubi „wystrzeliwać kilka ekstrakcji jednocześnie” dla maksymalnej efektywności.

Metoda 3: Kod (wysoki wysiłek, najwyższa jakość)

Podejście przez kod wymaga największego wysiłku, jednak zapewnia prototypy niemal nie do odróżnienia od prawdziwego produktu. Matthews wymienia kluczowe wymagania: pomoc inżynierów przy konfiguracji środowiska, znajomość GitHub i terminala oraz przygotowanie front-endu bez zależności back-end.

Prowadzący wspomina także o nowym Figma MCP Server, który umożliwia Cursor autonomiczne pobieranie zrzutów ekranu, ekstraktowanie design tokenów i uzyskiwanie CSS z Dev Mode Figma.

Zespołowe przepływy pracy – od chaosu do systemu

Przepływ pracy 1: Baseline and forks

Matthews wyjaśnia, że podczas gdy komponenty zapewniają building blocks, baseline dostarcza gotową reprodukcję obecnego produktu do łatwego eksperymentowania. Prowadzący demonstruje to na przykładzie Airbnb Experiences.

Stworzenie baseline zajmuje około 20 minut z biblioteką komponentów. Ta strona staje się niemodyfikowaną wersją referencyjną. Każdy fork to jeden prompt na gotowym baseline, co znacznie przyspiesza testowanie wariantów.

Matthews pokazuje konkretne przykłady:

Fork #1: Kwestionariusz personalizacyjny
Fork #2: Rekomendacje na podstawie historii podróży

Przepływ pracy 2: Sześciostopniowy cykl rozwoju produktu

✅ 6-step AI Prototyping Checklist:

□ Step 1: Discovery (20 minut)

Fidelity: Medium
Audience: Wewnętrzny zespół
Cel: Iteracja własnego myślenia, komunikacja z zespołem

Matthews podkreśla kluczową zasadę: „Traktuj prototypy jak rzeczy do wyrzucenia i zamiast iterować na samym prototypie, iteruj na poleceniu, które go generuje”.

□ Step 2: Roadmap alignment (20-60 minut)

Fidelity: High
Audience: Interesariusze, klienci
Cel: Budowanie poparcia, prezentowanie inwestycji

Dzięki temu można pokazać, jak coś będzie działać, zamiast opowiadać o tym abstrakcyjnie.

□ Step 3: PRD and mocks (2 godziny)

Fidelity: Medium
Audience: Zespół produktowy
Cel: Asset komunikacyjny, supplement PRD

Gotowy prototyp staje się żywym elementem dokumentacji, co znacznie ułatwia komunikację z inżynierami i pozwala szybciej wychwycić przypadki brzegowe.

□ Step 4: User interviews (3-5 dni)

Fidelity: Medium/High
Audience: Użytkownicy końcowi
Cel: Testowanie UX, wbudowane ankiety dla skali

Matthews zwraca uwagę na zaawansowane możliwości: można osadzać ankiety, implementować logowanie interakcji czy nagrywanie całej sesji użytkownika dla bardzo dokładnych informacji zwrotnych.

□ Step 5: Engineering scoping (2 godziny)

Fidelity: Low
Audience: Inżynierowie
Cel: Komunikacja wymagań (NIE przekazanie kodu)

Matthews ostrzega: kod z prototypów jest w większości bezużyteczny dla zespołu inżynierskiego, ponieważ nie uwzględnia istniejącej architektury ani właściwego języka programowania. Mimo to prototyp doskonale służy komunikacji wymagań dotyczących animacji czy stanów ładowania.

□ Step 6: Delivery (2-6 tygodni)

Cel: Narzędzie komunikacji przy pytaniach o produkt

Poziomy fidelity – świadome zarządzanie jakością

Matthews wprowadza rozróżnienie na medium fidelity jako kategorię pośrednią między low-fi sketch a high-fi Figma mocks:

Medium fidelity:

Poprawny na pierwszy rzut oka, drobne błędy UI
✅ Komunikacja z inżynierami
✅ Wewnętrzne testy konceptów

High fidelity:

Wymaga więcej czasu i wysiłku
✅ Prezentacje dla CEO
✅ Prezentowanie milionowych inwestycji
✅ Testy z klientami

Współpraca w zespole – czy AI zagraża projektantom?

Matthews odnosi się do częstej obawy, że PM-owie tworzący prototypy AI wejdą w kompetencje projektantów. Jego zdaniem jest wręcz przeciwnie – dla projektantów dbających o spójność wizualną to błogosławieństwo, ponieważ zmusza cały zespół do myślenia komponentami i korzystania ze wspólnego języka wizualnego.

Jednocześnie Matthews przyznaje, że dla osoby biegle posługującej się Figmą praca z promptami może wydawać się „super żmudna”. Z kolei dla menedżera produktu, który – jak sam mówi – „ssie w Figmie”, jest to znacznie szybszy i mniej frustrujący sposób na zwizualizowanie pomysłu.

Praktyczne wskazówki implementacji

✅ Checklist: Jak dodać prawdziwe logo

Problem: AI rysuje „uncanny-valley version” logo zamiast używać prawdziwego

Rozwiązanie – dwie opcje:

□ Opcja 1: Bezpośrednio ze strony

Right-click na logo → inspect element
Skopiuj URL lub SVG content
Użyj promptu do dodania logo

□ Opcja 2: Repozytorium logotypów

Wejdź na Brandfetch.com
Znajdź swoje logo firmowe
Skopiuj odnośnik do osadzenia
Wklej bezpośrednio do AI prototyping tool

Realistyczne zdjęcia przez Unsplash

Matthews poleca proszenie AI o automatyczne dobieranie zdjęć z Unsplash do kontekstu produktu za pomocą prostego promptu.

✅ Implementation Checklist – jak zacząć

□ Faza 1: Podstawy

Wybierz jedną z trzech metod biblioteki komponentów (zalecane: zrzuty ekranu na start)
Stwórz pierwszą bibliotekę komponentów dla swojego produktu
Przetestuj baseline and forks na jednym feature

□ Faza 2: Team adoption

Ustaw jasne expectations co do fidelity levels
Zintegruj z istniejącym product development lifecycle
Wytrenuj zespół na wybranej metodzie

□ Faza 3: Optimization

Dodaj prawdziwe logo i zasoby brandingowe
Ustaw proces sharing bibliotek komponentów w zespole
Zmierz time savings vs tradycyjne metody

Matthews podsumowuje: te elementy to nie nice-to-haves – to różnica między zespołami barely scratching the surface a tymi w pełni integrującymi AI tools ze swoimi best practices i daily workflows.

Biblioteka promptów Matthews – gotowe do użycia

📋 Budowa biblioteki komponentów

1️⃣ Component Library Prompt

You are tasked with creating a component library based on a screenshot, using 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 & 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.

Kiedy używać: Pierwszy krok w budowie biblioteki komponentów przez zrzuty ekranu. Załącz zrzut ekranu interfejsu.

Component Library Fix Prompt

Instead of showing me a page that re-creates the UI, the index page should be a list of components in the component library.

Kiedy używać: Gdy AI reprodukuje cały zrzut ekranu zamiast stworzyć listę komponentów.

Add Components Prompt

Add these components as well.

Kiedy używać: Dodawanie kolejnych komponentów do istniejącej biblioteki. Załącz nowy zrzut ekranu.

📝 PRD i Planning

2️⃣ AI Feature Prompt

Create a PRD for an AI feature for Airbnb to plan full trip itineraries. Start with the value prop and user stories -- I'll provide feedback before we write the full PRD.

Kiedy używać: Szybkie stworzenie structured spec dla AI features. Matthews używał tego w połączeniu z pre-configured Claude project.

3️⃣ PRD Format Template

When creating a PRD, use this format:


**Todoist Clone PRD**

**Overview**
A simplified clone of Todoist, focusing on core task management features while maintaining a clean, modern interface.

**User Stories**
* As a user, I want to create new tasks with titles and due dates.
* As a user, I want to mark tasks as complete.
* As a user, I want to organize tasks into projects.
* As a user, I want to prioritize tasks with different priority levels.
* As a user, I want to edit existing tasks.
* As a user, I want to delete tasks I no longer need.

**Implementation Phases**

**Phase 1: Core Task Management**
* Basic task list UI
* Add/edit/delete tasks
* Mark tasks as complete
* Local storage persistence
* Basic task filtering

**Phase 2: Projects & Organization**
* Create and manage projects
* Assign tasks to projects
* Project-based task filtering
* Task priorities

**Phase 3: Enhanced Features**
* Due dates and reminders
* Task sorting options
* Search functionality
* Keyboard shortcuts

**Design System**
**Colors:**
* Primary: Todoist Red `#db4c3f`
* Secondary: Slate Gray `#808080`
* Background: White `#ffffff`
* Text: Dark Gray `#202020`

**Typography:**
* Inter font family

**Spacing:**
* Consistent 4px/8px grid system

**Components:**
* Task Item
* Add Task Form
* Project List
* Priority Selector
* Date Picker

**Data Model**
*(To be defined later)*

Kiedy używać: Template do strukturyzowania PRD w Claude project. Matthews używał tego jako pre-built instructions w swoim Claude project.

🔧 Iteracja i Poprawa

Reflection Prompt

List the differences between the screenshot and your implementation. How can you match the design more exactly? Don't code.

Kiedy używać: Analiza różnic przed wprowadzeniem poprawek. Matthews nazywa to „reflection technique”.

Component Optimization Prompt

How can we leverage our existing components to improve the design of the Trip Planner? I want the resulting page to use existing [brand] cards, buttons, forms, etc. where possible. What changes can you make?


Overall, make a plan. Don't run any code.

Kiedy używać: Poprawa wykorzystania istniejących komponentów w nowym prototypie. Zastąp [brand] swoją marką.

🚀 Prototyping Specific Features

Mock Data Instruction

Mock all AI responses. Don't connect to OpenAI Claude. This is a client side prototype.

Kiedy używać: Zawsze dodawaj do promptów z features AI – unika problemów z integracjami.

🎨 Baseline and Forks Prompts

Questionnaire Feature Prompt

Modify this page so that it runs through a questionnaire to determine experiences that I would like before showing me experiences. Maintain the [brand] branding.

Kiedy używać: Testowanie wariantu z personalizacją przez kwestionariusz. Fork z baseline.

History-Based Recommendations Prompt

Modify this page so it shows me experiences I would like based on my past travel history with [brand]. For each recommendation, add a UI element that says 'based on your trip to...'

Kiedy używać: Testowanie personalizacji przez historię użytkownika. Fork z baseline.

🖼️ Zasoby i branding

Unsplash Images Prompt

Add images from Unsplash that make sense given the context.

Kiedy używać: Dodawanie realistycznych zdjęć bez szukania konkretnych obrazów.

📊 Specific Use Cases

AI Scheduling Assistant

Create a Google Calendar main page view that has an AI scheduling assistant to recommend deep-work blocks.

Kiedy używać: Matthews pokazywał te jako przykłady konkretnych feature’ów z biblioteką komponentów.

Pro tip od Matthews: Zawsze zaczynaj od planu („make a plan, don’t run any code”) przy większych zmianach – pozwala to zaakceptować direction przed wykonaniem.

Kluczowy insight

Paradoks pustej kartki

Standardowo myślimy: Głównym celem jest jak najszybsze tworzenie spójnych wizualnie prototypów, dlatego pracę zawsze należy zaczynać od załadowania gotowej biblioteki komponentów.

W praktyce okazuje się, że: W najwcześniejszej, najbardziej kreatywnej fazie discovery celowe zrezygnowanie z biblioteki i start z „pustej kartki” może prowadzić do bardziej przełomowych pomysłów. Matthews zauważa, że gotowa biblioteka może nieświadomie zamykać myślenie w istniejących schematach, podczas gdy „dzikie”, niespójne propozycje AI mogą zainspirować do zupełnie nowych rozwiązań.

Dlaczego to jest istotne: Uwalnia to od „klątwy spójności” na etapie, gdy najważniejsza jest eksploracja, a nie optymalizacja. W rezultacie pozwala na odkrycie nowych kierunków, zanim zostaną zamknięte w ramach istniejącego systemu projektowego.

Test na jutro: Następnym razem, gdy rozpoczniesz fazę discovery dla zupełnie nowej funkcji, zamiast od razu ładować bibliotekę komponentów, spróbuj opisać pomysł w narzędziu AI na „czystej karcie” i sprawdź, czy chaotyczne, niespójne wizualnie propozycje nie podsuną Ci rozwiązań, na które nie wpadłbyś trzymając się utartych schematów.

Ten wpis stanowi część kolekcji notatek z wartościowych prezentacji i podcastów. Oryginalne źródło: Maven lightning lesson Colin Matthews „Product Development Lifecycle with AI Prototyping„.

Tag: Workflow W Zespole

AI prototyping dla zespołów – od eksperymentów do profesjonalnych przepływów pracy #EN227