W tym odcinku dzielimy się 5 “magicznymi” zasadami UX, których możesz użyć, aby przeprowadzić audyt użyteczności swojego produktu lub usługi. [pobierz darmową checklistę]

Wysłuchaj, jeśli:

• potrzebujesz krytycznym okiem zerknąć na swój produkt cyfrowy/usługę,
• chcesz samodzielnie wyłapać podstawowe błędy 
• szukasz prostego narzędzia do oceny swojego produktu.

Co jest dla nas najważniejsze? Takie narzędzie powinno dać Ci poczucie, że wiesz, czy w Twoim produkcie dany problem istnieje, a jeśli tak to gdzie. 

PS Niepopularna opinia od agencji UX/UI: Nie musisz wydawać dodatkowego budżetu na osobny audyt.

Pobierz bezpłatną checklistę do samodzielnej oceny swojego produktu cyfrowego. 

 

Transkrypcja rozmowy

Ilona: Celem dzisiejszego odcinka jest dostarczenie ci wiedzy i narzędzi do tego, abyś mógł/a samodzielnie ocenić jakość swojego produktu cyfrowego albo usługi cyfrowej pod kątem user experience.

O Samodzielnym audycie

Być może masz takie przesłanki, że coś nie działa. Być może jesteś przekonany/a, że dobrze by było taki audyt przeprowadzić, ale nie do końca jeszcze jesteś przekonany/a do tego, żeby na przykład podjąć współpracę z taką agencją jak my, albo z jakimś freelancerem, ekspertem/ekspertką. 

No to dzisiaj właśnie odcinek dla Ciebie. Dlatego, że dla tych takich „Zoś Samoś” damy trochę narzędzi, które pomogą samodzielnie przeprowadzić audyt UX.

Ilona: Ale drogi słuchaczu, jeżeli uważasz, że Twój produkt jest super i nie wymaga poprawy, to też uważam, że przejście przez te zasady, którymi za chwilę się podzielimy, będzie bardzo fajnym ćwiczeniem. 

Pomoże ci to lepiej poznać swój produkt, zajrzeć tam, gdzie się zwykle nie zagląda i przeprowadzić taki audyt, który pokaże, czy przypadkiem nie ma tam jakiś luk.

Wstęp do Heurystyki Nielsena 

Radek: Tak, zawsze może być lepiej. Te wskazówki, o których dzisiaj będziemy rozmawiać, są uporządkowane według zasad, które są znane rynkowo i nazywają się one Heurystykami Nielsena. 

 

Ilona: Tak, będziemy opierać się o wiedzę zredagowaną przez dr. Jakoba Nielsena. To nie są najnowsze zasady. One zdążyły się już osadzić w świecie cyfrowym i przetrwały próbę czasu. Są cały czas aktualne i na tyle uniwersalne, że przejście tej listy wraz z przykładami i wyjaśnieniem pozwoli wam zrobić taką checklistę własnego produktu. 

Jedna uwaga na początku, zanim zaczniemy i zanim wejdziemy głębiej w tę naszą checklistę… pamiętaj o tym, że audyt UX przeprowadzony przez specjalistę lub samodzielnie pokaże ci skalę problemu, ale nie da ci rekomendacji rozwiązań.

 

Radek: Tak, takie rekomendacje mogą dać ci projektanci, którzy poszukają rozwiązań, wskażą kierunek rozwoju pogłębienia danego problemu. 

 

#1 Pokazuj status systemu 

Radek: Nie przedłużajmy! Co możemy zrobić w ramach pierwszej heurystyki, która brzmi: pokazuj status systemu? Co to w ogóle oznacza?

 

Ilona: Oznacza to, że interfejs naszego rozwiązania powinien dawać informacje, co się dzieje na danym ekranie. I tutaj mówimy na przykład o operacjach, które są w toku, o procesach albo… co ja właściwie mogę zrobić na tym ekranie? 

Przykładem może być tutaj bardzo prosta rzeczy, trywialna wręcz, pokazanie statusu, czy jestem zalogowany/a, czy nie.

 

Radek: Tak, albo na jakim etapie jestem np. w procesie zakupowym. To jest bardzo częste w projektach e-commerce, gdzie duża część ścieżki zakupowej jest w Internecie. Czy jestem teraz w koszyku, czy prekoszyku (bo takie też się zdarzają w procesie sprzedażowym) 

To jest bardzo ważne, żeby pokazywać, gdzie użytkownik się znajduje. 

Więc jeśli studiujesz taką ścieżkę zakupową, albo jesteś w swoim systemie i jest to na przykład system, w którym użytkownik powinien być zalogowany, to zadaj sobie pytanie, czy Twój interfejs mówi ci gdzie i na jakim etapie w ścieżce jesteś. Czy ten interfejs podaje takie informacje? 

 

Szanuj czas użytkownika

Radek: Innym przykładem na stronach są wszelkiego rodzaju loadery, kiedy na przykład ładują nam się jakieś dane. 

Robiłem kiedyś taki projekt, gdzie główną wartością był raport, który generował się po takiej sporej dawce informacji od użytkownika. Użytkownik musiał wpuścić dużo danych do systemu, żeby taki raport otrzymać. Raport dotyczył zdolności kredytowej. 

 

Trzeba było długo poczekać, zanim system przemielił wszystkie dane, aby dać użytkownikowi dobry raport. To trwało dość długo, ponad minutę. W Internecie to jest cała wieczność.

Więc co zrobić tutaj, żeby użytkownik nie uciekł, żeby nie pomyślał, że coś się zepsuło. W Internecie robimy się bardzo szybko niecierpliwi i negatywne emocje, gdy nie dostajemy natychmiast tego, czego chcemy, bardzo szybko się wzmagają. 

Więc bardzo ważne było zaprojektowanie takiego loadera, który nie tylko da semantyczną informację, że coś się dzieje w tle, ale też poinformuje mnie, ile czasu ten system potrzebuje jeszcze ode mnie, żebym poczekał na efekt.

 

#2 Zachowaj spójność

 

Ilona: Teraz przejdziemy do drugiej zasady. Druga zasada brzmi, zachowaj spójność pomiędzy systemem a rzeczywistością. Zdanie jest dosyć skomplikowane, ale mówi ono o języku.

 

Radek: Zdanie może nie jest skomplikowane, ale te są te pułapki heurystyki, które ja gdzieś tam zauważam i wytykam, bo tak na dobrą sprawę, o co chodzi? O to, żeby mówić językiem użytkownika, dla którego dedykujemy dane rozwiązanie, dany interfejs.

 

Ilona: Tak, użyte frazy i sformułowania powinny być dostosowane do tego, kim jest nasz odbiorca. Robiąc audyt swojego produktu, zwróć uwagę na to, czy nie używasz na przykład żargonu albo języka, którego Twoi odbiorcy nie mają szansy zrozumieć.

 

Może mają wątpliwości? Jeżeli ty będziesz mieć wątpliwości podczas sprawdzania kluczowej ścieżki, to znaczy, że prawdopodobnie ten tekst będzie dla nich niezrozumiały.

 

Radek: Bardzo trudne zweryfikować coś takiego, dlatego, że my jako specjaliści branżowi na co dzień używamy takiego specyficznego języka. I dla nas na przykład takie coś jak struktura strony albo…

 

Ilona: Flow. Zrobimy flow czegoś… to uwielbiamy.

 

Radek: Aby przejść, zrób swipe…różne naleciałości z języka angielskiego. Nam trudno zobaczyć, że to jest rzeczywiście żargon i naprawdę niektórzy będą mieli problem z tym, żeby coś zrozumieć, bo my po prostu łapiemy to i to jest dla nas zrozumiałe.

 

Ilona: Przykład ze swipe, bo pokazuje, jak ważne jest to kim jest nasz odbiorca. Jeżeli mówimy do nastolatków, to użycie sformułowania swipe będzie totalnie zrozumiałe. Ale jeżeli będziemy chcieli zrobić ogólną aplikację dla wszystkich…

 

Na przykład wyobraźmy sobie, że mObywatel ma w swojej instrukcji adresowanej do wszystkich Polaków, a teraz zrób swipe w prawo albo w lewo… to już trochę słabo.

 

Uważaj na słowa

 

Radek: Ja tutaj przytoczyłem hasło struktura i funkcjonalność strony, dlatego, że ostatnio w audycie widziałem ankietę, która pytała się wprost o strukturę i nawigacje strony. 

 

To był sklep e-commercowy więc tak na dobrą sprawę ludzie nie wchodzą na stronę i nie patrzą: o, ale fajna nawigacja i struktura strony. Może to tego jeszcze architektura i UX i wszytko razem.

 

Musimy na to uważać. Nie używajmy takich pojęć. I to jest bardzo trudne. 

 

Możemy powiedzieć, że bardzo dobrze znamy naszą grupę docelową i decydujemy się, że używamy danego języka. Co jest super, bo wtedy tę grupę docelową mamy.

 

Ale mało jest takich produktów, które mają naprawdę taką bardzo charakterystyczną grupę docelową. Może produkty SaaSowe, albo takie dedykowane konkretnym branżom… 

 

Ale większość produktów, które ja spotykam w naszej codziennej pracy, to produkty, które powinny przejść test pięciolatka. To znaczy, że pięciolatek powinien mniej więcej zrozumieć, o co chodzi. 

 

Ilona: Sugerowałabym również sprawdzenie jeszcze jednego zakamarka. Kiedy będziesz robić taki audyt, sprawdź komunikaty błędów, które są wyświetlane na stronie, kiedy użytkownik wykona jakąś akcję niepoprawnie albo zabraknie jakichś informacji i nie będzie mógł przejść dalej. Jak sformułowana jest informacja zwrotna do naszego drogiego klienta, pacjenta, czy po prostu użytkownika?

 

Radek: To, co pasuje do tego stanu połączenia zgodności między rzeczywistością a systemem, to też sklepy internetowe. Warto, żebyśmy pomyśleli, jak wyglądają półki sklepowe, jak są podzielone kategorie produktów.

 

Jak one leżą obok siebie w kategorii, którą masz na przykład właśnie w swojej nawigacji, czy kategoryzacji. To jest bardzo ważne, żeby na przykład piżamy leżały obok majtek, a nie obok…

 

Ilona: … stroju sportowego, co czasami się zdarza. 

 

Radek: Dokładnie, więc warto to sprawdzać.

 

#3 Daj kontrolę użytkownikowi  

 

Ilona: Trzecia zasada z naszej checklisty brzmi: daj użytkownikowi pełną kontrolę. 

 

Umówmy się, użytkownik często robi coś przez pomyłkę. Klika w przycisk, żeby np. sprawdzić, co się pod nim kryje, jakie tam są akcje. A czasami nie planował nawet wykonania tej akcji. 

 

Dlatego zasada ta (daj użytkownikowi pełną kontrolę) mówi o tym, żeby pozwolić mu wrócić do poprzedniego stanu. Dać mu możliwość zrobienia, znowu powiem coś z żargonu, emergency exit, czyli powrotu do poprzedniego ekranu, poprzedniego stanu. 

 

Szczególnie jeżeli jest to jakaś ważna akcja, na przykład usunięcie jakiegoś elementu.

 

Radek: Nawet zwyczajne cofanie się do poprzedniej karty np. z listingiem, czyli listą produktów, które się wyświetlają na karcie. To jest ważne, żebyśmy dawali możliwość kontroli nad tym.

 

Kontroluj pop-upy 

 

Radek: I tutaj często nasuwają mi się złe przykłady. Na przykład wyskakują pop-upy, które mają takie małe “X” do zamknięcia, a jest to na przykład, zapisz się do newslettera. 

 

Jest szereg takich akcji, które można dawać użytkownikowi do podjęcia, ale bez wyjaśnienia tak naprawdę czego one dotyczą. Na przykład możesz zapisać się przez przypadek do newslettera, chociaż tak na dobrą sprawę cały pop-up po dawał wrażenie czegoś innego. 

 

Ilona: Tak, ale z tym newsletterem to jest ciekawa historia, bo czasami szczególnie na małym ekranie dostajemy wielki pop-up zapisz się do newslettera, bez możliwości wyłączenia go. 

 

Jak tutaj możemy mówić o daniu użytkownikowi jakiejkolwiek kontroli, gdzie zmuszamy go do zapisania się do newslettera, bo inaczej nie może korzystać ze strony.

 

Radek: Ja najbardziej lubię te gdy próbujesz się wypisać z newslettera i ten interfejs jest tak pokolorowany, że jednak nie chcesz się wycofywać z tego newslettera… więc z powrotem mnie zapisz.

 

Ilona: Tak, też mamy odcinek o tzw. dark patterns. Często o to mówimy.

 

Radek: Dark patterns… brzmi trochę jak darknet.

 

Ilona: Trochę tak. To leży w tym samym worku. Mamy o tym odcinek i podlinkujemy w opisie.

 

Radek: Zwróćcie uwagę na to, czy przypadkiem operacje, które dajecie klientowi/użytkownikowi na waszym interfejsie… czy one dają mu pełną kontrolę decyzji o danej operacji, czy raczej wymuszają na nim nieświadome akcje. To jest bardzo ważne. 

 

Ja rozumiem, że można chcieć, żeby ludzie zapisywali się do newslettera, ale jeśli ktoś się zapisze do newslettera, a tego nie chciał, to będzie wkurzony. A jak będzie wkurzony, to powie o tym komuś innemu. I wtedy czarny PR sobie robicie, a nikt nie chce się na to narażać. 

 

Ilona: Tak, dokładnie. Tak samo będzie, jeżeli wykona jakąś akcję, która istotnie wpływa na to, jak korzysta z produktu i nie może tej akcji cofnąć, ani nie widzi, jakie są konsekwencje danego działania. 

 

#4 Spójność interfejsu 

 

Radek: To co, czwarta… ta o trzymaniu standardów i spójności interfejsu.

 

Ilona: W tym punkcie chodzi głównie o spójność systemu. Spójność systemu brzmi dumnie. Wszyscy wiemy, że bardzo trudno jest ją utrzymać w trakcie całego cyklu rozwoju produktu cyfrowego czy usługi cyfrowej.

 

Ale wielokrotnie widziałam, że w produktach, szczególnie tych dużych ta sama akcja, którą wykonujemy, nazywa się zupełnie inaczej. 

Zdecyduj się 

Radek: Co masz na myśli, mówiąc akcje?

 

Ilona: Już ci mówię. Ostatnio nawet uspójnialiśmy u jednego z naszych klientów pokazywanie historii zmian. Jednym z wymagań tej aplikacji jest to, aby wszystkie wykonane akcje były zapisywane w systemie i mogły być później odtworzone po pewnym czasie.  Takie akcje jak np. usunięcie, dodanie lub edycja elementu. Gdzie elementem może być np. faktura, albo zdjęcie. Jest to aplikacja B2B i tutaj wiadomo, że jeżeli coś źle wykonamy, coś usuniemy, a wpłynie to istotnie na projekt i np. wynikną z tego dodatkowe koszty, to zwykle firmy chcą wiedzieć, kto taką akcję wykonał i kiedy. I mieliśmy bardzo fajną funkcjonalność, czyli change log — historia zmian. Ale ten change log nazywał się w różnych miejscach aplikacji inaczej. Raz był po prostu logiem, raz był change logiem…

 

Radek: Changing log…

 

Ilona: Changing name… I to też było ciekawe, bo mieliśmy dokładnie tę samą funkcję, ale ona była nazwana w różnych miejscach inaczej. 

Wprowadzamy naszego odbiorcę w zdezorientowanie, bo on widział gdzieś w jednym module właśnie taką akcję. Teraz szuka jej, a jej nie ma albo jest pod inną nazwą. I to nie jest fajne.

 

Radek: Albo przejdź dalej w koszyku, albo w jakimś formularzu. Potem masz następny krok i w sumie nie wiadomo, o co tutaj chodzi. 

Ale wydaje mi się, że to nie tyczy się tylko i wyłącznie samego nazewnictwa. Bo te standardy to też na przykład kolor, prawda? Podczas pracy nad interfejsem staramy się na przykład zachować tę samą kolorystykę do aktywnych przycisków, linków, czyli wszędzie, gdzie możesz kliknąć i wywołać jakąś akcję. 

Te kolory są jasne i zarezerwowane do takich aktywnych elementów. I jeśli na przykład mamy brak spójności pomiędzy tymi elementami, to użytkownik może klikać coś, co nie jest klikalne. I to może denerwować. Albo na odwrót, nie będzie klikał w coś, co jest klikalne, bo będzie to wyglądało na przykład jak część grafiki.

 

Ilona: I też mieliśmy taki przykład, gdzie projektowaliśmy dosyć skomplikowany konfigurator. To też jest przykład e-commercu, ale B2B. 

 

Pomóż klientowi kliknąć

 

Radek: Ten e-commerce ma dużo za uszami. 

 

Ilona: Dużo jest też takiego połączenia, że jak audyt to e-commercowy. To jest dosyć popularne działanie. 

Ale to jest akurat produkt B2B. W momencie, kiedy weszliśmy do tego produktu, żeby się rozeznać, co tam się w ogóle dzieje, to okazało się, że miejsce, gdzie mogliśmy przetestować ten produkt w akcji, wyglądało, właśnie jak grafika.

Po wpięciu analityki produktowej okazało się, że nikt w to nie klika, bo w sumie to nie wie, że można w to kliknąć. Dzięki takiemu audytowi znaleźliśmy tę rzecz i wystarczyło zmienić jej wygląd. Daliśmy jasną informację użytkownikowi, co może z tym zrobić. I ludzie zaczęli w to klikać. 

Oczywiście to nie było tak, że ta funkcja nie była potrzebna i dlatego w nią nie klikali. Prosili o pomoc support. 

 

Przetestuj swoje call to action

 

Radek: Myślę, że takim prostym ćwiczeniem będzie sprawdzenie tych podstawowych przycisków do call to action, czyli tych, które wywołują główne akcje. 

I sprawdzić, chociażby, czy mamy spójność na poziomie tego głównego przycisku, który mówi kup, przejdź dalej, zapisz się. Potem przechodzić dalej do tych innych aktywnych elementów i sprawdzać, czy tam też ta różnice się pojawiają.

Ilona: Jeżeli mamy wątpliwości co do tego, czy na danym ekranie coś jest widoczne, czy jest jasne, możemy zawsze kogoś zapytać. Oczywiście w idealnym świecie, najlepiej spytać kogoś z naszych odbiorców, z naszej grupy docelowej. 

Ale jeżeli nie mamy akurat pod ręką nikogo, kto reprezentuje naszą grupę docelową, to o jakiś mały fragment możemy też zapytać kogoś, kogo znamy. 

Ale z tą spójnością jest tak, że trzeba o nią dbać praktycznie cały czas, tworząc nowe projekty, zmieniając moduły. Trzeba wracać do tego, co już jest, żeby nie zrobić z naszej usługi czy produktu cyfrowego Frankensteina.

A jeżeli go robimy, to przynajmniej wiemy, dlaczego i kiedy z tego stanu wyjdziemy. To jest też moje podejście, że czasem warto coś zmienić na jednym ekranie, sprawdzić, czy to działa i dopiero wtedy zmieniać wszędzie.

 

Radek: Ale masz wtedy tego świadomość, masz plan w tym wszystkim… 

 

Ilona: Tak, czwarta zasada: zachowaj standardy i spójność jak najbardziej jest czymś, co powinniśmy robić na co dzień.

 

#5 Zapobiegaj błędom 

Radek: Jesteśmy na półmetku. Piąta zasada: zapobiegać błędom, dotyczy wspierania użytkownika w nie popełnianiu błędów. Takie błędy użytkownicy mogą popełniać, wpisując np. ciąg liczb, daty, telefony.

Interfejs powinien wspierać użytkowników w tym, żeby takich błędów nie popełniali. Prawda jest taka, że żyjemy teraz bardzo szybko. Bardzo dużo tych interakcji i wpisywania danych. dzieje się w biegu, na telefonie. 

Więc jak nasz system może supportować w tym, żeby dane były wpisywane poprawnie?

 

Ilona: Albo jak już popełni błąd, to jak sobie nasza aplikacja z tym radzi…

 

No i właśnie w przypadku tego punktu sam Nielsen wyróżnił dwa typy błędu. Powiedział, że jednym typem błędów są błędy drobne, tzw. literówki. To takie rzeczy, które popełniamy, działając na autopilocie.

 

Potem mamy już poważniejsze błędy typu ominięcie jakiegoś pola, niepoprawne wpisanie frazy i próba jej wyszukania.

 

W takim wypadku interfejs może zareagować na dwa sposoby:  albo zwróci nam pustą wyszukiwarkę i powie, że takiej frazy nie ma, albo nas poprawi i zwróci wyniki wyszukiwania, które będą najbardziej podobne dla tej frazy, którą nasz użytkownik próbuje wpisać.

 

Zwróćcie więc uwagę np. na waszą wyszukiwarkę. W jaki sposób się zachowuje i jak sobie radzi z drobnymi błędami typu literówki, a jak z większymi.

 

Radek: Wpisujcie błędy i sprawdzajcie, co się dzieje w waszym systemie. 

 

Przewiduj błędy

 

Ilona: I tutaj też rozwinęłabym trochę ten punkt. Zapobieganie błędom jest super ważne, ale z drugiej strony zwykle jak testujemy swój produkt czy usługę, to przechodzimy tzw. happy path. Wtedy wszystko dzieje się dobrze. Wpiszemy wszystkie dane, bo przecież znamy ten produkt. Wiemy, że w tym formularzu trzeba wpisać takie i takie dane. 

 

Ale jeżeli chcecie samodzielnie zrobić audyt swojego systemu, to jest właśnie wyszukanie miejsc i celowe popełnianie błędów po to, żeby zobaczyć, jak nasz produkt radzi sobie z zarządzaniem błędami.

 

Pamiętajcie, że liczy się kontekst, w jakim odbiorcy korzystają z produktu i może być to na przykład w biegu. Szczególnie apki mobilne możemy klikać, przechodząc przez ulicę na światłach.

 

Radek: Więc zapisujemy listę potencjalnych błędów i testujemy czy nasz system pomoże nam je rozwiązać i uniknąć ich popełnienia. Sprawdzamy po prostu, jak bardzo ten system nas wspierał.

 

Ilona: Dokładnie, a w miejscach, w których potencjalnie mogą się pojawić błędy, bo albo o nich wiemy, albo mamy zgłoszenia z supportu… są takie rzeczy, które my jako UX już wymyśliliśmy. 

 

Na przykład podkreślenia, które pokazują, ile znaków powinniśmy wpisać, podając kod pocztowy, po tym jak wybierzemy kraj Polska. Numery kierunkowe telefonów, pesel — to też są rzeczy, które już wymyśliliśmy i warto takich fajnych praktyk się trzymać.

 

Radek: Myślę, że to jest jasne.

 

Czas na audyt!

Radek: Myślę, że na tym półmetku dzisiaj się zatrzymamy, dlatego, że pozostałe pięć heurystyk omówimy w kolejnym odcinku podcastu, który już niedługo.

Ilona: A teraz zadanie dla Was, drodzy słuchacze! Weźcie checklistę z pięcioma punktami, którą dołączyliśmy do tego odcinka, i spróbujcie przeprowadzić audyt swojego produktu cyfrowego. Jestem bardzo ciekawa, jak Wam to wyjdzie. Dziękuję za ten odcinek i do usłyszenia w kolejnym.

Radek: Do usłyszenia. Cześć.

 

Źródła:

• Jak przygotować się do redesignu?
• https://designzima.com/podcasts/jak-przygotowac-sie-do-redesignu/

• 10 Usability Heuristics for User Interface Design
• https://www.nngroup.com/articles/ten-usability-heuristics/

• https://www.nngroup.com/articles/signal-noise-ratio/ 
• Książka: The Mom Test i Don’t make me think – cytaty
• O Benchmarkozie, czyli kiedy patrzenie na konkurencję szkodzi
  

 

Zasubskrybuj nasz kanał i wykorzystuj naszą wiedzę do rozwijania swojego biznesu.