Gdy w tabeli lub liście zamiast treści pojawia się „zero”, użytkownik widzi pustkę. Tyle że to może znaczyć różne rzeczy: ekran może być „pierwszym razem”, wyniki mogą być puste po filtrach, ktoś jeszcze nic nie dodał albo interfejs komunikuje, że aktualnie nie ma danych do wyświetlenia. W tym momencie zaczyna działać empty state (zero-data screen copywriting) — mikrocopy, które ma wyjaśnić stan i poprowadzić dalej.
Dobre empty state nie jest dekoracją. To krótka rozmowa z użytkownikiem: co się stało, dlaczego ekran wygląda tak, jak wygląda, i jaki jest następny krok. W praktyce liczą się trzy elementy: nagłówek (primary message), zwięzły opis (body copy) oraz CTA do jednego, przewidywalnego działania. Zobacz, jak je układać, żeby „brak rekordów” nie brzmiał jak błąd ani ślepa uliczka.
Empty state ≠ „pusty ekran”: o co chodzi w zero-data screen
Gdzie najczęściej widać zero-data w praktyce
Zero-data pojawia się wtedy, gdy interfejs ma „pusto”, bo w tej chwili nie ma treści do pokazania. To może być sytuacja normalna, a nie awaria. Najczęściej spotkasz ją w miejscach, gdzie użytkownik naturalnie oczekuje danych, ale ich jeszcze nie ma.
Typowe przykłady w UI:
- Pusta tabela/lista, gdy użytkownik dopiero zaczyna i nie ma jeszcze rekordów do wyświetlenia.
- Brak wyników po wyszukiwaniu lub po zastosowaniu filtrów.
- Pierwsze wejście w nowy widok (edukacyjnie/onboardingowo) — ekran ma pokazać, co tu będzie się działo, gdy pojawią się dane.
- Scenariusze, w których użytkownik oczekuje treści, bo „powinna się pojawić” — wtedy copy musi rozbroić nieporozumienie i zaprowadzić do kolejnego kroku.
Właśnie dlatego empty state powinien być projektowany jako komunikacja: nagłówek + opis + akcja (jeśli istnieje), a nie tylko „biała przestrzeń”. To zapobiega wrażeniu, że użytkownik zrobił coś źle albo że system jest „zepsuty”.
Nagłówek, który nie myli: brak danych vs błąd
Szybka zasada doboru nagłówka: „co to za stan?”
Zanim zaczniesz pisać, odpowiedz sobie na jedno pytanie: jaki to stan — rzeczywisty brak danych, a może problem, który wymaga innego typu komunikatu? Patterny empty states podkreślają, że nagłówek ma dać primary message: wyjaśnić powód stanu wprost, krótko i bez mieszania kategorii.
Najprostsza zasada: jeśli ekran pokazuje „rzeczywistość stanu” (np. nie ma rekordów, bo to dopiero start), nagłówek powinien mówić o tym, że nie ma tego, co miało się pojawić. Jeśli natomiast to sytuacja, która przypomina problem z wyświetleniem/konfiguracją, copy nie powinno udawać „normalnej pustki”.
Przykładowe kierunki nagłówków (dobieraj do przyczyny, nie do emocji użytkownika):
- Gdy to brak danych: „Brak wpisów” / „Tu jeszcze nie ma rekordów” — bez dodatkowych obietnic.
- Gdy to zero wyników po filtrach/wyszukiwarce: „Nie znaleźliśmy wyników” — z naciskiem na bieżący rezultat działania.
- Gdy to pierwszy raz / ekran ma nauczyć: „Zacznij od pierwszego wpisu” — nagłówek prowadzi do aktywacji, nie do rozczarowania.
- Gdy to sytuacja, która może wyglądać jak błąd: dopasuj nagłówek do tego, że potrzebna jest inna obsługa (nie „czekaj aż dane się pojawią”).
Cel nagłówka jest praktyczny: użytkownik ma szybko rozpoznać, czy to komunikat „brak danych”, czy „coś wymaga innego kroku”, i co dalej.
Jak dopasować treść do kontekstu ekranu (pierwszy raz, brak aktywności, filtry/wyszukiwanie)
Szablon: najpierw scenariusz, potem copy
Empty state nie jest jeden dla wszystkich ekranów. Kontekst decyduje o tonie i treści. Jeśli treść ma być zrozumiała, najpierw ustal, co dokładnie spowodowało pustkę: czy użytkownik jest na początku, czy właśnie uruchomił działanie, które logicznie mogło dać zero wyników.
Pracuj schematem: scenariusz → struktura wypowiedzi. Zgodnie z tym podejściem, zanim napiszesz nagłówek i opis, wypisz sobie (np. w briefie), co użytkownik zrobił tuż przed pustym ekranem.
Typowe scenariusze i jak przekładają się na copy:
- Nowy widok / pierwszy raz: język ma być bardziej edukacyjny. Użytkownik potrzebuje informacji „co to za miejsce” i „jak pojawią się dane” — nie tylko stwierdzenia, że ich brak.
- Brak aktywności (nic nie dodano): opis powinien mówić, że w tej chwili nie ma rekordów, bo jeszcze ich nie utworzono lub nie ma co pokazać, i wskazywać drogę do pierwszej wartości.
- Filtry i wyszukiwanie: opis ma odnosić się do bieżącego wyniku („aktualnie brak rezultatów”) i prowadzić do korekty kolejnego kroku, jeśli jest to możliwe.
- Wariant „pomyślne zakończenie” bez rezultatów: nadal prowadzisz dalej, ale bez obiecywania, że „zaraz pojawią się dane”. Tu liczy się sensowny kierunek działania.
W praktyce najwięcej błędów wynika z mieszania scenariuszy w jednym komunikacie, np. jednoczesnego mówienia o braku danych i o tym, że to problem systemowy. Dobra treść wybiera jeden powód i konsekwentnie prowadzi do następnego kroku.
Body copy: dlaczego i co dalej — w 1–3 liniach
Rzeczy, które warto zawrzeć w opisie (i te, których lepiej unikać)
Body copy w empty state ma być krótkie. Patterny zalecają zwięzłą formę: zwykle 1–2 zdania (lub zwięzłe linie), tak aby opis nie próbował zastąpić całej instrukcji produktu. Najważniejsze są dwa elementy: powód stanu oraz „co dalej”.
W treści możesz (a często powinieneś) dołożyć doprecyzowanie, dlaczego ekran jest pusty. Ale zawsze w perspektywie użytkownika: co to znaczy dla niego i jak szybko odzyska użyteczność.
Co warto zawrzeć:
- Powód w prostych słowach (np. brak rekordów, brak wyników po bieżących ustawieniach, sytuacja pierwszego użycia).
- Minimalny kontekst, który zapobiega nieporozumieniu „czy to błąd?”.
- Kierunek — opis powinien przygotować do CTA, a nie konkurować z nim.
- Spójność z ekranem: jeśli w tabeli pusto z powodu filtrów, to opis ma dotyczyć tej sytuacji, a nie „ogólnego braku danych”.
Czego lepiej unikać:
- Przesadnej liczby akcji w opisie — empty state ma prowadzić jednym, przewodzącym krokiem, a resztę informacji przełożyć poza komunikat.
- Nieprecyzyjnych technicznych sformułowań — mikrocopy ma być czytelne dla użytkownika, nie dla systemu.
- Mieszania kategorii („to nie błąd”, a obok sugestia naprawy typowej dla błędu) — takie zestawienie robi więcej zamieszania niż pomaga.
Jeśli w danym momencie istnieje sensowna akcja, body copy może ją „zasygnalizować”, aby użytkownik nie musiał domyślać się, co kliknąć.
CTA bez dead-endu: jak nazwać przycisk, żeby użytkownik wiedział, co kliknąć
Nazwy CTA: jak utrzymać jasność bez kombinowania
CTA w empty state ma być jednoznaczne i przewidywalne. Wytyczne podkreślają, że jeśli istnieje następny krok, powinien być dostępny bezpośrednio (np. jako primary action), a komunikat nie powinien zostawiać użytkownika w dead-endie.
W praktyce, zanim wymyślisz nazwę przycisku, ustal: co użytkownik może realnie zrobić z poziomu tego ekranu? CTA ma prowadzić do odzyskania użyteczności — do pierwszej wartości lub do korekty sytuacji, która spowodowała „zero”.
Jak dobrać CTA do kontekstu:
- Gdy pusto, bo użytkownik jeszcze nic nie dodał: CTA powinno kierować do działania tworzącego pierwsze dane (np. dodania wpisu).
- Gdy pusto, bo wyników nie ma po filtrach/wyszukiwarce: CTA powinno prowadzić do zmiany warunków (np. do ponowienia ustawień) — tak, by użytkownik miał logiczną drogę naprawczą.
- Gdy to nowy widok/onboarding: CTA może być krokiem startowym, który uruchamia sensowną kolejność działań.
Unikaj nazw, które brzmią jak obietnica efektu bez podstaw. Lepiej, żeby przycisk mówił o działaniu („dodaj…”, „utwórz…”, „zmień…”, „zacznij…”) niż o gwarancji („na pewno znajdzie”, „zawsze pokaże”). Wtedy użytkownik wie, co kliknie jako następny krok.
Checklist wdrożeniowy: zero-data screen copywriting od nagłówka do CTA
Szybki proces redakcyjny (do zastosowania od razu)
Żeby empty state był skuteczny, potraktuj go jak mały projekt komunikacji: krótki brief, szybka weryfikacja i korekty pod kontekst. Poniżej masz checklistę, którą możesz przejść przed wdrożeniem treści do tabeli/listy.
- Sprawdź nagłówek: czy mówi o właściwym powodzie stanu (brak danych / brak wyników / pierwszy raz), a nie myli go z błędem?
- Upewnij się, że opis (body copy) ma 1–2 zdania: powód + co dalej, bez lania wody.
- Weryfikuj spójność: czy nagłówek, opis i CTA nie należą do różnych scenariuszy?
- Dobierz jedno CTA jako przewodni krok: jeśli istnieje działanie, które przywraca użyteczność, przycisk ma do niego prowadzić.
- Usuń dead-end: użytkownik ma wiedzieć, co kliknąć teraz — nawet jeśli to „zacznij” zamiast „sprawdź później”.
- Przeczytaj całość jednym oddechem: czy komunikat nie brzmi jak „pusto bez sensu” i czy jest zrozumiały bez kontekstu technicznego?
Na koniec, potraktuj empty state jako zaproszenie do pierwszej wartości: nagłówek tłumaczy stan, opis przygotowuje, a CTA domyka rozmowę. Zero-data nie musi oznaczać frustracji. To moment, w którym copy może przejąć kontrolę nad doświadczeniem, zanim użytkownik straci orientację.
Skontaktuj się z Aleteksty.pl, aby omówić artykuły, teksty na stronę, opisy produktów lub regularną obsługę treści.
