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

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 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

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

Add Components Prompt

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

📝 PRD i Planning

2️⃣ AI Feature Prompt

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

**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

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

Component Optimization Prompt

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

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

🎨 Baseline and Forks Prompts

Questionnaire Feature Prompt

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

History-Based Recommendations Prompt

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

🖼️ Zasoby i branding

Unsplash Images Prompt

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

📊 Specific Use Cases

AI Scheduling Assistant

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„.