Wzorce pustych stanów, które zmniejszają niejasności i prowadzą użytkowników do następnego kroku konfiguracji — gotowe struktury copy, układu i list kontrolnych do szybkiego zastosowania.
Pusty ekran nie jest neutralny. Tworzy przerwę, podczas której ludzie zaczynają się domyślać, co zrobić, czy coś przeoczyli, albo czy produkt w ogóle działa. Podczas konfiguracji ta przerwa kosztuje dużo — zmienia „rozpoczynam” w „wrócę później”.
Pusty stan to to, co użytkownik widzi, kiedy nie ma jeszcze nic do pokazania, bo nic nie stworzył, nie zaimportował ani nie podłączył. To nie jest ekran ładowania, komunikat o błędzie ani ostrzeżenie o uprawnieniach. To moment tuż przed wartością, kiedy aplikacja musi pomóc użytkownikowi dojść do pierwszego sensownego rezultatu.
Dobre pusty stan ma jedno zadanie: przesunąć użytkownika do następnej udanej akcji przy jak najmniejszym wysiłku poznawczym. „Udana” ma znaczenie. Następny krok powinien dać prawdziwy wynik (pierwszy projekt, podłączone źródło danych, pierwszy utworzony element), a nie prowadzić do bezowocnego formularza czy mglistych tur produktu.
Takie momenty pojawiają się częściej, niż zespoły spodziewają się: pierwsze logowanie po rejestracji, zupełnie nowe workspace, zakładka funkcji bez elementów (projekty, klienci, pliki) albo ścieżka konfiguracji, gdzie import został pominięty i nic nie istnieje.
Kiedy pusty stan robi swoje, szybko odpowiada na trzy pytania:
Przykład: w Koder.ai nowy użytkownik może otworzyć świeży workspace i nie zobaczyć jeszcze żadnych aplikacji. Silny pusty stan mówi jasno, że nic nie zostało stworzone, oferuje jedną oczywistą następną akcję, np. „Utwórz swoją pierwszą aplikację”, i dodaje małą linijkę bezpieczeństwa (np. że eksport kodu źródłowego i snapshoty będą dostępne po rozpoczęciu). Celem jest przekształcenie „nic tu nie ma” w „mogę osiągnąć pierwszy działający rezultat”.
Dla nowego użytkownika pusty ekran może sprawiać wrażenie, że aplikacja stanęła w miejscu albo że oni zrobili coś źle. Umysł szybko wypełnia lukę i zwykle nie idzie to na twoją korzyść.
Większość osób zadaje w duchu ten sam zestaw pytań:
Emocje stojące za tymi pytaniami napędzają zachowanie. Niepewność sprawia, że ludzie wahają się. Strach przed zrobieniem czegoś źle powoduje, że omijają główny przycisk. Niecierpliwość sprawia, że zamykają aplikację, jeśli jasny następny krok nie pojawi się w kilka sekund.
Puste stany dla nowych użytkowników i dla zaawansowanych użytkowników rozwiązują różne problemy. Nowi potrzebują kontekstu i poczucia bezpieczeństwa, bo nie znają jeszcze twojego słownictwa. Powracający chcą szybkości: szybkiego sposobu na utworzenie elementu, import danych lub powtórzenie znanej akcji.
Puste stany w konfiguracji różnią się też od stanów błędu i ładowania. Ładowanie mówi „poczekaj, coś się dzieje”. Błąd mówi „coś się nie powiodło, oto dlaczego”. Konfiguracja mówi „tutaj nic jeszcze nie ma i to jest normalne. Oto jak zacząć”.
Konkretne przykład: jeśli ktoś otwiera nowy workspace w Koder.ai i widzi pustą stronę Projekty, nie myśli o funkcjach. Myśli: „Zacznę od promptu, zaimportuję kod czy wybiorę szablon, i czy to coś zepsuje?” Twój pusty stan powinien odpowiedzieć na to bez odsyłania do dokumentacji.
Dobry pusty stan nie powinien wyglądać na pusty. Ma pełnić funkcję drogowskazu: „Oto, do czego to służy, i tu jest następne kliknięcie”.
Struktura działająca w większości przepływów konfiguracji składa się z trzech części:
Trzymaj wyjaśnienie krótkie. Jeśli potrzebujesz akapitu, żeby wytłumaczyć ekran, prosisz użytkownika o zbyt dużo myślenia. Celuj w 1–2 krótkie zdania z prostymi słowami jak „Dodaj swój pierwszy projekt” lub „Utwórz swoje pierwsze workspace”.
Następnie spraw, by następny krok był oczywisty dzięki pojedynczemu przyciskowi głównemu. Jeśli pokażesz trzy równe przyciski, każesz użytkownikowi wybrać ścieżkę zanim zrozumie stronę. Jeśli musisz zaoferować alternatywy (import, szablon, pomiń), utrzymuj je wizualnie spokojniejsze niż główna akcja.
Użyj linii zapewniającej, aby usunąć typowe obawy: boję się popełnić błąd, stracę czas lub potrzebne są umiejętności techniczne. Małe wskazówki o tym, co się stanie dalej i co można cofnąć, działają lepiej niż długie wyjaśnienia.
Przykładowe copy dla pierwszego ekranu „Projekty” dla nowego użytkownika:
Tytuł: Rozpocznij swój pierwszy projekt
Wyjaśnienie: Projekty przechowują konfigurację aplikacji i wydania.
Główna akcja: Utwórz projekt
Zapewnienie: Zajmie około 2 minut. Możesz zmienić nazwę w dowolnym momencie.
Jeśli produkt obsługuje wiele sposobów startu (budowanie z chat, import, lub szablon, jak narzędzia typu Koder.ai), trzymaj „Utwórz” jako domyślną opcję i umieść „Import” oraz „Użyj szablonu” jako akcje wtórne poniżej.
Puste stany zawodzą, gdy copy mówi o funkcjach zamiast o tym, co użytkownik zyskuje. Twoje słowa powinny szybko odpowiadać: czym jest ten ekran? Dlaczego warto coś tutaj zrobić? Co zrobić teraz?
Prosty wzór nagłówka to Rezultat + obiekt. Nazwij rezultat i rzecz, którą użytkownik stworzy, a nie wewnętrzną nazwę funkcji.
W tekście opisowym użyj czym jest + dlaczego to ważne w jednym lub dwóch zdaniach:
„Klienci to osoby, którym sprzedajesz. Dodaj jednego teraz, żeby wysłać fakturę i śledzić płatności.”
CTA powinny zaczynać się od jasnego czasownika i zawierać konkretny rzeczownik. Unikaj niejasnych przycisków typu „Rozpocznij”, gdy istnieje więcej niż jedna ścieżka.
Dodaj mikrotekst obok wyboru, który wydaje się ryzykowny. Małe zapewnienia często działają lepiej niż długie wyjaśnienia:
Jeśli produkt generuje dla użytkownika wynik (jak Koder.ai), ustaw oczekiwania, aby użytkownicy wiedzieli, że nie zobowiązują się do wersji finalnej: „Stworzymy pierwszy szkic. Będziesz mógł przejrzeć i edytować przed wdrożeniem.”
Dobry pusty stan powinien czytać się jak drogowskaz, nie plakat. Układ musi mieć jasny porządek, żeby użytkownik mógł raz spojrzeć, zrozumieć i zadziałać.
Użyj prostej hierarchii zgodnej ze sposobem, w jaki wzrok skanuje stronę: nagłówek, jedno krótkie zdanie, przycisk CTA główny, a potem cichsza akcja wtórna (import, szablon, pomiń).
Trzymaj przycisk główny blisko komunikatu. Jeśli użytkownik musi czytać, przewijać, a potem decydować, często rezygnuje. Popularny wzorzec to zwarty blok (nagłówek + opis + CTA), z większą ilością przestrzeni między tym blokiem a resztą interfejsu (nawigacja, stopka, panele boczne).
Ikony i niewielkie ilustracje pomagają w skanowaniu, ale tylko jeśli dodają znaczenie. Ikona folderu obok „Brak projektów” jest pomocna. Losowy maskotka zwykle nie jest. Jeśli używasz ilustracji, trzymaj ją małą i umieść nad nagłówkiem, żeby nie konkurowała z CTA.
Jednym z najsilniejszych wzorców jest pokazanie mini-podglądu sukcesu: przykładowa karta, pojedynczy demo-wiersz w tabeli albo przygaszony przykład kafelki. W narzędziu takim jak Koder.ai ekran pustych „Aplikacji” mógłby pokazać jedną przykładową kafelkę aplikacji (nazwa, status, ostatnia aktualizacja), żeby użytkownik od razu zrozumiał, co stworzy.
Kiedy ktoś trafia na pusty ekran, zazwyczaj chce jednej z trzech rzeczy: zacząć od zera, wprowadzić istniejące dane lub szybko wystartować z gotowego startera. Dobre pusty stany wyjaśniają te ścieżki jasno, bez zmuszania do wnikliwej analizy produktu.
Prowadź z „Utwórz”, gdy pierwszym realnym zwycięstwem jest utworzenie nowej rzeczy: projektu, workspace, strony czy pierwszego rekordu. To działa najlepiej, gdy użytkownik może zakończyć to szybko, a akcja jest odwracalna.
Jeśli tworzenie zajmuje więcej czasu, podziel je na mniejsze kroki (np. „Utwórz szkic”), żeby mogli ruszyć dalej bez poczucia zamknięcia.
Prowadź z „Importuj”, gdy większość nowych użytkowników przychodzi z istniejącego systemu, pliku lub konta do podłączenia. Pusty stan powinien opisać, co import obsługuje i co użytkownik zyska po nim (np. mapowanie pól i utworzone elementy).
Praktyczny sposób wyboru CTA głównego to użycie kontekstu. Jeśli użytkownik przechodzi z treści migracyjnej, podkreśl Import. Jeśli kliknął przycisk „nowy projekt”, wyróżnij Utwórz. Jeśli konfiguracja jest złożona, podświetl Szablon.
Prowadź z szablonami, gdy produkt ma typowe punkty startowe, a użytkownicy chcą raczej adaptować niż projektować. Nazwij szablony według rezultatu („Lejek sprzedażowy”, „Tygodniowy planer”), nie funkcji.
Opcja „Wypróbuj z przykładowymi danymi” zmniejsza obawę. Wyraźnie zaznacz, że można to usunąć. Dla chat-first buildera jak Koder.ai przykładowy projekt pokaże kształt działającej aplikacji zanim użytkownik napisze własny prompt.
Puste ekrany nie są neutralne. Najlepsze z nich sprawiają, że następna udana akcja wydaje się oczywista, bezpieczna i szybka.
Przykład: jeśli ktoś otwiera nowy CRM i widzi pustą zakładkę „Kontakty”, najszybszym zwycięstwem będzie „Dodaj pierwszego kontaktu”. Poproś tylko o imię i email, jako awaryjne daj „Importuj CSV” i zapewnij, że pola można aktualizować później.
Większość „zablokowanych” pustych stanów zawodzi z jednego powodu: sprawiają, że następny krok wydaje się ryzykowny lub niejasny.
Jeśli pokażesz trzy przyciski wyglądające równie ważnie, użytkownicy się zatrzymają. Wybierz jedną akcję główną i jedną wtórną. Resztę ukryj za cichszą linią „Więcej opcji”.
„Potężne dashboardy, elastyczne role, zaawansowane ustawienia” nie mówi ludziom, co zrobić teraz. Zastąp to opisem następnego rezultatu, jaki uzyskają po kliknięciu.
Przykłady:
Długie formularze w pustym stanie wyglądają jak zobowiązanie. Jeśli potrzebujesz dodatkowych danych, zdobądź je później. Zacznij od najmniejszego kroku, który daje widoczny rezultat.
Zamiast prosić o imię, wielkość firmy, rolę i cele zanim cokolwiek załaduje się, poproś tylko o „Nazwę projektu” i resztę zrób opcjonalną po utworzeniu pierwszego ekranu.
Humor jest w porządku, ale nie tam, gdzie użytkownik potrzebuje jasności. „Nic tu nie ma” marnuje chwilę. Powiedz dokładnie, co się stanie po kliknięciu i czego nie robi ta akcja.
Niektórzy użytkownicy nie mogą stworzyć od zera. Zapewnij realną ścieżkę zapasową: import, szablon albo dane przykładowe. Na przykład, jeśli ktoś w Koder.ai nie ma gotowego pomysłu, „Rozpocznij od przykładowej aplikacji” może zaprowadzić go do działającego ekranu bez pisania pełnej specyfikacji.
Nowy użytkownik powinien zrozumieć, co to za ekran, dlaczego to ważne i co zrobić następnie w około pięć sekund.
Uspokojenie zamienia wahanie w działanie. Dodaj krótką linię przy CTA, która zmniejszy obawy, np. „Możesz to później zmienić” albo „Nic nie zostanie opublikowane, dopóki nie potwierdzisz.” Trzymaj to spokojne i konkretne.
Prosty test: poproś kolegę, żeby spojrzał na ekran przez pięć sekund, a potem powiedział, co myśli, że się stanie po kliknięciu głównego przycisku. Jeśli nie potrafi odpowiedzieć, zacieśnij copy lub hierarchię.
Jeśli budujesz przepłydy konfiguracji w builderze zorientowanym na chat, takim jak Koder.ai, ta sama lista kontrolna się sprawdza. Pusty stan powinien zapraszać do jednej udanej następnej akcji: zacznij od szablonu, zaimportuj dane albo wygeneruj pierwszą działającą wersję, którą można bezpiecznie edytować.
Samozatrudniony założyciel rejestruje się w Koder.ai i otwiera zupełnie nowy workspace. Trafia na stronę Projektów z zerem aplikacji i nie ma pojęcia, jak wygląda „dobry” punkt startowy.
Zamiast pustej tabeli, pusty stan pokazuje krótką obietnicę, jasny następny krok i małą notkę bezpieczeństwa. Oto jeden przykład copy i CTA (czas to tylko przybliżenie, które warto zweryfikować):
Your workspace is empty.
Create your first app in 5 minutes. Start with a template or describe what you want in plain English.
[Create your first app]
Secondary: Import existing code | Browse templates
Note: You can export the source code anytime.
Po kliknięciu Create your first app drugi ekran zadaje jedno proste pytanie: „Co budujesz?” z jednym polem i 2 przykładowymi promptami (np. „CRM dla małej agencji” lub „Landing page z formularzem zapisu”). Trzymaj ścieżkę wąską: jedno oczywiste pole, jeden oczywisty przycisk.
Drugi ekran może być szybkim przeglądem planu (funkcje, strony, dane), a potem krokiem budowania i podglądem działającym. Pierwszy moment sukcesu to chwila, gdy użytkownik może wykonać jedną realną czynność w podglądzie, np. dodać rekord lub przetestować rejestrację.
Gdy dane istnieją, powracający użytkownicy nie powinni znów widzieć tego samego pustego stanu. Ekran Projektów może przejść do widoku „ostatnie aplikacje” z jednym wyróżnionym działaniem szybkiego startu (np. Nowa aplikacja) i mniejszymi akcjami (np. Snapshoty lub Wdróż) w zależności od poprzednich działań.
Aby sprawdzić, czy pusty stan działa, mierz kilka wskaźników:
Wybierz jedną ścieżkę konfiguracji do poprawy w tym tygodniu. Postaw na tę, która ma największy współczynnik porzucenia albo którą nowi użytkownicy trafiają najpierw. Przepisz jej pusty stan tak, żeby szybko odpowiadał na trzy pytania: Co to jest? Dlaczego robić to teraz? Jakie jest następne kliknięcie?
Trzymaj zmianę małą. Nie przeprojektowujesz całego onboarding. Chodzi o to, by pierwsza udana akcja była oczywista.
Prosty plan na tydzień:
Po pierwszym sukcesie ustandaryzuj. Stwórz krótką wewnętrzną zasadę dla pustych stanów: odstępy, styl nagłówków, zasady ikon/ilustracji i spójny układ CTA. Gdy zespoły będą stosować tę strukturę, użytkownicy nauczą się jej raz i będą poruszać się szybciej wszędzie.
Jeśli budujesz nową aplikację i chcesz szybko prototypować kroki konfiguracji, Koder.ai (koder.ai) może pomóc tworzyć flow w Planning Mode, wygenerować pierwszą wersję do testów i iterować na podstawie tego, gdzie użytkownicy faktycznie się zawieszają.
Pusty stan to to, co użytkownik widzi, gdy nie ma jeszcze nic do pokazania — ponieważ nie stworzył, nie zaimportował ani nie podłączył żadnych danych. Powinien wyjaśnić, do czego służy ekran i wskazać następną skuteczną akcję, zamiast zostawiać użytkownika w domysłach.
Ekran ładowania mówi „poczekaj, coś się dzieje”, a stan błędu mówi „coś się nie powiodło, oto dlaczego”. Pusty stan konfiguracji mówi „tutaj nic jeszcze nie ma i to jest normalne”, a potem prowadzi użytkownika do utworzenia, zaimportowania lub rozpoczęcia od szablonu, żeby osiągnąć pierwszy realny rezultat.
Celuj w szybkie odpowiedzi na trzy pytania: co to za ekran, dlaczego jest pusty i co robić dalej. Jeśli użytkownicy nie zrozumieją tego w kilka sekund, częściej się zawahają, pomyślą, że zrobili coś źle, albo opuszczą aplikację.
Prosta struktura: krótkie wyjaśnienie, jedna oczywista akcja główna i linia zapewniająca, która zmniejszy obawy lub wysiłek. Trzymaj tekst krótko, żeby użytkownik nie musiał czytać całego akapitu, żeby wiedzieć, co kliknąć.
Domyślnie jedna akcja główna dopasowana do najczęstszego następnego kroku. Wszystko inne powinno być wyraźnie wtórne. Jeśli pokażesz kilka jednakowo ważnych przycisków, ludzie często zamarzną, bo nie wiedzą, która ścieżka jest „właściwa”.
Prowadź z „Utwórz”, gdy od zera da się szybko osiągnąć widoczny rezultat (pierwszy projekt, pierwszy rekord). Prowadź z „Import” gdy większość nowych użytkowników ma już dane gdzie indziej. Prowadź z „Szablon” gdy prędkość i gotowy punkt startowy są ważniejsze niż pełna kontrola.
Nagłówki pisz jako wynik + obiekt, np. „Utwórz swój pierwszy projekt”, zamiast etykiet funkcji jak „Projekty”. W tekście opisz, co się stanie po kliknięciu — jedna zdaniowa zapowiedź rezultatu pomaga użytkownikowi przewidzieć efekt.
Umieść nagłówek, jedno krótkie zdanie i główny przycisk w zwartej grupie z jasną hierarchią wizualną. Opcje wtórne trzymaj bliżej i cichsze, unikaj wypychania głównego przycisku daleko w dół strony, gdzie trzeba przewijać.
Dodaj krótką linię bezpieczeństwa blisko akcji, np. „Możesz to zmienić później” albo „Nic nie zostanie opublikowane, dopóki nie potwierdzisz”. W narzędziach takich jak Koder.ai warto wspomnieć o możliwościach cofania zmian (snapshoty) lub eksporcie kodu źródłowego po rozpoczęciu pracy.
Mierz, jak często użytkownicy widzą pusty ekran, klikają główny CTA i kończą kamień milowy, do którego ekran prowadzi. Obserwuj też czas do pierwszego sukcesu i współczynnik porzucenia między pustym stanem a następnym krokiem — bo czasami ekran może generować kliknięcia, ale nie doprowadzać do rzeczywistego rezultatu.