Dla każdego stanu należy nazwać sytuację, zakomunikować ją również technologii wspomagającej, zachować dane i zaproponować bezpieczne działanie: poczekać, powtórzyć, poprawić lub skontaktować się z pomocą techniczną.
Interfejs to nie tylko idealny ekran z kompletnymi danymi. Użytkownik czeka na sieć, otwiera puste konto, traci uprawnienia, wprowadza nieprawidłowe dane lub trafia na awarię usługi. Jeśli system wyświetli tylko spinner, pustą białą powierzchnię lub kod techniczny, człowiek nie wie, czy ma czekać, spróbować ponownie, czy skontaktować się z pomocą techniczną.
Dobrze zaprojektowany stan wyjaśnia, co system wie, zachowuje bezpiecznie wykonaną pracę i proponuje odpowiedni kolejny krok. Nie może obiecywać sukcesu, dopóki serwer nie potwierdził operacji, ani ujawniać wewnętrznych szczegółów bezpieczeństwa. Stan należy projektować jako część funkcji i testować przy wolnej sieci, powtórzonym żądaniu, utracie sesji oraz z technologiami asystującymi.
Model stanów powstaje razem ze ścieżką użytkownika
Dla każdego ekranu proszę spisać, w zależności od potrzeb, stan początkowy, ładowania, pusty, częściowy, sukcesu, błędu, offline i braku uprawnień. Należy odróżnić błąd użytkownika, problem z siecią, regułę biznesową i awarię wewnętrzną. Każda sytuacja wymaga innego tekstu i innego sposobu odzyskania. Jeden uniwersalny komunikat „Coś poszło nie tak” ukrywa potrzebną decyzję.
Określ, które dane można zachować, którą operację można bezpiecznie powtórzyć i kiedy grozi duplikacja. Przy płatności, zamówieniu lub wysłaniu formularza interfejs musi umieć odróżnić niepowodzenie od nieznanego wyniku. Jeśli stanu nie da się potwierdzić, nie nakłaniaj użytkownika do bezrefleksyjnego powtarzania krytycznej akcji.
- źródło i typ powstałego stanu
- dane, które mają zostać zachowane
- bezpieczeństwo ponawiania operacji
- właściciel reakcji technicznej i treściowej
Ładowanie powinno informować o zakresie i nie blokować bez potrzeby
Krótką operację można sygnalizować lokalnie przy elemencie, dłuższa wymaga zrozumiałego postępu lub przynajmniej informacji, co jest ładowane. Spinner bez tekstu i bez końca nie pokazuje, czy aplikacja pracuje. Skeleton powinien odpowiadać docelowemu układowi i nie może tworzyć fałszywej treści, która po załadowaniu gwałtownie się przesunie.
Blokuj tylko te kontrolki, które w sposób konfliktowy zmieniałyby trwającą operację. Przycisk po aktywacji informuje o stanie i zapobiega niezamierzonemu podwójnemu wysłaniu, ale reszta strony może pozostać użyteczna. Po przekroczeniu oczekiwanego czasu zaoferuj wyjaśnienie, anulowanie lub bezpieczne ponowienie (retry). Zmianę ogłoś bez wielokrotnego zakłócania pracy czytnika ekranu.
Pusty stan wyjaśnia, dlaczego nic nie widać
Rozróżniaj nowe konto bez danych, wyszukiwanie bez wyników, aktywny filtr bez dopasowań oraz brak uprawnień. Każdy przypadek wymaga innego komunikatu. Nowemu użytkownikowi pokaż pierwszy sensowny krok, przy zerowym wyniku zaproponuj zmianę filtra, a przy braku uprawnień wyjaśnij, z kim można się bezpiecznie skontaktować.
Nie należy wypełniać pustego ekranu generyczną ilustracją bez informacji. Przykład może pomóc zrozumieć przyszłą zawartość, ale musi być wyraźnie oznaczony i nie może wyglądać jak prawdziwy rekord. Akcja główna powinna być dostępna także z klawiatury, a jej nazwa powinna mówić, co utworzy lub zmieni.
- nowe konto bez pierwszego rekordu
- filtr lub wyszukiwanie bez dopasowania
- treść ukryta z powodu niewystarczających uprawnień
- dane usunięte lub tymczasowo niedostępne
Komunikat o błędzie zawiera diagnostykę dostosowaną do użytkownika
Komunikat powinien wskazywać zadanie, które się nie powiodło, to, co zostało zachowane, oraz możliwy kolejny krok. Identyfikator techniczny może pomóc działowi wsparcia, ale wyświetlajcie go oddzielnie od wyjaśnienia dla człowieka. Nie ujawniajcie stack trace, nazw baz danych, tokenów ani reguł bezpieczeństwa. Przy wrażliwej operacji nie zdradzajcie, czy konkretne konto istnieje.
Jeśli ponowienie jest bezpieczne, zachowaj kontekst i umożliw je w tym samym miejscu. Przy powtarzającym się niepowodzeniu zaproponuj alternatywę i kontakt z identyfikatorem zgłoszenia. Błąd nie powinien automatycznie przekierowywać na stronę główną i powodować utraty pracy. Przenieś focus lub ogłoś stan zależnie od znaczenia, tak aby użytkownik rozumiał zmianę.
Sukces, tryb offline i testy regresyjne zamykają cykl
Stan sukcesu należy potwierdzić dopiero po autorytatywnej odpowiedzi systemu. Proszę podać, co się stało, gdzie znaleźć wynik i czy następuje kolejny krok. Komunikat toast, który szybko znika, może nie wystarczyć przy ważnej operacji. W trybie offline należy wyraźnie oznaczyć zmiany zapisane lokalnie oraz stan ich przyszłej synchronizacji.
Należy przetestować wolne i przerwane połączenie, timeout, ponowienie, powrót, odświeżenie, podwójną aktywację, utratę sesji i niedostępną zależność. Warto sprawdzić obsługę klawiatury, focus i komunikaty czytnika ekranu. Błędy techniczne należy logować bez wrażliwych danych wejściowych i wiązać je z anonimowym typem zadania, aby zespół usuwał przyczyny, a nie tylko poprawiał treść komunikatów.
- potwierdzenie zapisu z autorytatywnego źródła
- widoczny wynik również po zniknięciu toastu
- jasny stan kopii lokalnej i serwerowej
- test bezpiecznego ponowienia krytycznej akcji
Najczęstsze pytania
Jak długo może być widoczny tylko spinner?
Stały czas nie sprawdza się w każdym zadaniu. Przy odczuwalnym oczekiwaniu wyjaśnij, co się dzieje, i w miarę możliwości zaoferuj postęp, anulowanie lub bezpieczne ponowienie.
Czy komunikat o błędzie powinien zawierać kod techniczny?
Może zawierać bezpieczny identyfikator referencyjny dla wsparcia. Nie powinien wyświetlać wewnętrznego stack trace, danych wrażliwych ani szczegółów technicznych, które nie pomogą użytkownikowi.
Czy toast nadaje się do potwierdzenia sukcesu?
Przy drobnej, odwracalnej akcji może wystarczyć. Przy płatności, zamówieniu lub wysyłce powinno pozostać stałe potwierdzenie z wynikiem i kolejnym krokiem.
Źródła i dalsza lektura
Adam Antoni vyvíja weby, aplikácie a softvér na mieru. Prepája firemné systémy, automatizuje procesy a vytvára AI agentov. Pôsobí v Spišskej Novej Vsi a spolupracuje s firmami na celom Slovensku.
