Claude Design - prototyp interfejsu bez umiejętności projektowania

Klient pyta „a jak to będzie wyglądać?" i projekt zatrzymuje się na dwa tygodnie. Makiety, uwagi, poprawki, kolejna wersja. Claude Design skraca ten etap do rozmowy: opisujesz czego chcesz i dostajesz klikalny interfejs. Pokażę Ci, jak to działa, gdzie ma sens i gdzie się wykłada.

Czytanie: ~10 min

Czym jest Claude Design i skąd się wziął

Anthropic wypuściło Claude Design 17 kwietnia 2026 pod szyldem Anthropic Labs, czyli działu, w którym testują rzeczy jeszcze niedopieczone. Narzędzie siedzi w osobnej zakładce Design na claude.ai i działa na modelu Opus 4.7. Dostęp mają subskrybenci planów Pro, Max, Team i Enterprise, ciągle w statusie research preview.

Zasada działania jest prosta do bólu. Piszesz, co chcesz zobaczyć: stronę główną dla firmy remontowej, panel administracyjny z listą zleceń, deck inwestorski na dziesięć slajdów, one-pager z ofertą. Po kilkunastu sekundach masz pierwszą wersję na ekranie.

Kluczowa różnica względem generatorów grafiki: to nie jest obrazek. Claude Design zwraca żywy kod HTML, który możesz kliknąć. Przyciski reagują, formularze się rozwijają, zakładki przełączają. Możesz to pokazać komuś na spotkaniu i pozwolić mu poklikać, zamiast tłumaczyć „a tu po kliknięciu wyskoczy okienko".

Dla kogoś, kto nie projektuje zawodowo, to zmienia punkt startu. Nie musisz znać Figmy, nie musisz wiedzieć, czym jest auto-layout ani jak ustawia się siatkę. Opisujesz zawartość i cel, resztę dostajesz w formie, którą da się ocenić okiem.

Dlaczego klikalny prototyp bije statyczną makietę

Statyczna makieta kłamie. Wygląda ładnie na slajdzie, a potem okazuje się, że w prawdziwym użyciu trzeba zrobić siedem kliknięć, żeby dodać jedno zlecenie. Tego nie widać na obrazku.

Prototyp, który reaguje, wyłapuje takie rzeczy w pięć minut. Dajesz go komuś z zespołu klienta, mówisz „dodaj tu fakturę" i patrzysz, gdzie się zawiesza. Cała reszta rozmowy o wyglądzie schodzi wtedy na drugi plan, bo naraz gadacie o tym, co naprawdę ważne: czy proces ma sens.

Poprawki wprowadzasz na trzy sposoby. Możesz napisać komentarz bezpośrednio przy elemencie na ekranie, powiedzieć głosem, co zmienić, albo przesunąć suwak przy parametrach typu odstępy czy zaokrąglenia rogów. Ostatnia opcja jest wygodna, jeśli nie masz słownictwa, żeby opisać, o co Ci chodzi. Widzisz efekt na żywo i zatrzymujesz się tam, gdzie wygląda dobrze.

Pierwszy projekt krok po kroku

Krok 1: napisz prompt zawierający kontekst, nie tylko wygląd

Największy błąd początkujących to prompt w stylu „zrób ładny landing page". Dostaniesz coś ładnego i kompletnie nieprzydatnego.

Zamiast tego podaj cztery rzeczy: kto jest odbiorcą, co ma zrobić po wejściu, jakie sekcje mają się znaleźć i jaki jest charakter marki. Przykład, który działa:

Zrób stronę główną dla jednoosobowej firmy zajmującej się prototypami aplikacji. Odbiorca: właściciel małej firmy, który rozważa zamówienie systemu. Cel: umówić rozmowę. Sekcje: nagłówek z propozycją wartości, trzy typowe problemy klienta, jak wygląda współpraca w czterech krokach, dwa przykłady realizacji, formularz kontaktowy. Ton: konkretny, techniczny, bez korporacyjnego żargonu. Kolorystyka stonowana, dużo światła.

Różnica w wyniku jest kolosalna. Pierwszy prompt daje generyczny szablon, drugi daje coś, co można od razu pokazać.

Krok 2: iteruj po jednym elemencie naraz

Kuszące jest wrzucenie dziesięciu uwag w jednej wiadomości. Nie rób tego, bo model zaczyna kompromisy i część uwag ginie po drodze.

Lepiej działa sekwencja: najpierw struktura sekcji, potem treść, na końcu kolory i typografia. Każda runda kończy się wersją, którą możesz ocenić, zanim ruszysz dalej. Jak coś pójdzie nie tak, cofasz się o jeden krok, a nie o cały projekt.

Krok 3: wyeksportuj to, czego naprawdę potrzebujesz

Tu robi się ciekawie, bo opcji jest sporo. Możesz pobrać samodzielny plik HTML, wyeksportować do PDF, do PPTX (przydatne przy deckach), wysłać projekt do Canvy albo ściągnąć całość jako ZIP z plikami.

Najmocniejsza opcja dla programisty: przekazanie projektu do Claude Code. Dostajesz wtedy kod w swoim repozytorium i pracujesz na nim normalnie, zamiast przepisywać ręcznie to, co widziałeś w przeglądarce. Ten jeden przycisk robi największą różnicę w tym, czy narzędzie zostanie zabawką, czy wejdzie do procesu.

Krok 4: zapisz to, co zadziałało

Prompty, które dały dobry efekt, warto trzymać w jednym pliku. Po kilku projektach zauważysz, że wracasz do tych samych sformułowań i że masz swój prywatny szablon briefu. U mnie to jest zwykła notatka w Obsidianie z pięcioma akapitami do skopiowania.

Co się dzieje, gdy podłączysz swój design system

Ta funkcja jest powodem, dla którego branża zrobiła wokół Claude Design tyle hałasu. Narzędzie potrafi przeczytać Twój kod albo plik Figmy, wyciągnąć z nich zasady wizualne (kolory, odstępy, fonty, style przycisków) i zastosować je do nowego projektu.

W praktyce oznacza to, że nowy ekran nie wygląda jak obcy element doklejony do aplikacji. Ma te same kolory, te same zaokrąglenia, te same odstępy co reszta systemu. Dla firmy, która ma już produkt i chce dorobić kolejny moduł, to oszczędza rundę poprawek z projektantem.

Jeśli nie masz żadnego design systemu, nic nie tracisz. Claude Design zaproponuje własny zestaw i będzie się go trzymał w obrębie projektu. Gorzej wygląda to przy wielu projektach obok siebie, bo spójność między nimi musisz pilnować sam.

Czego Claude Design nie zrobi

Research preview to nie marketingowa etykietka. Lista braków jest długa i lepiej ją poznać przed, a nie po.

Nie ma backendu. Dostajesz wyłącznie warstwę wizualną. Żadnej bazy danych, logowania, zapisu formularza. Prototyp wygląda jak działająca aplikacja, ale pod spodem jest pusty. To akurat sensowny wybór produktowy, tylko trzeba o nim uprzedzić klienta, zanim zapyta „to kiedy wchodzimy na produkcję".

Nie ma eksportu do Figmy z edytowalnymi warstwami. Możesz wyciągnąć HTML i PDF, ale projektant nie dostanie pliku, w którym pociągnie za komponenty. Istnieją obejścia przez zewnętrzne narzędzia, żadne nie jest bezbolesne. Jeśli pracujesz z zespołem projektowym siedzącym w Figmie, ten punkt potrafi przekreślić cały pomysł.

Nie ma współpracy w czasie rzeczywistym. Dwie osoby nie klikną w ten sam projekt jednocześnie. Nie ma też publicznego linku do udostępnienia, więc pokazanie efektu komuś z zewnątrz kończy się wysyłką pliku albo screen sharingiem.

Nie ma nieskończonego płótna. Pracujesz nad projektem, nie nad przestrzenią, w której leży czterdzieści wariantów obok siebie. Kto lubi rozkładać pomysły na stole i porównywać wzrokiem, poczuje ciasnotę.

Nie generuje fotorealistycznych zdjęć. Grafiki produktowe, zdjęcia zespołu, wizualizacje trzeba dostarczyć z zewnątrz albo wygenerować w innym narzędziu.

Animacje zostają w przeglądarce. Claude Design potrafi zrobić animowane przejścia, ale nie wyeksportujesz ich jako pliku wideo. Zostaje nagrywanie ekranu, co brzmi absurdalnie w narzędziu za kilkadziesiąt dolarów miesięcznie.

Dochodzi jeszcze kwestia limitów. Na planie Pro sesja z intensywnym iterowaniem potrafi zjeść dzienny limit w pół godziny, bo każda poprawka to generowanie kodu od nowa. Jeśli planujesz pracować tak codziennie, licz się z planem Max.

Claude Design, Lovable, Figma - kiedy który

Sam prototypuję dla klientów i korzystam z Lovable, więc porównanie robi mi się naturalnie.

Lovable robi całą aplikację: frontend, backend, baza, logowanie, deploy. Efektem jest coś, co realnie działa i co możesz oddać ludziom do przetestowania na prawdziwych danych. Cena tego jest taka, że wchodzisz w konkretny stack i sprzątasz po nim później.

Claude Design zatrzymuje się na warstwie wizualnej, za to robi ją szybciej i ładniej. Do momentu, w którym decydujesz „czy w ogóle budujemy", to wystarczy w zupełności. Zbudowanie działającego backendu tylko po to, żeby ktoś powiedział „a jednak nie tędy", jest marnowaniem czasu.

Figma zostaje tam, gdzie w grze jest zespół projektowy, biblioteka komponentów i praca na miesiące. Nazywanie Claude Design zabójcą Figmy jest na razie mocno na wyrost, bo brak edytowalnego eksportu odcina go od całego świata, w którym Figma jest standardem.

Mój podział wygląda tak: Claude Design na pierwszą rozmowę i decyzję o kierunku, Lovable na działający prototyp do testów, Figma dopiero wtedy, gdy projekt dojrzał na tyle, że opłaca się w niego inwestować godziny projektanta.

Gdzie to naprawdę pomaga w moim procesie

Najczęstszy scenariusz w mojej pracy: ktoś ma pomysł na wewnętrzne narzędzie i chce wiedzieć, czy warto. Wcześniej ten etap wyglądał tak, że rozmawialiśmy o wymaganiach, ja robiłem szkice, wracaliśmy do rozmowy, powstawał dokument, a decyzja i tak zapadała na wyczucie.

Teraz na tej samej rozmowie otwieram Claude Design, opisuję na głos to, o czym mówimy, i po chwili mamy na ekranie coś, na co obie strony patrzą. Dyskusja przestaje być abstrakcyjna. Zamiast „chcemy widzieć status zlecenia" pada „ten status ma być na górze, a nie w tabelce, bo brygadzista patrzy na to z telefonu w kurzu".

Drugie zastosowanie to materiały, które trzeba zrobić szybko i mają nie wyglądać jak zrobione w Wordzie. One-pager z ofertą, prosty deck, podsumowanie projektu na spotkanie zarządu. Zwykle zajmowało mi to wieczór, teraz mieści się w kwadransie plus poprawki.

Czego bym w tym nie robił: finalnego produktu. Kod z takiego narzędzia jest dobry na demo, nie na system, który ma żyć trzy lata i być rozwijany przez zespół.