Projekt stanu pustego

Stan pusty to stan wyświetlany przez interfejs, gdy nie ma treści do wyświetlenia: nowe konto bez danych, wyszukiwanie bez wyników, kombinacja filtrów nie dająca żadnych rezultatów, wyczyszczona skrzynka odbiorcza lub lista oczekująca na pierwszy wpis. Stany puste należą do najczęściej pomijanych ekranów w większości produktów, ponieważ nie są tym, o czym myślą projektanci i rzadko występują w makietach używanych do weryfikacji projektu.

To zaniedbanie jest kosztowne, ponieważ puste stany pojawiają się w najważniejszych momentach. Każdy użytkownik nowego produktu zaczyna od pustego stanu, a to, co tam widzi, decyduje o tym, czy zrozumie cel produktu i podejmie pierwsze działanie. Pusty ekran z ogólnym komunikatem nic nie wnosi; dobrze zaprojektowany stan pierwszego użycia wyjaśnia, co tu pasuje, dlaczego to ma znaczenie i zapewnia jeden, oczywisty sposób rozpoczęcia. Skuteczność wdrożenia w dużej mierze zależy od tych ekranów, a nie od jakiegokolwiek przewodnika czy samouczka nałożonego na wierzch.

Wyniki wyszukiwania bez pasujących wyników to drugi przypadek o wysokiej wartości. Samo „brak wyników” to ślepa uliczka, a odwiedzający ma tylko jedną opcję: zgadnąć ponownie lub opuścić witrynę. Przydatna wersja tego samego ekranu wyjaśnia, czego szukano, oferuje poprawki ortograficzne, rozluźnia najbardziej restrykcyjny filtr, sugeruje powiązane terminy, pokazuje popularne alternatywy i wskazuje drogę do pomocy. W handlu wyszukiwania bez wyników oznaczają użytkowników z jasnymi intencjami i bez ścieżki do celu, co czyni je jednymi z najbardziej wartościowych, odzyskiwalnych błędów na stronie.

Stany puste służą również jako powierzchnie błędów i przypadków skrajnych, które ujawniają problemy systemowe. Lista pusta z powodu nieudanego żądania nie powinna wyglądać identycznie jak lista pusta, ponieważ tak naprawdę nic na niej nie ma, ponieważ prawidłowe działanie jest zupełnie inne. Rozróżnienie stanów pustego, ładowania i niepowodzenia oraz jasne komunikowanie każdego z nich zapobiega wyciąganiu przez użytkowników wniosków, że działający produkt jest uszkodzony, a uszkodzony jest po prostu nowy.

Aby je dobrze zaprojektować, konieczne jest jawne wyliczenie przypadków podczas projektowania, a nie odkrywanie ich podczas implementacji. Dla każdej listy, tabeli, wyszukiwania i pulpitu nawigacyjnego pytania brzmią: jak to wygląda bez niczego, z jednym elementem, z typową ilością, z ekstremalną ilością, podczas ładowania i po awarii. Systematyczne odpowiadanie na te pytania jest szybkie i zapobiega częstemu generowaniu pustych wariantów przez programistę pod koniec sprintu.

Puste stany to również okazja do nauczania, a nie tylko wyjaśniania, i właśnie tutaj najczęściej zdobywają swoje miejsce. Pierwszy stan użycia, który pokazuje przykładowy wygląd widoku zapełnionego, wykorzystując realistyczną, przykładową treść wyraźnie oznaczoną jako taką, komunikuje przeznaczenie produktu szybciej niż jakikolwiek opis i daje nowemu użytkownikowi cel, do którego może dążyć. To samo podejście dotyczy stanów następujących po usunięciu lub uzupełnieniu, gdzie wskazanie przeznaczenia przestrzeni zapobiega wyciągnięciu przez użytkownika wniosku, że coś poszło nie tak. Ograniczeniem jest uczciwość: przykładowa treść, której nie da się odróżnić od rzeczywistej, powoduje zamieszanie, a w produktach obsługujących pieniądze lub dokumentację może prowadzić do poważnych błędów.

Ponieważ stany puste znajdują się na granicy między projektowaniem interfejsu a zrozumieniem produktu, są one zazwyczaj traktowane jako część przepływu, a nie jako odizolowane ekrany. projekt produktu praca jest określana obok zaludnionych stanów jako standardowa praktyka i w Audyt UX są wiarygodnym źródłem odkryć, ponieważ niemal każdy produkt ma przynajmniej jeden pusty stan, który nigdy nie został zaprojektowany i teraz po cichu blokuje część użytkowników przy ich pierwszym zetknięciu z nim.