Nie używaj jednego, generycznego stanu pustego dla swoich tabel danych
Większość tabel danych dostarczana jest z jedną, jedyną wiadomością: „Brak danych”.
W przeglądzie projektowym wygląda to w porządku. W środowisku produkcyjnym generuje zgłoszenia do wsparcia technicznego.
Pusta tabela oznacza trzy różne rzeczy. Każdy przypadek wymaga specyficznego projektu, konkretnego tekstu i określonego działania.
Oto trzy przypadki, które musisz zaprojektować oddzielnie:
Pierwsze użycie (brak danych) Użytkownik jest nowy. Chce wiedzieć, do czego służy ta tabela i jak zacząć. • Cel: Wdrożenie użytkownika (onboarding). • Tekst: Wyjaśnij cel tabeli. • Działanie: Zapewnij przycisk do utworzenia pierwszego elementu lub zaimportowania danych. • Unikaj: Komunikatów typu „ślepy zaułek”, takich jak „Brak danych”.
Pusta po filtrowaniu (dane istnieją, ale filtry je ukrywają) Użytkownik zastosował filtry, które nie zwracają żadnych wyników. Często myśli wtedy, że narzędzie nie działa. • Cel: Pomóż użytkownikowi odnaleźć jego dane. • Tekst: Wyraźnie zaznacz, które filtry są aktywne. • Działanie: Zapewnij przycisk do wyczyszczenia wszystkich filtrów lub ich edycji. • Unikaj: Generycznych komunikatów, które ignorują aktywne filtry.
Błąd ładowania (zapytanie nie powiodło się) Serwer zwrócił błąd lub nastąpiła awaria sieci. • Cel: Pomóż użytkownikowi wrócić do pracy. • Tekst: Wyjaśnij, że ładowanie się nie powiodło, i podaj znacznik czasu lub kod błędu. • Działanie: Zapewnij przycisk ponowienia próby. • Unikaj: Informowania użytkownika o „braku danych”, gdy problemem jest w rzeczywistości błąd techniczny.
Dlaczego zespoły zawodzą w tym aspekcie:
- Projektują stany puste zbyt późno w procesie.
- Testują tylko na danych demonstracyjnych, więc nigdy nie widzą stanu pustego.
- Traktują stany puste jako przypadki brzegowe.
W rzeczywistości stany puste to momenty o ogromnym znaczeniu. Dobry stan pusty przeprowadza użytkownika od zera do osiągnięcia wartości w kilka minut. Zły pozostawia go w konfuzji i frustracji.
Zaprojektuj swój komponent tabeli tak, aby obsługiwał te warunki oddzielnie. Zaprojektowanie ich teraz niewiele kosztuje, ale zaoszczędzi mnóstwo czasu wsparcia technicznego w przyszłości.