Landing z Claude Design, który mierzy popyt na plany

Landing BusiKM powstał w kilka godzin. Najwięcej czasu nie zajęło pisanie kodu, bo kodu prawie nie pisałem. Zajęły go makiety w wersji na komputer i na telefon, integracja formularza z Firebase i jedna decyzja biznesowa: formularz zapisu miał nam mówić, przy którym planie z cennika ktoś kliknął, zanim zostawił adres. W tym poście opisuję, jak wygląda taki proces, gdy wygląd robi Claude Design, kod pisze Claude Code, a moja rola to treść, zasady i decyzje.

Trzy źródła, każde od czegoś innego#

Cały proces opiera się na jednym podziale, zapisanym na początku dokumentacji wdrożenia: dokumentacja trzyma treść, Claude Design robi wygląd, a katalog landing/ to kod. Każda z tych rzeczy ma jedno źródło i wiadomo, gdzie ją poprawić.

Najważniejsza zasada brzmi: jeśli w Claude Design zmienię jakieś zdanie, wraca ono najpierw do dokumentacji, a dopiero potem trafia do kodu. Bez tego po trzech iteracjach nikt nie wie, która wersja treści jest prawdziwa: ta z projektu, ta z kodu czy ta z pliku. Druga zasada: nie implementujemy strony przed akceptacją projektu. Poprawka w projekcie kosztuje minuty, ta sama poprawka w kodzie godziny.

Prompt, który jest specyfikacją#

Prompt do strony głównej ma 383 linie i bardziej przypomina specyfikację niż prośbę o ładną stronę. Opisuje, kto będzie stronę czytał, jaka jest główna obietnica, jaki ma być ton, system wizualny i treść każdej sekcji z gotowymi nagłówkami. Najwięcej uczy jednak rozdział „Czego NIE robić”:

• nie wymyślaj dowodu społecznego, bo produkt nie ma jeszcze klientów: zero logotypów, opinii i liczb w rodzaju „500 zadowolonych przewoźników”,
• nie używaj zdjęć stockowych, zamiast nich makiety interfejsu i typografia,
• nie strasz terminem ustawowym, tylko podaj fakt i datę,
• nie pisz językiem korporacyjnym: „platforma”, „rozwiązanie”, „ekosystem” i „kompleksowy” są zakazane.

Na końcu jest kryterium sukcesu, które przydaje się przy każdej decyzji o wyglądzie: właściciel firmy transportowej przewija stronę na telefonie między jednym telefonem od klienta a drugim i po dziesięciu sekundach wie, że to zbiera dane z jego kierowców i zamyka mu miesiąc. Jeśli musi czytać, żeby to zrozumieć, projekt jest za gęsty.

Prompt wymaga trzech artboardów: całej strony w szerokości 1440 px, całej strony na telefonie w 390 px i arkusza systemu z kolorami, typografią i komponentami. Ten trzeci jest podkładem do implementacji. Przy stronie głównej dochodzą jeszcze stany nawigacji, bo bez nich trzeba by zgadywać, jak wygląda pasek po przewinięciu i rozwinięte menu.

Iteracje w Claude Design działają tylko z konkretnymi uwagami. „Sekcja 7 jest za ciasna, więcej powietrza nad nagłówkiem” działa. „Zrób ładniej” nie działa.

Z projektu do kodu#

Gotowy projekt eksportuję do repozytorium, do katalogu design/ z numerem strony. Claude Code porównuje go z dokumentacją, wypisuje każdą rozbieżność w treści, przenosi tokeny do CSS, składa sekcje na komponenty i podpina animacje. Ja dostaję gałąź z kodem i krótką listę rozbieżności do decyzji. W miejscach, gdzie powinien być prawdziwy ekran aplikacji, a go jeszcze nie ma, zostaje ramka z nazwą pliku. Podmiana makiety na zrzut to wrzucenie jednego obrazu.

Podstrony szły falami: dwadzieścia cztery prompty w czterech falach. Fala nie czekała na poprzednią. Kiedy Claude Code implementował pierwszą, ja projektowałem drugą. Każdy PR przechodzi przez Lighthouse w CI, na komputerze i na telefonie. Ta strona, movgranto.com, powstała tak samo: z projektu w Claude Design, którego eksport leży w repozytorium jako źródło prawdy dla wyglądu i ruchu.

Formularz, który mówi, który plan ktoś oglądał#

Ani aplikacja, ani demo nie były jeszcze publiczne, więc landing zamiast przycisków prowadzących donikąd ma dwie listy wczesnego dostępu. Ktoś, kto kliknął „Zobacz demo”, trafia na inną listę niż ktoś, kto kliknął „Zaloguj się”, bo ten drugi szukał własnego konta i jest bliżej decyzji. Pierwsza wiadomość do tych dwóch grup nie powinna brzmieć tak samo.

Pierwsza wersja gubiła jednak najcenniejszą informację. Ktoś, kto kliknął „Wypróbuj 14 dni” przy planie Firma z rozliczeniem rocznym, powiedział o sobie więcej niż samym adresem e-mail, a przycisk prowadził na stronę zapisu bez śladu po tym, co oglądał. Zgłoszenia w skrzynce były nie do odróżnienia.

Teraz plan i okres jadą w adresie strony, a po zapisie trafiają do bazy, do powiadomienia mailowego i do listy mailingowej. Plan jest w temacie maila, więc zgłoszenie da się ocenić bez otwierania. Kalkulator w cenniku działa tak samo i przekazuje plan, do którego doszedł suwak. Dzięki temu widzimy, który plan bardziej przyciąga ludzi, zanim w produkcie w ogóle są płatności.

Dwie decyzje w tym mechanizmie były ważniejsze od samego kodu. Pierwsza: wybór jest pokazany nad formularzem, z odnośnikiem „zmień”, a nie przekazywany po cichu. Człowiek widzi, że jego wybór nie przepadł, i może go poprawić, a my nie zbieramy w tle niczego, czego nie pokazalibyśmy mu wprost. Druga: to deklaracja zainteresowania, a nie zamówienie. Nikt jeszcze nie płaci, więc pola są opcjonalne na całej drodze, bo na stronę zapisu wchodzi się też prosto z wyszukiwarki.

Reguły Firestore pilnują, żeby te pola nie stały się miejscem na dowolny tekst z zewnątrz:

// Plan and billing period from the pricing page. Optional, because people
// also land on the sign-up page directly. If present: both at once, known values only.
function wyborZCennika(d) {
  return ('plan' in d) == ('okres' in d)
    && (!('plan' in d)
        || (d.plan in ['start', 'firma']
            && d.okres in ['miesiecznie', 'rocznie']));
}

Trasa API, przez którą idzie zapis, powtarza tę samą walidację, bo jest publiczna i nie może zakładać, że wywołał ją nasz formularz.

Co z tego zostaje#

Kilka godzin na landing to nie zasługa tego, że AI szybko pisze kod. To zasługa podziału: treść w jednym miejscu, wygląd zaakceptowany przed kodem i jasna lista rozbieżności do decyzji. Najwięcej mojej pracy poszło w rzeczy, których żadne narzędzie nie zrobi za mnie: co strona ma obiecywać, czego ma nie udawać i czego ma się od odwiedzających dowiedzieć.

Dlatego zanim zaprojektujesz landing, zdecyduj, co ma mierzyć. U nas była to jedna informacja: który plan ktoś oglądał przed zapisem. Czternastodniowy okres próbny z cennika ma też swoje zakończenie w kodzie, opisałem je w poście o trybie tylko do odczytu. Jeśli budujesz landing dla swojego SaaS i chcesz go zrobić w ten sposób, napisz do mnie.