O czym jest ten film
- Autor podłącza do Claude Design bibliotekę Mobbin — ponad pół miliona zrzutów ekranów i realnych przepływów użytkownika z istniejących aplikacji.
- Połączenie odbywa się przez serwer MCP Mobbina, dodawany jako konektor w aplikacji Claude na komputer, a następnie widoczny w Claude Design w przeglądarce.
- Konektor udostępnia trzy narzędzia: wyszukiwanie ekranów, sekcji (pojedynczych elementów UI) i przepływów.
- Przykładem roboczym jest aplikacja wspierająca karmienie piersią — prawdziwa prośba od kogoś z otoczenia autora.
- W pierwszym przejściu model generuje trzy odrębne kierunki projektowe dla tej samej aplikacji — nie warianty ekranów, tylko różne koncepcje.
- W drugim przejściu autor wskazuje konkretny przepływ onboardingu z Mobbina (Whisperflow) i każe go przenieść na wybrany kierunek wizualny.
- W trzecim przejściu prosi o wysoko oceniany komponent wyboru czasu i zbudowanie na jego bazie funkcji harmonogramu karmień.
- Duża część materiału to argument metodyczny: najpierw PRD i wymagania, potem kierunek UX, a dopiero na końcu UI, kolory i typografia.
- Autor ostrzega, że pominięcie etapu decyzji produktowych kończy się aplikacją, która wygląda dobrze, ale nie robi tego, co miała robić.
- Domknięciem procesu jest powrót z gotowych projektów do PRD, żeby schemat bazy, modele danych i logika backendu odwoływały się do zaprojektowanych ekranów.
Redakcyjne tłumaczenie
Co właściwie zrobiłem
Dałem Claude Design dostęp do biblioteki zawierającej setki tysięcy zrzutów ekranów i prawdziwych przepływów użytkownika z rzeczywistych aplikacji. Poprosiłem, żeby na tej podstawie zbudował mi aplikację i proces onboardingu — od zera. W tym materiale pokażę, jak nawiązać takie połączenie i jak samemu zrobić to samo.
Wiem, że to nieco osobliwe, że akurat ja robię film na ten temat, bo według statystyk YouTube’a moja widownia to w jakichś 96–98 procentach mężczyźni — a będziemy mówić o piersiach. Inspiracja jest prosta: to aplikacja wspierająca laktację. Wybrałem ten temat, bo ktoś z mojego otoczenia realnie poprosił mnie o pomoc przy jej zbudowaniu. Postanowiłem upiec dwie pieczenie na jednym ogniu: pomóc i przy okazji przetestować nowy serwer MCP, który wam dziś pokażę — po to, żeby szybko wygenerować koncepcje tego, jak ta aplikacja mogłaby wyglądać.
(Informacja dodatkowa: MCP — Model Context Protocol — to otwarty standard, dzięki któremu modele językowe mogą sięgać po dane i narzędzia z zewnętrznych usług przez ustandaryzowany interfejs.)
W efekcie mamy trzy różne ekrany. To trzy fundamentalnie odmienne kierunki dla tej samej aplikacji — nie różne wersje ekranów wewnątrz jednego projektu, tylko odrębne kierunki projektowe, spośród których można wybierać. Do tego powstał całkiem przyjemny przepływ onboardingu: pełnoekranowy ekran startowy z napisem „nightlight”, a potem kolejne kroki — zbieranie adresu e-mail, możliwość wgrania własnego zdjęcia, pytanie o wiek dziecka z ładnymi selektorami typu radio button, pytanie o to, z czym użytkowniczka aktualnie się zmaga, jak mamy się do niej zwracać, i jeszcze kilka dalszych etapów. Wszystko to powstało na podstawie inspiracji projektem z zupełnie innej branży.
Skąd pochodzą te materiały
Narzędzie, z którego korzystamy, nazywa się Mobbin. Omawiałem je na kanale chyba przez ostatni rok i ciągle do niego wracam, bo uważam, że to świetne miejsce na inspiracje do tego, co chcemy zbudować — zwłaszcza przy aplikacjach mobilnych. Ich sekcja stron internetowych nie jest według mnie zbyt mocna, nie ma tam wielu przykładów aplikacji webowych. Ale jeśli budujecie aplikację mobilną, to naprawdę dobre miejsce, żeby poszukać inspiracji dla ekranów, zobaczyć, jak mogą wyglądać poszczególne elementy interfejsu albo jak można poprowadzić onboarding. Mnóstwo dobrego materiału.
Najciekawsze jest to, że do wszystkiego, co tam widzimy, możemy sięgnąć programowo. Wydaje mi się, że w tym narzędziu jest ponad pół miliona ekranów — i wszystkie są dostępne przez serwer MCP. Wchodzimy w ustawienia. Przy okazji: korzystam z planu Pro, więc trzeba się liczyć z kosztem co najmniej 45 dolarów za dostęp do planu płatnego. Po wejściu w ustawienia znajdziemy tam opcję serwera MCP. Jeśli chcecie używać go bezpośrednio w Codeksie, v0, Cursorze, Claude Code czy czymkolwiek podobnym — da się to zrobić bez większych trudności. Ja jednak pokażę, jak podpiąć go do Claude Design.
Dlaczego Claude Design
Jeśli macie jakiekolwiek trudności z tworzeniem ładnych projektów albo po prostu chcecie usprawnić ten proces, gorąco polecam Claude Design. To znakomite narzędzie. Wpinam je też głęboko w swój faktyczny proces deweloperski. Kiedy przygotowuję PRD dla jakiegoś elementu albo mam nową funkcję do zbudowania, najpierw wchodzę do Claude Design i tam to projektuję. Mam potem skille, które pomagają ożenić projekt z backendem — buduję schemat, bazę danych i logikę biznesową, wiedząc już, jak mają wyglądać komponenty. Chodzę tam i z powrotem między projektem a implementacją, żeby te dwie warstwy się spotkały.
(Informacja dodatkowa: PRD — Product Requirements Document — dokument opisujący, co produkt ma robić, zanim zapadną decyzje o jego wyglądzie.)
Miła rzecz w Claude Design jest taka, że w sekcji zarządzania konektorami możemy podłączyć wszystko, co mamy zintegrowane w aplikacji Claude na komputer. W moim przypadku widać podłączonego Notiona i podłączony serwer MCP Mobbina. A robi się to tak: ponieważ Claude Design działa w przeglądarce i nie ma tam bezpośredniego sposobu na podpięcie serwera MCP, robimy to przez aplikację desktopową. Wchodzimy w ustawienia konta Claude, przewijamy do konektorów, wybieramy „dodaj konektor”, potem „przeglądaj”, wpisujemy „mobbin” — i znajdziemy tam konektor wspierany przez społeczność.
Trzy narzędzia: ekrany, sekcje, przepływy
Konektor daje nam trzy możliwości: wyszukiwanie przepływów, wyszukiwanie ekranów i wyszukiwanie sekcji. Wyjaśnię, co dokładnie to znaczy.
Po pierwsze — ekrany. Możemy pobrać faktyczne zrzuty ekranów, te, które oglądamy w interfejsie Mobbina.
Po drugie — konkretne elementy interfejsu. Powiedzmy, że pracujecie nad określonym rodzajem przycisku albo nad sposobem prezentacji jakiejś informacji. Możecie poprosić o zwrócenie wyłącznie tych elementów. Na przykład zastanawiacie się, jak najlepiej pokazać w aplikacji podpowiedź kontekstową — ściągacie te wzorce do siebie i czerpiecie z nich inspirację.
Po trzecie — przepływy. Jeśli chcecie zbudować doświadczenie onboardingu, możecie wywołać je bezpośrednio przez serwer MCP. Krótko mówiąc: wszystko, co widzimy w interfejsie Mobbina, da się wciągnąć do Claude Design.
Pierwsze podejście: kierunki projektowe
Przechodzimy do budowania. Wracamy do naszego przykładu: makieta aplikacji wspierającej karmienie piersią dla świeżo upieczonych matek. Gdzie do gry wchodzi serwer MCP? Piszemy wprost: masz użyć serwera MCP Mobbina, żeby zaczerpnąć inspirację z innych aplikacji.
Pierwsze przejście brzmi więc: przejrzyj te wszystkie ekrany i zaproponuj wyraźnie odmienne kierunki UI i UX, które moglibyśmy rozważyć. Do tego wklejam listę funkcji, które ta aplikacja ma mieć — oparte na rozmowie, którą w tym przypadku odbyłem z siostrą.
Ważna uwaga: tutaj podrzuciłem tylko kilka punktów, ale realnie, jeśli chcecie, żeby to narzędzie działało możliwie skutecznie, powinniście przekuć to w jakieś lekkie PRD. Mam skill, do którego podlinkuję poniżej, jeśli ktoś chce. Chodzi o to, żeby wziąć opis tego, co aplikacja ma umieć, i zacząć przekształcać go w zestaw wymagań: co funkcjonalnie użytkownik ma móc z tym zrobić. Robimy to dlatego, że dopiero z tych ustaleń wynikają decyzje o faktycznym doświadczeniu użytkownika — czym ta aplikacja ma być i jak ma realizować swój cel. Do interfejsu, kolorów, odstępów, układu i typografii możemy przejść później, kiedy mamy już pewność, że rzecz funkcjonalnie zrobi to, czego od niej oczekujemy.
Wiele osób ten krok pomija, a potem jest bardzo niezadowolonych, że aplikacja jakoś nie robi tego, co miała robić. To będzie się wam zdarzać zawsze, jeśli przeskoczycie decyzje produktowe i od razu rzucicie się na projektowanie. Pokazuję tu, jak działa serwer MCP Mobbina, ale w praktyce chcecie to wpiąć w swój realny proces budowania.
Kolejność pracy: od PRD do ekranów i z powrotem
Żeby pokazać wizualnie to, o czym mówię: zaczynamy od PRD, gdzie opisujemy, co ta rzecz ma funkcjonalnie umieć. Potem tłumaczymy to na właściwe wymagania — dokumentację, w której nie mówimy jeszcze, jaki kształt to ma przybrać, tylko jakie zadania użytkownika ma zrealizować.
Kiedy mamy te dwa dokumenty, wchodzimy dalej. To, co lubię robić, zanim jeszcze sięgnę po narzędzie takie jak Claude Design, to przemyśleć kierunek UX. Ten sam problem można komuś rozwiązać na wiele sposobów. W aplikacji, którą tu opisujemy, jest pewnie kilkadziesiąt możliwych kierunków. Czy to ma być doświadczenie oparte na formularzu? Na czacie? Czy aplikacja zagaduje użytkowniczkę proaktywnie, czy jest czysto reaktywna i to użytkowniczka wszystko inicjuje? Możliwości złożenia tego w całość jest naprawdę mnóstwo. Trzeba to przemyśleć w kontekście tego, co konkretnie próbujecie osiągnąć. To etap, którego nie chcecie pomijać.
Dopiero kiedy wiemy, co ta rzecz ma funkcjonalnie umieć i jaki ogólny kształt przyjmie, zamieniam to wszystko na prompty do poszczególnych ekranów, wchodzę do narzędzia takiego jak Claude Design i projektuję je pojedynczo.
Potem spędzamy pewnie kilka godzin na iteracjach, upewniając się, że jesteśmy zgodni co do kierunku, dopracowując wszystkie funkcje produktu, stany puste, elementy nawigacyjne i tak dalej. Krok ostatni: wracamy, ściągamy gotowe projekty z Claude Design z powrotem do naszych PRD i pilnujemy, żeby schemat bazy danych, modele danych, logika backendu i wszystkie potrzebne historyjki były właściwie ułożone w kolejności i żeby odwoływały się do zaprojektowanych ekranów.
Dostaję dużo pytań o to, jak przeprowadzić duży projekt od początku do końca. To właśnie taki proces to umożliwia. Mam wtyczkę, która robi to wszystko, w mojej płatnej społeczności — link w opisie. Ten darmowy generator lekkiego PRD, o którym wspomniałem, też podlinkuję, gdyby ktoś chciał tylko tę część.
Wynik pierwszego przejścia
Widzimy teraz, co wyszło z drugiej strony. Model przeszedł przez proces, ściągnął z Mobbina sporo różnych ekranów — projektowanie zresztą wciąż trwa — i na tej podstawie zbudował dla nas kilka kierunków. Oczywiście nie jestem kobietą, ale wydaje mi się, że akurat ten kierunek najbardziej trafiałby w tę grupę odbiorczyń. I to bez tego, żebym na potrzeby tego materiału robił pogłębione badania użytkowników.
Drugie podejście: przepływ onboardingu
Gdzie jeszcze można wykorzystać ten serwer MCP? Przejdziemy szybko przez dwa zastosowania. Pierwsze to zbudowanie realnego przepływu onboardingu.
Wracamy do Mobbina, wchodzimy w przepływy, a tam jest sekcja poświęcona onboardingom. Możemy przejrzeć, jak wyglądają procesy wdrożenia w różnych aplikacjach. Jeśli któryś się wyróżnia — bo jest naprawdę wysokiej jakości, bo dobrze pasuje do niszy, w której działamy, albo z jakiegokolwiek innego powodu dobrze się z nim czujemy — po prostu go zapamiętujemy. Można je zresztą zapisywać; tworzy się z tego kolekcja.
Przewijam, aż znajdę coś, co pasuje do tego, co chcemy zrobić. Podoba mi się ten od Whisperflow. I nie chodzi tu koniecznie o samą estetykę, tylko o to, jakie pytania są zadawane i jak ogólnie poprowadzony jest ten przepływ.
Tworzymy nowy czat. Pracujemy dalej na kierunku 1A. Piszę: użyj serwera MCP Mobbina, ściągnij przepływ onboardingu Whisperflow i połącz go z kierunkiem 1A, żeby zbudować makietę procesu wdrożenia w aplikacji.
Zastrzeżenie, które przy takich rzeczach zawsze powtarzam: to my powinniśmy przemyśleć te pytania. Nie oddajemy Claude Design decyzji o tym, o co pytać na onboardingu.
Widzimy pełnoekranowy ekran powitalny, który wprowadza nas do pierwszego ekranu z powitaniem. Mamy interaktywne pola wyboru, spójne wizualnie z resztą projektu. Można odpowiedzieć na pytania o dziecko i całą resztę. Wygląda to całkiem nieźle. Jeśli kiedykolwiek próbowaliście zbudować własny onboarding od zera, wiecie, że to wypada naprawdę dobrze w porównaniu z tym, co wychodzi, gdy robi się to ręcznie.
Rezultat dość wiernie podąża za projektem, któremu przyglądaliśmy się w Whisperflow: mieliśmy tam pełnoekranowy obraz bohaterski, mamy podobny sposób zadawania pytań — dokładnie to, co wylądowało w naszej aplikacji. Struktura tych ekranów jest odwzorowana przyzwoicie. Gdybyśmy chcieli dorzucić momenty potwierdzenia — gratulacje i tym podobne — możemy o to poprosić.
Trzecie podejście: pojedynczy komponent
Ostatnia rzecz do przetestowania to elementy interfejsu. Powiedzmy, że chcemy mieć funkcję wyboru godziny. Wracamy i piszemy: na bazie kierunku 1A użyj MCP Mobbina, żeby wybrać wysoko oceniany komponent wyboru czasu, i zbuduj na jego podstawie makietę funkcji harmonogramu karmień. To tylko przykład pokazujący, jak model potrafi sięgnąć po konkretne inspiracje projektowe z Mobbina.
Widzimy zamakietowaną nową funkcję: harmonogram, w którym ludzie odnotowują karmienia. Nawiasem mówiąc, wymyślam te funkcje na poczekaniu — nie mam pojęcia, czy tak to powinno wyglądać. Właśnie dlatego robi się badania użytkowników. Ale jeśli wejdziemy w jeden z tych wpisów, zobaczymy ładny komponent, w którym można wybierać godziny. Całość wygląda naprawdę nieźle. I to wszystko przyszło z tych selektorów w Mobbinie.
Model potrafi więc podejmować sensowne decyzje o tym, co wybrać, jaką ogólną strukturę to ma mieć i co pasuje do estetyki aplikacji. On faktycznie ogląda te obrazy i na ich podstawie podejmuje decyzje. Świetne narzędzie.
Skill do lekkiego PRD będzie w opisie, jeśli ktoś chce sobie taki dokument szybko wygenerować. A jeśli chcecie pełny proces i nauczyć się prowadzić większe projekty od początku do końca, aż po sprzedaż — to, co tu pokazałem, to tylko mały wycinek tego, co mam w płatnej społeczności. W momencie nagrywania jest tam około 70 osób. To tyle w tym materiale, do zobaczenia w kolejnym.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Bibliotekę wzorców UI można podłączyć do narzędzia projektowego przez MCP
Na czym polega: Mobbin udostępnia swój katalog (ponad pół miliona ekranów, sekcji i przepływów) jako serwer MCP, dzięki czemu model nie zgaduje, jak wygląda dobry interfejs — tylko ogląda realne zrzuty z działających aplikacji.
Jak stosować: Podłączcie konektor i w promptach wprost każcie modelowi z niego skorzystać („użyj MCP Mobbina, żeby…”). Bez takiej instrukcji model często zaprojektuje z własnych skojarzeń.
Na co uważać: To płatna usługa — autor mówi o planie Pro od około 45 dolarów. Konektor jest wspierany przez społeczność, nie przez producenta, więc jego dostępność i stabilność mogą się zmieniać.
2.Konektor MCP dodaje się w aplikacji desktopowej, a używa w przeglądarce
Na czym polega: Claude Design działa w przeglądarce i nie ma tam interfejsu do dodania serwera MCP. Konektory podłączone w aplikacji Claude na komputer stają się widoczne w sekcji zarządzania konektorami w Claude Design.
Jak stosować: Ustawienia konta Claude → konektory → dodaj konektor → przeglądaj → wyszukaj nazwę usługi. Potem wróćcie do Claude Design i sprawdźcie, czy konektor jest aktywny.
Na co uważać: Ta obserwacja opisuje stan narzędzi w sierpniu 2026 — ścieżka w interfejsie może się zmienić. Jeśli konektora nie widać w przeglądarce, najpierw sprawdźcie, czy jest naprawdę włączony w desktopie.
3.Trzy poziomy zapytań: przepływ, ekran, komponent
Na czym polega: Konektor daje osobne narzędzia do szukania całych przepływów (np. onboarding), pojedynczych ekranów i wyodrębnionych sekcji interfejsu (przycisk, podpowiedź, selektor czasu).
Jak stosować: Dobierzcie poziom do problemu. Nie wiecie, jak poprowadzić wdrożenie — szukajcie przepływu. Utknęliście na jednym elemencie — szukajcie sekcji. Chodzi o ogólny nastrój wizualny — szukajcie ekranów.
Na co uważać: Prośba o „inspirację” bez wskazania poziomu daje rozmytą odpowiedź. Im konkretniej nazwiecie, czego szukacie, tym trafniejsze materiały wrócą.
4.Najpierw kierunki, potem szczegóły
Na czym polega: Pierwsze przejście autora nie generuje wariantów tego samego ekranu, tylko trzy fundamentalnie różne koncepcje całej aplikacji, spośród których się wybiera.
Jak stosować: W pierwszym promptcie żądajcie wprost „wyraźnie odmiennych kierunków UI i UX”. Wybierzcie jeden, nadajcie mu etykietę (autor mówi o „kierunku 1A”) i w kolejnych czatach się do niej odwołujcie.
Na co uważać: Trzy warianty tego samego pomysłu to iluzja wyboru. Jeśli propozycje różnią się tylko kolorami, doprecyzujcie, że mają się różnić modelem interakcji, a nie stylistyką.
5.Kolejność: PRD → wymagania → UX → UI
Na czym polega: Autor stanowczo twierdzi, że decyzje o kolorach, odstępach i typografii mają sens dopiero po ustaleniu, co produkt funkcjonalnie robi i jakie zadania użytkownika realizuje.
Jak stosować: Zanim otworzycie narzędzie projektowe, zapiszcie choćby lekkie PRD, a potem wymagania sformułowane jako zadania użytkownika — nie jako opisy ekranów.
Na co uważać: Autor wprost ostrzega: pominięcie tego etapu prawie zawsze kończy się aplikacją, która nie robi tego, co miała robić. Łatwość generowania ładnych ekranów jest tu największą pokusą.
6.Kierunek UX to osobna decyzja, przed projektowaniem
Na czym polega: Ten sam problem można rozwiązać na kilkadziesiąt sposobów: formularz czy czat, aplikacja proaktywna czy reaktywna. To rozstrzygnięcie zapada przed pierwszym ekranem.
Jak stosować: Wypiszcie kilka alternatywnych modeli interakcji dla swojego produktu i świadomie wybierzcie jeden, uzasadniając wybór celem produktu.
Na co uważać: Jeśli oddacie tę decyzję modelowi, dostaniecie kierunek najczęstszy w danych treningowych, a nie najlepszy dla waszego przypadku.
7.Przepływ można pożyczyć z zupełnie innej branży
Na czym polega: Onboarding aplikacji laktacyjnej powstał na wzór onboardingu Whisperflow — narzędzia z zupełnie innego obszaru. Chodziło nie o estetykę, tylko o strukturę: jakie pytania i w jakiej kolejności.
Jak stosować: Szukając wzorca przepływu, patrzcie na jego logikę, a nie na branżę. Wskażcie modelowi konkretną aplikację po nazwie i połączcie ją z waszym wybranym kierunkiem wizualnym.
Na co uważać: Pożyczajcie strukturę, nie treść. Autor podkreśla, że konkretne pytania onboardingowe muszą wynikać z waszych badań, a nie z propozycji modelu.
8.Treść pytań onboardingowych to decyzja człowieka
Na czym polega: Model chętnie wymyśli pytania i funkcje — autor przyznaje, że część funkcji w demie wymyślił na poczekaniu i sam nazywa to argumentem za badaniami użytkowników.
Jak stosować: Traktujcie wygenerowany onboarding jako rusztowanie wizualne, a listę pytań podmieńcie na własną, opartą na rozmowach z użytkownikami.
Na co uważać: Ładna makieta łatwo uwiarygadnia złe decyzje produktowe. Im lepiej wygląda, tym mniej chętnie się ją kwestionuje.
9.Pętla domykająca: z projektów z powrotem do PRD
Na czym polega: Po godzinach iteracji autor ściąga gotowe projekty z powrotem do dokumentów produktowych, żeby schemat bazy, modele danych, logika backendu i historyjki odwoływały się do konkretnych ekranów i były właściwie posekwencjonowane.
Jak stosować: Po zamknięciu warstwy projektowej zaktualizujcie PRD o odniesienia do ekranów, zanim zaczniecie pisać backend. To ta pętla pozwala prowadzić duże projekty end to end.
Na co uważać: Bez tego kroku projekty i implementacja rozjeżdżają się cicho — komponenty powstają pod inny model danych, niż zakłada backend.
10.Model faktycznie ogląda obrazy i wybiera świadomie
Na czym polega: Przy prośbie o „wysoko oceniany komponent wyboru czasu” model przejrzał selektory w Mobbinie i dobrał taki, który pasował do struktury i estetyki projektowanej aplikacji.
Jak stosować: Formułujcie prośby o komponenty z kryteriami jakości i dopasowania („wysoko oceniany”, „pasujący do kierunku 1A”), zamiast prosić po prostu o „time picker”.
Na co uważać: Trafność takiego wyboru zależy od tego, jak dobrze opisaliście wcześniej kierunek. Przy pustym kontekście „dopasowanie do estetyki” nie ma do czego się odnieść.