Gotowe na demo a gotowe na produkcję: kiedy aplikacja zbudowana z AI jest naprawdę gotowa na prawdziwych użytkowników
Większość aplikacji zbudowanych z AI wygląda świetnie na demie i pęka przy trzecim prawdziwym użytkowniku. Oto jak rozpoznać, po której stronie jesteś, i jak zamknąć tę lukę bez programisty.
Z każdym kreatorem aplikacji z AI przychodzi moment, gdy to, co zbudowałeś, zaczyna wyglądać prawdziwie. Strona się wczytuje, przyciski działają, formularz przyjmuje dane, a dane pokazują się tam, gdzie powinny. Klikasz dookoła i czujesz się jak founder. To dobre uczucie. To też miejsce, gdzie wielu ludzi utyka — bo przepaść między „to działa, gdy robię demo” a „to działa, gdy używa tego obcy” jest większa, niż wygląda, a ta przepaść nie pokazuje się w panelu podglądu kreatora aplikacji z AI.
Ten wpis jest o tym, jak celowo zamknąć tę lukę. Nie musisz stać się inżynierem, by to zrobić. Musisz wiedzieć, czego testować, w jakiej kolejności i kiedy przestać nazywać coś prototypem.
Co naprawdę znaczy „gotowe na demo”
Gotowa na demo aplikacja zbudowana z AI robi to, co chciałeś, by robiła, na ścieżce, na której ją testowałeś, z danymi, które wyglądają jak dane, które wklejałeś w prompty. Logowanie działa. Panel się wczytuje. To, co chciałeś pokazać współzałożycielowi, jest na ekranie.
Gotowe na demo to nie nic. Cztery miesiące temu to, co zbudowałeś, było zleceniem dla freelancera i sześciotygodniowym harmonogramem. Ale to też wersja Twojej aplikacji, która była przetestowana przez Ciebie, samego, na szczęśliwej ścieżce. Prawdziwi użytkownicy nie zostają na szczęśliwej ścieżce.
Wklejają adres mailowy z zabłąkaną spacją na końcu. Używają Safari na iPadzie w trybie poziomym. Wchodzą na danych mobilnych i pozwalają stronie wisieć w połowie wczytanej przez trzydzieści sekund, zanim klikną przycisk. Oczekują, że „wstecz” zadziała, i oczekują, że odświeżenie nie zgubi niczego, co wpisali.
Powodem, dla którego dema są mylące, nie jest to, że AI zbudowało coś fałszywego. To to, że osoba prowadząca demo wie, gdzie pochowane są trupy. Instynktownie klikasz przyciski, które działają. Prawdziwy użytkownik klika te, o których zapomniałeś, że istnieją.
Pięć rzeczy, które pękają jako pierwsze
U ludzi, których obserwowałem przechodzących od demo do startu z kreatorami aplikacji z AI, te same pięć rzeczy zwykle pęka jako pierwsze pod prawdziwymi użytkownikami. Przejście przez nie świadomie to najszybszy sposób, by zbliżyć się do gotowości na produkcję.
1. Pusty stan. Twój panel wygląda świetnie z trzema projektami, bo używałeś trzech projektów podczas budowania. Nowy użytkownik się rejestruje, ląduje na panelu z zerem czegokolwiek i widzi pusty szary prostokąt. Rozwiązaniem jest jeden prompt: „Gdy użytkownik ma zero projektów, pokaż przyjazny komunikat wyjaśniający, co zrobić dalej, i przycisk do utworzenia pierwszego”. Nudne, dziesięć sekund pracy, robi różnicę między „to zepsute” a „to pomocne”.
2. Stan błędu. Spróbuj tego teraz: wyłącz wifi i poklikaj po swojej aplikacji. Wpisz celowo złe hasło. Prześlij formularz z pustym polem mailowym. Jeśli Twoja aplikacja się zawiesza, zamarza albo pokazuje surowy błąd w stylu 500 Internal Server Error, masz problem ze stanem błędu. Kreator AI potrafi to naprawić, ale musisz zapytać: „Co się dzieje, gdy wywołanie API zawiedzie? Gdy użytkownik wpisze złe dane? Gdy jest offline?”. To trzy osobne prompty i pokrywają większość sposobów, w jakie prawdziwi użytkownicy wpadają w kłopoty.
3. Widok mobilny. Mniej więcej połowa Twoich pierwszych użytkowników — może więcej, zależnie od tego, czym jest Twoja aplikacja — otworzy ją na telefonie. Kreatory AI dobrze radzą sobie z responsywnym projektem dla standardowych układów i źle dla niestandardowych, zwłaszcza czegokolwiek z paskiem bocznym, przyklejonym modalem albo złożonym formularzem. Otwórz aplikację na telefonie, drugim kciukiem, tak jak używa jej prawdziwa osoba. Jeśli cokolwiek wychodzi poza ekran, cokolwiek jest za małe, by dokładnie kliknąć, albo cokolwiek zasłania klawiaturę, gdy próbujesz pisać, to do poprawy. Zwykle jeden prompt: „Spraw, by ta strona wyglądała dobrze na ekranie telefonu, zwłaszcza [zepsuta rzecz] — zostaw wersję na komputer bez zmian”.
4. Problem »drugiego użytkownika«. Oto podstępna rzecz. Wiele aplikacji zbudowanych z AI zakłada jednego użytkownika. Dane, które tworzysz, zostają w aplikacji. Potem rejestruje się drugi użytkownik i albo widzi Twoje dane, albo żadnych danych w ogóle i jest bardzo zdezorientowany. To kwestia uwierzytelniania i zakresowania danych i warto poprosić AI, by wyjaśniło, jak przechowuje dane użytkowników, zanim wystartujesz. Właściwe sformułowanie: „Wyjaśnij, jak rozdzielone są dane użytkowników. Jeśli zarejestrują się dwie osoby, czy jedna może zobaczyć dane drugiej?”. Odpowiedź jest testem.
5. Przycisk »zmieniłem zdanie«. Prawdziwi użytkownicy nieustannie cofają rzeczy. Usuwają konto, które właśnie utworzyli, bo wpisali zły mail. Wypisują się dwie minuty po zapisaniu. Chcą edytować projekt zrobiony wczoraj, bo tytuł ma literówkę. Kreatory aplikacji z AI, zostawione same sobie, budują ścieżkę tworzenia i pomijają ścieżkę edycji-lub-usunięcia — bo demo zawsze prosiło je tylko o tworzenie rzeczy. Jeśli wystartujesz z tą luką, pierwszych trzech użytkowników napisze do Ciebie maila w ciągu godziny, a mail zacznie się od słowa „Jak”. Przejdź przez aplikację i pytaj dla każdego ekranu: „Czy użytkownik może cofnąć to, co właśnie zrobił, albo zmienić to później?”. Gdziekolwiek odpowiedź brzmi nie, to funkcja, której potrzebujesz przed startem.
Czego „gotowe na produkcję” nie znaczy
Gotowe na produkcję dla aplikacji zbudowanej z AI to nie to samo, co gotowe na produkcję w banku. Nie potrzebujesz 99,99% dostępności. Nie potrzebujesz testu obciążeniowego. Nie potrzebujesz runbooka ani dyżuru pod telefonem. Nie jesteś Stripe, jesteś małą rzeczą obsługującą prawdziwych ludzi.
Czego potrzebujesz, to build, który nie skompromituje Cię przed obcym. To osiągalne w skupione popołudnie albo dwa, gdy wiesz, czego szukać. Pięć punktów powyżej to większość tego. Reszta to uczynienie aplikacji czytelną — jasny tekst na każdym przycisku, przewidywalne zachowanie po kliknięciu, żadnych stron, które kończą się ślepo na strzałce wstecz, która nie działa.
Największy skok od gotowego na demo do gotowego na produkcję nie jest w kodzie. Jest w Twojej gotowości, by używać własnej aplikacji tak, jak zrobiłby to obcy. Sztuczka, którą polecam ludziom: podaj telefon znajomemu w kawiarni i poproś, by zrobił główną rzecz, którą robi Twoja aplikacja, bez wyjaśniania mu jej. Nie podpowiadaj. Obserwuj jego kciuk. Pierwsze miejsce, gdzie zatrzyma się na dłużej niż trzy sekundy, to najważniejsza rzecz, którą możesz naprawić w tym tygodniu. Drugie i trzecie miejsce to zwykle szybkie dorobienia.
Mała lista kontrolna przed startem
Zanim wypuścisz dla pierwszych dziesięciu prawdziwych użytkowników, przejdź tę listę. Nic z niej nie wymaga pisania kodu. Wszystko to prompt do kreatora aplikacji z AI albo ręczne przeklikanie.
- Zarejestrowałem się jako zupełnie nowy użytkownik z okna prywatnego przeglądania, od początku do końca, bez skrótów.
- Użyłem aplikacji na telefonie.
- Próbowałem zepsuć formularze — puste pola, dziwne dane, bardzo długie dane.
- Zapytałem kreatora AI, jak rozdzielone są dane użytkowników, a odpowiedź ma sens.
- Mam sposób, by skontaktować się z użytkownikami, jeśli coś pójdzie nie tak (pole mailowe, link do opinii, cokolwiek).
- Mam sposób, by wiedzieć, gdy coś poszło nie tak — kreator AI zwykle oferuje podstawowe logowanie błędów; włącz je.
- Pusty stan każdej strony mówi użytkownikowi, co zrobić dalej.
- Każda akcja, która coś tworzy, ma sposób na cofnięcie, edycję albo usunięcie.
Jeśli przejdziesz tę listę i kilku pozycji brakuje, to jutrzejsze prompty. Jeśli przejdziesz i brakuje większości, aplikacja jeszcze nie jest gotowa — a to użyteczna rzecz do wiedzenia, zanim wyślesz komukolwiek link.
Szczery złoty środek
Większość aplikacji zbudowanych z AI przez jakiś czas żyje w strefie pośredniej. Działają, w większości. Mają kilka chropowatych krawędzi. Dobrze obsługują małą grupę użytkowników i pękłyby na skalę. To dobre miejsce dla startupu albo narzędzia wewnętrznego, by żyć w nim miesiącami. Błędem jest traktowanie gotowej na demo aplikacji, jakby już była za tą strefą. Innym błędem jest traktowanie gotowości na produkcję jako perfekcjonistycznego standardu, którego nigdy nie osiągniesz.
Właściwe pytanie brzmi: czy czułbym się komfortowo, gdyby znajomy tego użył i zdał relację? Jeśli tak, jesteś wystarczająco gotowy na produkcję jak na swój etap. Jeśli wolałbyś popędzić, by coś naprawić, zanim powie Ci, co myślał, zapisz tę rzecz i napraw ją najpierw.
Nie musisz być gotowy na dziesięć tysięcy użytkowników. Musisz być gotowy na następnych dziesięciu. To prawdziwa, skończona lista poprawek, a Twój kreator aplikacji z AI może pomóc Ci zrobić większość z nich w jedno popołudnie.
Jeśli wypuściłeś aplikację zbudowaną z AI dla prawdziwych użytkowników, co było pierwszą rzeczą, która się zepsuła, a której nie przewidziałeś? To zwykle ciekawsze pytanie niż „czy moja jest gotowa” — bo niespodzianka to właściwy sygnał.