Dobra praktyka UX to nie prawda objawiona. To hipoteza do sprawdzenia

Kiedy słyszę „przecież to jest zgodne z dobrymi praktykami”, często czuje po plecach przechodzą mi dreszcze.

Dlaczego?

Bo rozwiązanie, które na pierwszy rzut oka wygląda poprawnie – jest zgodne z heurystykami, wykorzystuje znany wzorzec, można na jego obronę znaleźć dziesiątki artykułów – wcale nie musi zadziałać.

Dopiero kontakt z realnymi użytkownikami pokazuje, że w konkretnym kontekście coś zgrzyta.

Ten artykuł jest dla Ciebie, jeśli w swojej pracy projektowej, produktowej czy badawczej słyszysz argument „tak się robi w UX” i czujesz, że to za mało, żeby podjąć decyzję. Pokażę Ci, dlaczego dobra praktyka jest dla mnie punktem wyjścia i hipotezą, a nie gotową odpowiedzią – i gdzie ten sposób myślenia najczęściej zawodzi.

Skąd w ogóle biorą się dobre praktyki UX?

Większość dobrych praktyk nie wzięła się znikąd. Za wieloma z nich stoją lata obserwacji zachowań użytkowników, badań nad użytecznością, psychologii poznawczej czy dostępności.

Dzięki nim wiemy na przykład, że warto:

• zachowywać spójność interfejsu
• informować użytkownika o stanie systemu
• zapobiegać błędom zamiast tylko informować o nich po fakcie
• korzystać ze znanych użytkownikom wzorców
• ograniczać niepotrzebne obciążenie poznawcze
• projektować tak, żeby użytkownik nie musiał pamiętać informacji, które system może mu pokazać

To sensowne punkty wyjścia.

Problem w tym, że gdzieś pomiędzy badaniami, artykułami, konferencjami i kolejnymi wdrożeniami łatwo zgubić jedno zastrzeżenie, które powinno być przyklejone do każdej z tych zasad.

To zależy od kontekstu.

„Best practice” to nie prawo fizyki

Weźmy prostą zasadę: im mniej kroków w procesie, tym lepiej. Brzmi rozsądnie – każdy dodatkowy ekran to potencjalnie więcej tarcia.

Ale czy proces z trzema krokami zawsze wygrywa z procesem z czterema krokami

Niekoniecznie.

Dodatkowy krok może:

• upewnić użytkownika, że dobrze zrozumiał konsekwencje swojej decyzji
• zapobiec kosztownemu błędowi
• wyjaśnić skomplikowaną regułę biznesową
• pomóc zebrać informacje potrzebne na dalszym etapie
• zwiększyć poczucie kontroli w procesie, który wiąże się z ryzykiem lub stresem

W takich sytuacjach optymalizacja liczby kliknięć może paradoksalnie pogorszyć doświadczenie, zamiast je poprawić.

Jukki: kiedy rozbudowane menu pomaga zamiast przeszkadzać

Podobną sytuację miałam w projekcie dla sklepu Jukki, który oferuje tekstylia dla dzieci.

Audyt był tu oparty na konkretnej, dobrze udokumentowanej zasadzie – Prawie Hicka. Im więcej opcji i im większa ich złożoność, tym dłużej użytkownik podejmuje decyzję.

Przy odrzuceniu na mobile sięgającym niemal 50%, wniosek wydawał się oczywisty: rozbudowane, wielopoziomowe menu powoduje „paraliż decyzyjny” i trzeba je uprościć.

Wywiady pogłębione pokazały coś dokładnie odwrotnego.

Dla części użytkowniczek, zwłaszcza świeżych mam i kobiet w ciąży, to samo rozbudowane menu pełniło funkcję edukacyjną, a nie przeszkadzającą.

Właśnie takie rozbudowane menu właśnie pomaga, w ogóle nawet jak nie wiesz, że są jakieś takie produkty, to właśnie przez to, że masz to na wierzchu, to je widzisz. – Zuzia

Jak byłam przed pierwszymi zakupami, to wchodziłam w każdą z tych zakładek i oglądałam sobie rzeczy, które są. I co mi się podobało, to wrzucałam do koszyka. – Martyna

Ten sam element interfejsu, dla jednej osoby jest mapą, która pomaga się rozejrzeć, a dla innej ścianą niezrozumiałych słów.

Prawo Hicka samo w sobie się nie myliło, po prostu nie uwzględniało tego, że dla części użytkowników „przeglądanie” nie jest szumem. Jest właśnie tym, po co przyszli i pomaga w edukacji na temat produktów.

Dlatego w rekomendacji końcowej napisałam wprost, że research jest tu ważniejszy niż audyt. Menu zostało szerokie, ale poprawiliśmy nazewnictwo kategorii, dodaliśmy ścieżki dopasowane do różnych poziomów wiedzy i ograniczyliśmy nawigację tylko tam, gdzie faktycznie rozpraszała, czyli w koszyku i checkoucie.

Nie radykalne cięcie, tylko porządkowanie.

Medeocare: kiedy wniosek z audytu zderza się z wynikiem badania

W projekcie dla Medeocare miałam do czynienia z wariantem tego samego problemu.

Audyt ekspercki zawierał dwie rekomendacje dotyczące wyszukiwarki. Pierwsza mówiła, że wyszukiwarka w sekcji hero na stronie głównej rozprasza uwagę od głównej oferty i lepiej zastąpić ją przyciskiem CTA. Druga – że wyszukiwarka nad headerem na mobile wprowadza dezorientację, bo jest „bardzo niestandardowym rozwiązaniem”, więc najlepiej zwinąć ją do małej ikonki.

W obu przypadkach kierunek był ten sam: schować, zmniejszyć, ograniczyć widoczność. Diagnoza opierała się na hierarchii wizualnej – wyszukiwarka byla „za bardzo widoczna” i „nie w tym miejscu”.

Dwa niezależne badania z użytkownikami (B2C i B2B) pokazały coś zupełnie innego.

Wyszukiwarka nie była dystraktorem. Była głównym, codziennym narzędziem nawigacyjnym. Ludzie korzystali z niej właśnie dlatego, że kategorie ich myliły.

Problem nie leżał w tym, że zajmuje za dużo miejsca na ekranie, tylko w tym, że nie działa tak, jak powinna.

Obecny stan wyszukiwarki nie tylko wydłuża ścieżkę użytkownika, ale wręcz ją blokuje. Klienci, którzy nie potrafią odnaleźć produktu przez specjalistyczne menu, a następnie zostają zawiedzeni przez techniczną niesprawność i nieelastyczność lupki, bardzo szybko oceniają sklep jako nieużyteczny.

W wywiadach B2B było to jeszcze bardziej konkretne. Nikola próbowała wpisać frazę „podkład celulozowy” na cztery różne sposoby, zanim się poddała. Anna opisywała to tak:

Czasami nawet potrafię wyjść w ogóle i wpisać w Google, i jeszcze raz zobaczyć, jak się to pisze. Bo to nie jest ten. O, to jest ten.

Użytkowniczka B2B, wpisując nazwę produktu w wyszukiwarkę własnego dostawcy, w pewnym momencie ufała bardziej Google niż wyszukiwarce sklepu, w którym właśnie robiła zakupy.

Kierunek naprawy okazał się dokładnie odwrotny do tego, co sugerował audyt. Zamiast kompresować wyszukiwarkę i chować ją z pola widzenia, trzeba było zainwestować w warstwę funkcjonalną – tolerancję literówek, kolejność wyrazów i synonimy. To była jedyna rekomendacja z obu badań oznaczona jako priorytetowy Quick Win.

I nie dotyczy to tylko wyszukiwarek. „Nie używaj modali”. „Jedno główne CTA na ekranie”. „Nie pokazuj użytkownikowi zbyt wielu opcji”. „Formularz powinien być jak najkrótszy”.

Każda z tych zasad UX może być świetną wskazówką na start. Żadna nie odpowiada jednak na pytanie, co próbuje zrobić konkretny użytkownik i czego potrzebuje, żeby zrobić to dobrze.

Auroria: dobre praktyki rozwiązują typowe problemy. Twój produkt ma konkretne

Dobre praktyki powstają na bazie powtarzalnych zachowań i problemów. Z definicji są więc pewnym uogólnieniem.

Kiedy jednak prowadzę badania konkretnego produktu, nie interesuje mnie przeciętny użytkownik. Interesuje mnie osoba, która w tym konkretnym momencie próbuje wykonać konkretne zadanie, z określoną wiedzą, motywacją i obawami. Często zupełnie inną niż użytkownik, dla którego dany wzorzec zwykle sprawdza się w innych produktach.

Dobry przykład z jednego z moich ostatnich projektów to Auroria.

Audyt ekspercki był tu jednoznaczny: strona nie prowadzi niezdecydowanej persony, brakuje ścieżki albo mechanizmu „pomóż mi wybrać”. Klasyczna, dobrze udokumentowana rekomendacja: jeśli użytkownik się waha, zaproponuj mu pomoc. W praktyce często oznacza to proaktywny chat albo asystenta pojawiającego się od razu po wejściu na stronę.

Badania z użytkownikami potwierdziły pierwszą część tej diagnozy. Potrzeba doradztwa rzeczywiście istniała. Nie potwierdziły jednak drugiej – czyli formy i momentu, w jakim ta pomoc miałaby się pojawić.

Wyłączam chatbox, bo nie lubię takich opcji na ekranie, wkurzają mnie.

Nie lubię okienek z czatem. Przeszkadzają mi. Nie używam i nie lubię pisać z robotem.

W syntezie całego badania pojawił się ten sam wzorzec: wiele osób nie chciało, żeby chat pojawiał się automatycznie jako pierwsza rzecz po wejściu na stronę. Nie ufały opiniom robota i wolały konsultację z żywym doradcą.

Dodatkowo z badań ilościowych wynikało coś, co moim zdaniem jest sednem tej sprawy: ponad 60% przez całą ścieżkę woli radzić sobie samodzielnie.

Doradztwo miało być czymś, po co sięgają sami, w momencie, który sami rozpoznają jako właściwy – nie czymś, co napotykają z góry narzucone.

To nie jest pełna sprzeczność z audytem. To coś bardziej podstępnego.

Audyt ekspercki miał rację, co do problemu i mylił się co do rozwiązania. Gdybyśmy wdrożyli rekomendację dosłownie, czyli wizard albo chat wyskakujący od razu, prawdopodobnie zirytowalibyśmy właśnie tę część użytkowników, której najbardziej zależało nam pomóc.

I właśnie dlatego rozwiązanie zgodne z dobrymi praktykami może przejść ekspercki audyt bez żadnych uwag, a mimo to sypać się podczas badań z realnymi użytkownikami. W takich sytuacjach problemu nie rozwiązuje kolejna uniwersalna zasada. Trzeba zrozumieć, dlaczego użytkownik zachowuje się właśnie w ten sposób.

Benchmark pokazuje, co robią inni. Nie mówi, dlaczego to działa

Podobny mechanizm widzę przy benchmarkach.

Jeśli pięć konkurencyjnych stron korzysta z tego samego rozwiązania, łatwo uznać je za standard. To rzeczywiście cenna informacja, zwłaszcza jeśli użytkownicy prawdopodobnie już się z nim spotkali.

Ale benchmark pokazuje przede wszystkim, co zostało wdrożone. Nie mówi automatycznie:

• czy użytkownicy w ogóle to rozumieją
• jakie alternatywy były wcześniej testowane
• jakie ograniczenia biznesowe wpłynęły na tę decyzję
• jakie problemy występują w tym rozwiązaniu na co dzień
• czy dany produkt osiąga dobre wyniki dzięki temu wzorcowi, czy raczej pomimo niego

Skopiowanie popularnego rozwiązania może zmniejszyć ryzyko projektowe. Nie zastępuje jednak zrozumienia problemu, który próbujesz rozwiązać.

Badania nie są od potwierdzania dobrych praktyk

I tu dochodzę do roli UX researchu, czyli mojej ulubionej części.

Badanie nie powinno odpowiadać wyłącznie na pytanie: „czy użytkownicy poradzą sobie z rozwiązaniem, które zaprojektowaliśmy zgodnie z best practices?”. To pytanie zbyt łatwo prowadzi do potwierdzania tego, co już założyliśmy.

Dużo ciekawsze pytania brzmią:

• jak użytkownik rozumie tę sytuację?
• jakiej informacji właściwie szuka?
• co budzi jego niepewność?
• na podstawie czego podejmuje decyzję?
• jak rozumie pojęcia, których używa Twój produkt?
• co zakłada, zanim jeszcze zacznie korzystać z interfejsu?
• w którym miejscu jego model mentalny rozmija się z modelem systemu?

Znowu Jukki dobrze to pokazuje.

Audyt opisał opis produktu na karcie produktu jako „ciężki, nieustrukturyzowany blok tekstu”, który na mobile „wydaje się nieskończony” i prawdopodobnie zniechęca do zapoznania się z kluczowymi informacjami. Klasyczna diagnoza: przeładowanie treścią.

Wywiady pokazały, że ta hipoteza jest trafna tylko dla części użytkowniczek – i zależała od etapu, na którym akurat się znajdowały.

Świeże mamy, bez wcześniejszego doświadczenia z danym typem produktu, bardzo ceniły dużą ilość dokładnych informacji. Mamy z większym doświadczeniem wolały dane w formie tabeli, którą można szybko przeskanować wzrokiem.

Gdybyśmy poszli za samym audytem i po prostu skrócili opis, ułatwilibyśmy życie jednej grupie kosztem drugiej – tej, która najbardziej potrzebowała wsparcia w podjęciu pierwszej, nieznanej wcześniej decyzji zakupowej.

Rozwiązaniem nie było więc usuwanie treści, tylko jej segmentacja: tabelaryczna specyfikacja techniczna dla osób skanujących wzrokiem, przy zachowaniu pełnej ilości informacji dla tych, które faktycznie chcą przeczytać wszystko od początku do końca.

Dopiero mając odpowiedzi na te pytania, wracam do dobrych praktyk i sprawdzam, które z nich faktycznie pomagają rozwiązać problem, który przed chwilą zobaczyłam w badaniu.

Dobra praktyka to hipoteza, nie decyzja

Najbardziej użyteczny sposób myślenia o dobrych praktykach, jaki znam, wygląda tak:

dobra praktyka → hipoteza → kontekst → badanie → decyzja projektowa

Zamiast:

dobra praktyka → gotowe rozwiązanie

To nie znaczy, że każdy checkbox, formularz czy element menu trzeba od zera badać z użytkownikami. Korzystanie z istniejącej wiedzy jest właśnie jednym z powodów, dla których nie musimy projektować produktów cyfrowych od podstaw za każdym razem.

Chodzi raczej o świadomość, gdzie kończy się wiedza wynikająca z ogólnych wzorców, a zaczynają założenia dotyczące Twojego konkretnego produktu.

Im większe konsekwencje ma błędne założenie, im bardziej specyficzny jest kontekst i im mniej wiemy o zachowaniu użytkownika, tym ostrożniej podchodzę do argumentu „Tak się robi w UX”.

Wracając więc do tego, od czego zaczęłam: to zdanie wcale nie zamyka tematu. Częściej dopiero go otwiera.

Bo najciekawsze pytanie w mojej pracy nigdy nie brzmi „Jaka jest tutaj dobra praktyka?”, tylko „W jakich warunkach ta dobra praktyka przestaje być dobra?”. I bardzo często właśnie odpowiedź na to drugie pytanie mówi mi najwięcej o produkcie, który naprawdę projektuję.