Zasady UX Dona Normana, które pomogą uniknąć mylących interfejsów

Ukryty koszt mylących interfejsów

Mylące interfejsy nie tylko źle wyglądają. Generują wymierne koszty: ludzie porzucają rejestrację i zakup, proszą o zwroty i kontaktują się z pomocą techniczną w sprawach, które powinny być oczywiste.

Zazwyczaj problem nie leży w estetyce. Chodzi o jasność. Użytkownicy nie potrafią powiedzieć, czego system od nich oczekuje, co stanie się dalej ani czy bezpiecznie jest kontynuować.

Ta niejasność przekłada się na realne straty czasu i pieniędzy w kilku przewidywalnych obszarach. Wzrosty porzuceń pojawiają się, gdy ktoś trafia na moment wątpliwości. Działy wsparcia zalewają pytania „Gdzie jest X?” i „Dlaczego to się stało?”. Zwiększają się zwroty i chargebacki, gdy przepływy cenowe, potwierdzenia lub anulowania są niejasne. Wewnątrz zespołów ludzie piszą poradniki i obejścia, bo produkt nie tłumaczy się sam.

Małe tarcia stają się kosztowne, bo powtarzają się w często używanych ścieżkach. Myląca rejestracja może kosztować Cię użytkownika raz. Mylące płatności mogą kosztować Cię za każdym razem.

Prosty scenariusz pokazuje, jak to działa: ktoś tworzy konto i zmienia ustawienie, np. częstotliwość powiadomień. Widzi przełącznik, stuknie go i nic nie potwierdza zmiany. Później nadal dostaje e‑maile. Masz zgłoszenie do supportu, użytkownik czuje się oszukany, a zaufanie spada. UI może wyglądać schludnie, ale doświadczenie jest niejasne.

Szybkie tempo ułatwia przeoczenia. Gdy budujesz szybko, zwłaszcza przy użyciu narzędzi chatowych generujących ekrany i przepływy, możesz skończyć z krokami, które mają sens dla budowniczego, ale nie dla użytkownika po raz pierwszy.

Naprawa zaczyna się od kilku pomysłów często kojarzonych z Donem Normanem: uczynienia akcji oczywistymi, dopasowania do modelu mentalnego użytkownika, zapewnienia szybkiego feedbacku i zapobiegania błędom zanim się wydarzą. Reszta tego przewodnika jest praktyczna: mały zestaw zasad oraz prosta rutyna, by zweryfikować każdy szybki przepływ zanim prawdziwi użytkownicy się pogubią.

Podstawy Dona Normana prostym językiem

Ludzie nie czytają interfejsów. Zgadują.

Użytkownicy przychodzą z modelem mentalnym, opowieścią w głowie o tym, jak coś powinno działać — bazując na innych aplikacjach, przedmiotach z świata rzeczywistego i nawykach. Gdy Twój interfejs pasuje do tego modelu, ludzie działają szybko. Gdy mu się sprzeciwia, zwalniają, wahają się i robią „błędy”, które w rzeczywistości są błędami projektowymi.

Modele mentalne: czego użytkownik oczekuje przed kliknięciem

Użytkownik klikający „Zapisz” spodziewa się, że jego praca jest bezpieczna. Użytkownik klikający „Usuń” spodziewa się ostrzeżenia lub łatwej drogi powrotu. Użytkownik widząc pole wyszukiwania myśli, że może wpisać i nacisnąć Enter. Te oczekiwania istnieją zanim pojawi się jakikolwiek tekst pomocy.

Dobry UX wykorzystuje te oczekiwania, zamiast próbować na nowo szkolić ludzi.

Signifiery vs affordance (co to jest vs jak wygląda)

Affordance to to, co element może zrobić. Signifier to to, co mówi, że może to zrobić.

Pole tekstowe umożliwia wpisywanie. Signifierem jest widoczny obrys pola, kursor i czasem tekst zastępczy. Przycisk umożliwia kliknięcie. Signifierem jest jego kształt, kontrast i etykieta. Jeśli ostylujesz przycisk tak, by wyglądał jak zwykły tekst, affordance się nie zmienił, ale signifier osłabł i ludzie go nie zauważą.

Dwie „przepaści”, które tłumaczą większość niejasności

Gulf of execution to luka między tym, czego użytkownik chce, a akcjami, które UI udostępnia. Jeśli ktoś chce zmienić adres wysyłki, a widzi tylko „Edytuj profil”, może nie wiedzieć, co zrobić.

Gulf of evaluation to luka między tym, co system zrobił, a tym, co użytkownik może zrozumieć ze ekranu. Jeśli kliknie „Zapłać” i nic się nie zmieni (albo pojawi się jedynie malutki spinner), nie wie, czy operacja powiodła się, nie powiodła, czy nadal trwa.

Feedback: pokaż, co się stało i co będzie dalej

Dobry feedback jest szybki, jasny i konkretny. Odpowiada na trzy pytania: czy to zadziałało, co się zmieniło i co mam teraz zrobić?

To ma większe znaczenie, gdy budujesz szybko przy pomocy narzędzi chatowych. Wygenerowane ekrany wciąż potrzebują oczywistych signifierów i bezbłędnego feedbacku, żeby użytkownicy po raz pierwszy się nie pogubili.

Prawdziwe przykłady z oprogramowania, które mylą ludzi

Mylące interfejsy rzadko zawodzą, bo kod jest zły. Zawodzą, bo ekran nie odpowiada temu, co ludzie myślą, że stanie się dalej.

Klasyczny przykład to bałagan „Zapisz vs Wyślij vs Opublikuj”. W wielu narzędziach „Zapisz” może oznaczać „zapisz szkic”, „zapisz i udostępnij” lub „zakończ proces”. Użytkownik, który chce tylko zachować pracę, zawaha się albo kliknie niewłaściwie i spanikuje. Etykiety takie jak „Zapisz wersję roboczą” i „Opublikuj teraz” redukują to zagrożenie, bo opisują rezultat.

Ekrany ustawień też robią dużo cichego szkody. Niejasne lub odwrócone przełączniki są wszędzie: przełącznik zatytułowany „Powiadomienia” bez informacji, co znaczy WŁ. Jeszcze gorzej, gdy przełącznik wygląda na włączony, a funkcja jest faktycznie wyłączona z powodu innej zależności. Ludzie przestają ufać stronie i zaczynają zgadywać.

Formularze to kolejny powtarzalny problem. Formularz rejestracyjny, który kończy się błędem bez wyjaśnienia, w praktyce mówi „Próbuj, aż się uda”. Ukryte zasady hasła pokazywane dopiero po błędzie, wymagane pola zaznaczone jedynie cienkim czerwonym obrysem albo komunikaty typu „Nieprawidłowe dane” zmuszają do dodatkowej pracy.

Puste stany też potrafią uwięzić użytkownika. Pusty dashboard z napisem „Brak danych” zostawia użytkownika bez pomysłu, co dalej. Pomocny pusty stan odpowiada na jedno pytanie: co mam teraz zrobić? Proste „Utwórz swój pierwszy projekt” plus jedno zdanie o tym, co się stanie dalej, często wystarcza.

Akcje destrukcyjne często kryją się pod neutralnym słownictwem. „Usuń” może znaczyć „usuń z tej listy” albo „usunąć na zawsze”. Jeśli skutek jest nieodwracalny, sformułowanie musi to jasno komunikować.

Jeśli budujesz szybko, warto najpierw podwójnie sprawdzić: etykiety przycisków powinny opisywać rezultat, przełączniki powinny mówić, co znaczy WŁ/WYŁ, błędy formularzy powinny wskazywać konkretnie pole i regułę, puste stany powinny proponować następny krok, a akcje destrukcyjne powinny być nazwane jasno i potwierdzone, jeśli trzeba.

Dopasuj przepływ do celu użytkownika

Większość nieporozumień zaczyna się, gdy produkt jest budowany od ekranów na zewnątrz, zamiast od celu użytkownika do środka. Ekran może wyglądać na pełny, a mimo to zawodzić, jeśli nie pomaga komuś dokończyć tego, po co przyszedł.

Wybierz jeden cel i zapisz go jak zadanie, nie jako funkcję: „Utwórz fakturę i wyślij ją”, „Zarezerwuj fryzurę na piątek” albo „Opublikuj stronę docelową”. Ten cel jest kotwicą, bo definiuje, co oznacza „zrobione”.

Potem skurcz podróż do najmniejszego zestawu kroków, który wciąż wydaje się naturalny. Jeden z najszybszych sposobów na ograniczenie niejasności to usunięcie kroków, które istnieją tylko dlatego, że budowniczy zna dodatkowy kontekst. Budowniczowie często umieszczają ustawienia na początku, bo miało to sens przy konfiguracji. Nowi użytkownicy zwykle chcą najpierw zacząć robić, a ustawienia dopiero potem.

Praktyczny test: sprawdź każdy krok trzema pytaniami:

• Co to jest (prosto)?
• Co mogę tu zrobić (czy główna akcja jest oczywista)?
• Co się stanie, jeśli to zrobię (czy rezultat jest przewidywalny)?

Gdy któryś krok zawodzi w jednym z tych punktów, użytkownicy zwalniają. Zawieszają się, przewijają, otwierają losowe menu albo odchodzą, by zapytać kolegę.

Szukaj przewidywalnych punktów zatrzymania: wybór o niejasnych różnicach („Workspace” vs „Project”), formularz proszący o informacje, których nie mają, strona z wieloma przyciskami głównymi lub przepływ zmieniający terminologię w trakcie (rejestracja, potem „provision”, potem „deploy”).

Gdy znajdziesz punkt zatrzymania, dostosuj następną akcję do celu. Użyj słów użytkownika, przenieś ustawienia zaawansowane na później i zrób jeden oczywisty kolejny krok. Przepływ powinien przypominać ścieżkę prowadzącą, nie test wiedzy.