Projektowanie pustych stanów UI: wskaż następny krok, gdy brakuje treści

1. Zdiagnozuj przyczynę pustej przestrzeni

Traktuj pusty stan jako informację o produkcie, nie okazję do dekoracji. Zapytaj, co zdarzyło się tuż przed pojawieniem ekranu, co wie system i czy użytkownik może zmienić sytuację. NN/g opisuje puste stany jako okazje do przekazywania statusu, wspierania nauki i prowadzenia do ważnych zadań. Korzyści te zależą najpierw od poprawnego rozpoznania stanu.

W szczególności nie pokazuj „Brak elementów”, gdy żądanie jeszcze trwa. Zachowaj wskaźnik ładowania lub szkielet, dopóki wynik nie będzie znany. Jeśli żądanie się nie powiedzie, wyjaśnij błąd i sposób odzyskania. Jeśli zakończy się powodzeniem, lecz bez elementów, powiedz, że nie ma pasujących treści. To rozróżnienie zapobiega myleniu chwilowego opóźnienia lub problemu systemu z prawdziwym wynikiem.

2. Dopasuj tekst do przyczyny

Nagłówek powinien nazywać stan, a tekst pomocniczy wyjaśniać znaczenie lub sposób kontynuacji. Nagłówek musi nadawać się do szybkiego przejrzenia. Dodaj zdanie tylko wtedy, gdy odpowiada na rzeczywiste pytanie. Wskazówki Apple dotyczące tekstów zalecają jasne następne kroki na pustych ekranach, etykiety oparte na działaniu i bezpośrednie błędy wyjaśniające rozwiązanie. Unikaj dowcipu, który przesłania sens, niejasnych nagłówków typu „Nic tu nie ma” i obwiniania użytkownika.

Na przykład hipotetyczny ekran zapisanych elementów przy pierwszym użyciu mógłby mówić „Tutaj pojawią się zapisane poradniki”, dalej „Zapisz poradnik, aby wrócić do niego później”, z przyciskiem „Przeglądaj poradniki”. Ukończona lista zadań mogłaby powiedzieć „Wszystko gotowe” i zaproponować „Zobacz ukończone zadania”. To różne sytuacje: jedna uczy wypełniania funkcji treścią, druga potwierdza sukces.

Przy udanym wyszukiwaniu bez dopasowań hipotetyczny komunikat mógłby brzmieć „Żaden projekt nie pasuje do ‘orchid’” i sugerować „Spróbuj szerszego hasła lub wyczyść filtry”. Zachowaj zapytanie i, jeśli to możliwe, umożliw odwrócenie zmian filtrów. Przy błędzie sieci napisz „Nie udało się wczytać projektów” z przyciskiem „Spróbuj ponownie”. Nie twierdź, że projektów nie ma, jeśli system nie mógł tego sprawdzić.

• Nazwij odpowiedni obiekt lub kryteria, aby komunikat miał sens poza kontekstem.
• Użyj czasownika na przycisku, na przykład „Utwórz projekt”, „Wyczyść filtry” lub „Spróbuj ponownie”.
• Umieść instrukcje przy treści, której dotyczą, i używaj tekstu oprócz koloru lub obrazu.
• Unikaj „Ups”, obwiniania i technicznych kodów, chyba że są potrzebne do rozwiązania problemu.

3. Następny krok powinien pomagać, nie być automatyczny

Zaproponuj działanie, gdy użytkownik może rozsądnie zmienić sytuację lub kontynuować zadanie. Pierwsze użycie często potrzebuje przycisku tworzenia lub dodawania; brak wyników może wymagać usunięcia ograniczenia; błąd może oferować ponowienie. Wyczyszczona skrzynka lub ukończony trening mogą nie wymagać żadnego działania. Nie wciskaj przycisku w każdy stan tylko po to, by panel wyglądał interaktywnie.

Zachowaj proporcję w odzyskiwaniu. Nieudane odświeżenie zwykle wymaga wyjaśnienia w treści i możliwości ponowienia, a nie blokującego alertu. Apple zaleca dostosowanie informacji zwrotnej do wagi wiadomości i rezerwowanie alertów dla sytuacji krytycznych, wymagających działania. Przy wyszukiwaniu zachowaj pracę użytkownika i proponuj rozsądne zmiany zamiast po cichu modyfikować zapytanie. Material Design sugeruje również treść początkową, krótkie objaśnienie lub jasno oznaczone najlepsze dopasowania, jeśli naprawdę pomagają.

Używaj ilustracji tylko wtedy, gdy dodaje kontekst, ciepło lub rozpoznawalność. Nie powinna konkurować z komunikatem ani sugerować, że dekoracyjny obraz jest interaktywny. Prosta ikona może wystarczyć przy zwartym wyniku filtra; przy pierwszym użyciu obszaru roboczego przydatny może być mały przykład przyszłej zawartości. Jeśli dodajesz treść początkową, zadbaj, by łatwo ją rozpoznać i usunąć.

• Wybierz jedno główne działanie, które bezpośrednio odpowiada na przyczynę.
• Dodaj drugą drogę pomocy tylko wtedy, gdy odpowiada na prawdopodobne kolejne pytanie.
• Użyj spokojnego komunikatu o ukończeniu, gdy pusty wynik jest dobrą wiadomością.
• Zadbaj, by działanie było zrozumiałe także dla użytkowników klawiatury i czytników ekranu.

4. Oceń cały stan, nie tylko ilustrację

Sprawdź stan w rzeczywistym kontenerze: pełnoekranowy widok pierwszego użycia, mały panel boczny i filtrowana tabela mają inne potrzeby dotyczące miejsca i hierarchii. Umieść komunikat blisko obszaru, który opisuje. Zadbaj o czytelność przy powiększaniu i zawijaniu tekstu oraz łatwość znalezienia głównego działania bez rozpoznawania koloru. Przetestuj także przejścia: ładowanie do pustego stanu, ładowanie do błędu, ponowienie do sukcesu i zmianę filtra z powrotem do wyników.

Praktyczna analiza biblioteki zaczyna się od zdarzenia wywołującego i oczekiwanego sposobu odzyskania. Dla każdego wzorca zapisz stan, nagłówek, opcjonalne wyjaśnienie, główne działanie, drugą drogę i to, co nastąpi po wyborze. Porównuj zrzuty pod kątem struktury i hierarchii wizualnej, a potem sprawdź zachowanie produktu w kontekście; statyczny obraz nie pokaże, czy błąd można naprawić ani czy wynik naprawdę jest pusty. Przeglądaj bibliotekę UI ScreenKits i wszystkie kategorie, by znaleźć pokrewne wzorce.

• Czy użytkownik rozpoznaje, że treści brak, wciąż się ładuje lub jest niedostępna z powodu błędu?
• Czy komunikat uwzględnia bieżące zapytanie, filtry, konto lub ukończone zadanie?
• Czy działanie zachowuje przydatne dane i prowadzi do widocznego rezultatu?
• Czy stan działa w małym rozmiarze, z dłuższym tłumaczeniem i technologią wspomagającą?
• Czy można odzyskać dostęp po błędzie lub dostosować nieudane wyszukiwanie?