Projektowanie pustych stanów aplikacji: co pokazać, gdy nie ma jeszcze danych

Użytkownik otwiera listę zleceń i widzi pusty ekran. Nie wie, czy firma nie ma jeszcze żadnych spraw, czy wybrał zły filtr, czy aplikacja nie potrafi pobrać danych. Wszystkie trzy sytuacje mogą wyglądać podobnie, ale każda wymaga innego następnego kroku.

Pusty stan aplikacji to widok pojawiający się wtedy, gdy w danym miejscu nie ma treści do pokazania. Może informować o pierwszym użyciu, braku wyników albo tym, że zadanie nie zostało jeszcze wykonane. Nie powinien jednak ukrywać błędu lub braku uprawnienia pod tym samym komunikatem.

Dobre rozwiązanie zaczyna się od pytania, co użytkownik próbował zrobić i co system rzeczywiście wie. Ilustracja może pomóc, lecz nie zastąpi wyjaśnienia i działania, które człowiek może wykonać. Poniższe przykłady są fikcyjne i trzeba je dopasować do procesu oraz zasad dostępu w konkretnej aplikacji.

Pierwsze użycie różni się od pustego wyniku

Wyobraźmy sobie nowy panel obsługi zleceń. Firma jeszcze nie utworzyła żadnej sprawy. Widok może wyjaśnić, do czego służy lista oraz jak rozpocząć pierwsze zlecenie, jeśli dana osoba ma do tego uprawnienie. Przycisk prowadzący do konkretnego zadania jest wtedy bardziej pomocny niż sama informacja „brak danych”.

Inaczej wygląda sytuacja po zastosowaniu filtrów. Zlecenia mogą istnieć, ale żadne nie odpowiada wybranemu okresowi lub statusowi. System powinien pokazać aktywne warunki oraz pozwolić je zmienić. Komunikat „nie masz zleceń” byłby mylący, jeśli wyniki ukrył filtr pozostawiony z poprzedniej wizyty.

Jeszcze innego tekstu potrzebuje wyszukiwanie, które nie znalazło pasującego numeru lub nazwy. Użytkownik może sprawdzić pisownię, użyć innego pola albo usunąć część zapytania. Warto pokazać te możliwości bez sugerowania, że sprawa na pewno nie istnieje w żadnym systemie firmy.

W dashboardzie operacyjnym pusty wykres również wymaga kontekstu. Brak spraw w danym okresie, brak dostępu do oddziału i nieudane odświeżenie danych to różne sytuacje. Osoba podejmująca decyzję powinna wiedzieć, którą z nich pokazuje ekran.

Przy pierwszym użyciu warto też sprawdzić, czy użytkownik rzeczywiście odpowiada za wprowadzenie danych. Osoba zaproszona do przeglądania raportu może jedynie czekać, aż administrator przygotuje źródło. Przycisk tworzenia zadania nie pomoże jej, jeśli nie ma prawa wykonać tej czynności.

Pusty wynik może dotyczyć również przygotowywanego raportu. Zanim użytkownik pobierze plik, warto wyjaśnić zakres oraz stan danych, o czym piszemy w artykule o eksporcie danych z aplikacji.

Nie nazywaj błędu brakiem danych

Jeżeli aplikacja nie otrzymała odpowiedzi od serwera, system nie ma podstaw, aby twierdzić, że lista jest pusta. Powinien powiedzieć, że danych nie udało się pobrać, i wskazać możliwy następny krok. Może nim być ponowna próba, kontakt z pomocą albo sprawdzenie stanu usługi, zależnie od sytuacji.

Komunikat powinien opisywać to, co rzeczywiście wiadomo. „Nie udało się pobrać zleceń” jest uczciwsze niż wskazanie konkretnej przyczyny, której aplikacja nie potwierdziła. Techniczny szczegół przydatny zespołowi utrzymania nie musi trafiać do głównego tekstu. Wsparcie może potrzebować identyfikatora błędu, jeśli został bezpiecznie przygotowany do przekazania.

Jeżeli na ekranie pozostają starsze dane, trzeba wyraźnie wskazać ich stan i czas ostatniego potwierdzenia, o ile jest dostępny. Nie każda aplikacja może bezpiecznie pokazywać zapisane wyniki po utracie połączenia. Decyzja zależy od procesu, uprawnień i tego, czy nieaktualna informacja może wprowadzić odbiorcę w błąd.

O przekazaniu problemu odpowiedniej osobie piszemy w artykule o monitorowaniu automatyzacji. W samym interfejsie warto odróżnić wiadomość dla użytkownika od sygnału, na który reaguje zespół utrzymania.

Podczas próby zwróćcie uwagę na czas oczekiwania. Jeśli ekran przez kilka sekund nie pokazuje ani wyników, ani informacji o pobieraniu, użytkownik może uznać brak danych za ostateczny. Stan ładowania powinien być odróżniony od zakończonego zapytania i błędu.

Brak uprawnień wymaga ostrożnego komunikatu

Osoba może nie widzieć danych, ponieważ nie ma prawa dostępu do konkretnego zasobu. System powinien stosować uzgodnione zasady autoryzacji, a komunikat pomagać w dalszym działaniu bez ujawniania informacji osobie nieuprawnionej. W zależności od procesu może wskazywać kontakt z administratorem albo ogólną informację o niedostępności.

Nie zawsze należy potwierdzać, że cudza sprawa istnieje. Jeśli sam numer lub nazwa rekordu stanowi informację, szczegółowy komunikat odmowy może ją ujawnić. Osoby odpowiedzialne za bezpieczeństwo powinny ustalić odpowiedni poziom szczegółowości dla danego procesu. Widok musi być zrozumiały dla uprawnionego użytkownika, ale nie może zastępować kontroli po stronie serwera.

Przy zmianie roli lub oddziału sprawdźcie, czy wcześniej zapisany filtr i link nadal prowadzą do dozwolonego zakresu. O projektowaniu dostępu według obowiązków piszemy w artykule o rolach i uprawnieniach. Pusty ekran nie jest dowodem, że reguła dostępu została prawidłowo zaimplementowana.

Przygotujcie osobny scenariusz dla użytkownika, który spodziewał się dostępu, ale go nie ma. Czy wie, do kogo zwrócić się z pytaniem? Czy osoba odpowiadająca może sprawdzić jego rolę bez proszenia o hasło? Takie zadanie pomaga zaprojektować bezpieczną i wykonalną drogę pomocy.

Zaproponuj działanie, które ma sens

Przycisk w pustym stanie powinien prowadzić do zadania związanego z powodem braku treści. Na nowej liście może to być utworzenie pierwszego zlecenia. Po zastosowaniu filtru przydatne będzie jego usunięcie. Przy błędzie pobierania odpowiednia może być ponowna próba, jeśli nie powoduje niezamierzonego skutku.

Nie umieszczajcie przycisku tworzenia, gdy użytkownik nie ma odpowiedniego uprawnienia. Można wskazać, kto zarządza dostępem, jeśli proces przewiduje taką drogę. Podobnie nie proponujcie ponownego wysłania operacji zmieniającej dane bez sprawdzenia, czy wcześniejsza próba nie została już wykonana.

Tekst powinien być konkretny i krótki, ale nie pomijać informacji potrzebnej do decyzji. „Nie znaleziono zleceń dla wybranego okresu” wyjaśnia więcej niż „ups”. Jeśli system zna aktywny filtr, warto go pokazać. Jeżeli przyczyna jest nieznana, należy to uczciwie powiedzieć i wskazać dostępną drogę pomocy.

W aplikacji używanej przez kilka zespołów ten sam stan może wymagać innego działania. Koordynator może utworzyć zadanie, a pracownik terenowy poprosić o jego przydzielenie. O różnicach w pracy między lokalizacjami piszemy w artykule o systemie dla wielu oddziałów.

Pokaż, kiedy dane będą potrzebne

Nowy użytkownik nie zawsze musi natychmiast utworzyć pierwszy rekord. W panelu raportowym firma może dopiero podłączać źródło informacji, a pracownik nie mieć prawa do jego konfiguracji. Zamiast kierować każdego do tego samego przycisku, pokażcie stan przygotowania oraz osobę lub zespół odpowiedzialny za kolejny krok.

Jeżeli lista jest pusta, ponieważ zadanie wykonano, komunikat może potwierdzać zakończenie pracy. Powinien jednak odnosić się do ustalonego zakresu. Brak spraw przypisanych do bieżącego użytkownika nie dowodzi, że cała firma nie ma otwartych zleceń. Różnica jest ważna zwłaszcza w raportach dostępnych osobom o różnych rolach.

Przy danych oczekujących na pierwszą synchronizację wskażcie, czy system nadal pracuje, czy potrzebna jest decyzja administratora. Jeśli nie można przewidzieć czasu zakończenia, nie wpisujcie go wyłącznie po to, by ekran wyglądał na bardziej pomocny. Użytkownik potrzebuje informacji, na której może oprzeć następne działanie.

Ilustracja, która nie zmienia znaczenia komunikatu

Grafika może nadać pustemu widokowi charakter, ale powinna pasować do sytuacji. Rysunek zachęcający do świętowania nie jest dobrym towarzyszem błędu pobierania danych. Najpierw wybierzcie właściwy komunikat i następny krok, dopiero potem sprawdźcie, czy ilustracja pomaga go zauważyć.

Jeżeli obraz jest wyłącznie dekoracją, nie powinien powtarzać tej samej informacji w sposób utrudniający korzystanie z czytnika ekranu. Jeśli sam niesie potrzebny komunikat, trzeba zapewnić jego dostępny odpowiednik. Sposób wykonania należy sprawdzić w kontekście konkretnego interfejsu.

Zwróćcie uwagę na użytkowników, którzy widzą widok codziennie. Długi tekst w miejscu krótkiej informacji może utrudniać pracę, a żart powtarzany przy każdej pustej liście szybko przestaje bawić. Przydatna treść powinna pomagać w zadaniu również po pierwszym spotkaniu.

Nie zgub kontekstu podczas powrotu do listy

Użytkownik może otworzyć szczegóły sprawy, wrócić do listy i zobaczyć inny wynik, ponieważ dane zmieniły się w międzyczasie. Ustalcie, czy aplikacja zachowuje wyszukiwanie i filtry oraz jak pokazuje zmianę zakresu. Powrót nie powinien po cichu usunąć warunku, od którego zależała decyzja.

Jeśli jedyny widoczny wynik przestaje być dostępny po odebraniu uprawnienia, sprawdźcie, jaki komunikat powinien się pojawić. Odpowiedź może zależeć od tego, czy samo istnienie rekordu jest informacją chronioną. Projektant, osoba odpowiedzialna za proces i zespół bezpieczeństwa powinni uzgodnić ten przypadek przed wdrożeniem.

Przy dużych listach sprawdźcie także końcową stronę wyników po usunięciu lub przeniesieniu rekordu. Użytkownik potrzebuje sposobu powrotu do pozostałych danych, a nie wrażenia, że cała lista zniknęła. Zachowanie należy ocenić na rzeczywistym zadaniu i urządzeniu używanym w pracy.

Dostępność obejmuje także komunikat o stanie

Osoba korzystająca z czytnika ekranu lub klawiatury powinna móc znaleźć informację o zmianie oraz wykonać proponowane działanie. W3C opisuje komunikaty statusu przekazywane technologiom asystującym bez konieczności zmiany kontekstu użytkownika. Zakres tej wskazówki dotyczy określonych komunikatów, więc zachowanie trzeba dobrać do konkretnego widoku.

Ikona lub kolor mogą wspierać rozpoznanie sytuacji, lecz tekst powinien wyjaśniać jej znaczenie. Jeśli aplikacja pokazuje tylko ilustrację pustego pudełka, użytkownik nadal nie wie, czy ma dodać pierwszą sprawę, czy poczekać na dane. Dekoracyjny obraz nie powinien zastępować dostępnej informacji.

Przy formularzu komunikat błędu powinien pomóc znaleźć właściwe pole i wyjaśnić, jak poprawić odpowiedź. W3C omawia zwięzłe informacje o wyniku i błędach formularza. Więcej o etykietach oraz zachowaniu wpisanych danych przeczytasz w artykule o dostępnym formularzu.

Sprawdźcie również język i długość tekstu na urządzeniu używanym przez odbiorcę. Na telefonie przycisk nie powinien zasłaniać komunikatu, a dłuższe tłumaczenie nadal musi pozostać czytelne. Nie zakładajcie, że poprawny wygląd na jednym ekranie potwierdza działanie całej ścieżki.

Przetestuj stan, zanim ktoś go zobaczy pierwszy raz

Przygotujcie nową organizację bez spraw, konto z ograniczonym dostępem oraz listę z aktywnym filtrem, który nie zwraca wyników. Poproście uczestnika próby o wyjaśnienie, co widzi i jaki krok wykonałby dalej. Jeżeli odpowiada inaczej, niż zakładał projektant, trzeba poprawić tekst, działanie lub sposób pokazania stanu.

Dodajcie niedostępny serwer oraz sytuację, w której dane są w trakcie pobierania. Użytkownik powinien móc odróżnić oczekiwanie od zakończonego pustego wyniku i błędu. Sprawdźcie również klawiaturę oraz technologie asystujące używane przez odbiorców. W artykule o testowaniu prototypu z pracownikami opisujemy przygotowanie takich zadań.

W kryteriach odbioru zapiszcie oczekiwane komunikaty, dostępne działania i osoby potwierdzające wynik. Test pojedynczego pustego ekranu nie dowodzi, że poprawnie obsłużono wszystkie przyczyny braku danych. Warto zachować przykłady dla kolejnych zmian aplikacji.

Jeśli chcesz poprawić miejsca, w których użytkownik nie wie, co zrobić dalej, opisz w briefie widok i sytuację prowadzącą do pustego ekranu. Możemy omówić oprogramowanie na zamówienie i zakres próby z użytkownikami. Napisz do Archifutura, używając fikcyjnych danych.