Prezentacja z warszatów o Audycie UX, przeprowadzonym dla Ladies that UX 15 listopada 2017.

1. 1

2. 2

3. 3
EKSPERCKI AUDYT UŻYTECZNOŚCI
Tzw. Opportunity review
ANALIZA MOŻLIWOŚCI/POTENCJAŁÓW
BENCHMARKING

4. 4
Miara wydajności, efektywności, i satysfakcji
z jaką dany produkt może być używany przez
określonych użytkowników dla osiągnięcia
określonych celów w określonym kontekście
użycia.

5. 5
Analiza ekspercka strony internetowej, aplikacji lub
systemu pod kątem wymagań i oczekiwań ze
strony użytkowników.
Audyt weryfikuje przede wszystkim użyteczność
analizowanego produktu, sprawdzając m.in. takie
elementy jak architektura informacji, nawigacja,
sposób interakcji czy treść.

6. 6

7. 7

8. 8
Szczegółowa lista wytycznych, jakie powinna
spełniać dana strona lub aplikacja
LISTA KONTROLNA
Sprawdzenie najczęstszych ścieżek
użytkowników pod kątem łatwości użycia
WĘDRÓWKA POZNAWCZA
Weryfikacja pod kątem 10 heurystyk
użyteczności Nielsena
ANALIZA HEURYSTYCZNA

9. 9
Długa lista cech i warunków, jakie powinien
spełniać serwis czy aplikacja. Zestaw zasad może
być opracowany samodzielnie przez zespół
badawczy, lub bazować na ogólnie dostępnych
źródłach, np. 247 zasadach webusability
opracowanych przez UserFocus.

10. 10
Przykładowa lista kontrolna do audytu UX

11. 11
ZALETY WADY
Przeprowadzana w oparciu o opracowaną
listę, analizę jest w stanie przeprowadzić
prawie każdy
Odgórnie narzucone zasady, brak
elastyczności
Łatwo jest znaleźć problemy z użytecznością Brak uwzględnienia kontekstu (!)
Brak konieczności opracowywania ścieżek dla
każdej strony
Ograniczenie co do ilości możliwych
przypadków

12. 12
Analiza heurystyczna jest metodą z inżynierii
użyteczności, polegającą na wykrywaniu
problemów z użytecznością w interfejsie systemu,
strony lub aplikacji.
Badanie to angażuje niewielki zespół badaczy
(sędziów), którzy analizują interfejs i oceniają jego
zgodność z wypracowanymi zasadami
użyteczności, tzw. heurystykami.

13. 13
Przykładowa ewaluacja heurystyczna – pojedyncza i z analizą
konkurencji

14. 14
ZALETY WADY
Określone rzeczy, na które należy zwrócić
uwagę
Konieczność bardzo dobrej znajomości
heurystyk i ich możliwych zastosowań
Zasady wyróżnione na podstawie wielu
testów użyteczności, określające
najpoważniejsze problemy użyteczności
Brak uwzględnienia kontekstu (!)
Ograniczenie co do ilości zasad, niektóre
problemy nie wpasowują się w żadną
heurystykę

15. 15
Metoda, w której badacz wciela się w rolę odbiorcy
i testuje system realizując typowe zadania
użytkownika.
W pierwszej kolejności tworzy się możliwe
scenariusze działań odbiorców, a następnie
realizuje kolejne czynności, sprawdzając tym
samym wszystkie możliwe procesy na stronie.

16. 16
User flow pozwalający ustalić procesy dla wybranej ścieżki

17. 17
ZALETY WADY
Uwzględnienie kontekstu użycia (!)
Brak określonych zasad, których należy się
trzymać
Ocena całych procesów, a nie tylko
pojedynczych ekranów
Problem z uwzględnieniem wszystkich
ścieżek w systemie
Połączenie perspektywy użytkownika z
perspektywą eksperta

18. 18

19. 19
Możliwość wyłapania podstawowych błędów użyteczności
Ewaluacja poprawność projektu,
np. spójności
Uzupełnienie badań z użytkownikami
Znalezienie możliwych szybkich zmian do wprowadzenia
Kompletny brak czasu lub pieniędzy na badania
z użytkownikami

20. 20

21. 21

22. 22
Ekspert nie jest użytkownikiem (!!!)
Możliwość pomyłki
Ekspert jest przeczulony na punkcie użyteczności
- znalezienie nieistniejących problemów
Strata czasu – analiza horrendalnie nieużytecznych
ekranów lub systemów
Ignorowanie rekomendacji, brak siły przebicia

23. 23
Wprowadzenie do metodologii
Dobre rozwiązania, nie tylko problemy
Obszary problemowe oznaczone na konkretnych
widokach ekranu
Podsumowanie najbardziej problematycznych
obszarów
Rekomendacje zmian (w formie pisemnej lub
jako propozycja w formie makiet)
Spis wszystkich błędów w jednym pliku wraz z wagą

24. 24
Analiza danych statystycznych strony lub
aplikacji, znalezienie miejsc, w których
następują porzucenia, analiza grupy
docelowej.
ANALIZA STATYSTYK
Zapoznanie się ze standardami i dobrymi
praktykami w danym obszarze lub branży.
BENCHMARKING KONKURENCJI

25. 25
Rozpisanie scenariuszy głównych ścieżek
użytkowników na stronie lub aplikacji z
uwzględnieniem tzw. edge case’ów. Podział
ścieżek na różne grupy docelowe.
OKREŚLENIE GŁÓWNYCH ŚCIEŻEK UŻYTKOWNIKÓW
Analiza produktu pod kątem użyteczności na
podstawie ścieżek użytkowników i
znajomości zasad użyteczności (w tym
heurystyk).
ANALIZA OBSZARÓW PROBLEMOWYCH
Określenie grup docelowych oraz
użytkowników danego produktu na
podstawie wywiadów z interesariuszami,
analizy danych oraz ew. dodatkowych
badań.
PRZYGOTOWANIE PERSON

26. 26
Stworzenie rekomendowanych zmian na
podstawie znalezionych problemów
użyteczności. Przygotowanie rekomendacji w
formie pisanej lub w formie makiet.
STWORZENIE REKOMENDACJI
Określenie wagi problemów, od błędów
wywołujących irytację do takich, które
całkowicie lub poważnie uniemożliwiają
zrealizowanie zadania.
NADANIE HIERARCHI OBSZAROM PROBLEMOWYM
Wypunktowanie najpoważniejszych i
najczęściej pojawiających się problemów na
stronie lub w aplikacji.
PODSUMOWANIE NAJWAŻNIEJSZYCH PROBLEMÓW

27. 27
• Zapoznanie się ze standardami zewnętrznymi
• Analiza dobrych i złych rozwiązań z danego obszaru lub
branży
• Poznanie bezpośredniej i pośredniej konkurencji
• Możliwość odwołania się w raporcie do rozwiązań i strategii
konkurencyjnych

28. 28
• Zebranie statystyk odnośnie przepływów na stronie lub w
aplikacji
• Analiza konwersji
• Znalezienie miejsc, w których użytkownicy porzucają stronę
• Analiza grupy docelowej – demografia, urządzenia,
lokalizacja, zachowania na stronie

29. 29
Google Analytics – analiza przepływów i porzuceń na stronie

30. 30
Hotjar– przykładowa clickmapa na stronie

31. 31
Lookback– nagranie sesji na stronie

32. 32
• Wybranie najważniejszych grup docelowych
• Przygotowanie opisu grupy docelowej na podstawie statystyk
oraz wiedzy od klienta
• Analiza zachowań, celów i potrzeb grupy w kontekście
analizowanego produktu
• Uspójnienie wiedzy o personach w obrębie zespołu

33. 33
Przykładowa persona

34. 34
• Określenie najważniejszych ścieżek użytkowników z
podziałem na grupy docelowe
• Dokładna analiza przepływu ścieżek
• Ogólny opis zadań w obrębie danego ekranu, bez
wchodzenia w szczegóły [na tym etapie]

35. 35
Przykładowy user flow procesu

36. 36
• Opisanie obszarów problemowych w kilku zdaniach, z
oznaczeniem ich na zrzutach ekranu
• Wyjaśnienie, dlaczego dane miejsce na stronie może
powodować problemy - perspektywa użytkownika!
• Odwołanie do heurystyk i innych zasad użyteczności tam,
gdzie to możliwe

37. 37
• Określenie wagi błędu - np. błąd kosmetyczny, poważny i
krytyczny
• Zawsze z perspektywy użytkownika, nie z biznesowej

38. 38
• Ponowne przejście przez obszary problemowe i
przygotowanie rekomendacji zmian do wdrożenia
• Możliwość przedstawienia kilku różnych propozycji zmian
tego samego obszaru
• Wyjaśnienie, jak dane rozwiązanie może pomóc
użytkownikowi lepiej zrealizować zadanie na stronie
• Rozróżnienie rekomendacji od “Nice-to-have”
• Przygotowanie rekomendacji w formie pisemnej lub popartej
makietami

39. 39
• Przygotowanie podsumowania z najważniejszymi i
najczęściej występującymi problemami
• Spojrzenie na produkt “z lotu ptaka”
• Podkreślenie i podsumowanie dobrych cech i rozwiązań
produktu
• Opcjonalne, ale przydatne: Spis wszystkich błędów wraz z
kodami i wagą - np. w Excelu

40. 40
Ogólne wrażenie
• Czy interfejs wydaje się być
przejrzysty?
• Czy to, co widzę, zachęca mnie do
interakcji?

41. 41
Ogólne wrażenie
Architektura
informacji
• Czy jestem w stanie łatwo znaleźć
poszukiwane informacje?
• Czy strona nie zawiera zbędnych
elementów?
• Czy interfejs wydaje się być
przejrzysty?
• Czy to, co widzę, zachęca mnie do
interakcji?

42. 42
Ogólne wrażenie
Architektura
informacji
Interakcje
• Czy interakcje są zrozumiałe?
• Czy wiem, jakie akcję muszę wykonać
aby zrealizować swój cel?
• Czy jestem w stanie łatwo znaleźć
poszukiwane informacje?
• Czy strona nie zawiera zbędnych
elementów?
• Czy interfejs wydaje się być
przejrzysty?
• Czy to, co widzę, zachęca mnie do
interakcji?

43. 43

44. 44

45. 45
Np. projektant, badacz, deweloper i strateg
OSOBY Z RÓŻNYCH DZIAŁÓW
1-2 GODZINY SESJI NA BADACZA
ZESPÓŁ ZŁOŻONY Z 2-4 OSÓB

46. 46
Liczba znalezionych problemów użyteczności przez 19 badaczy
Źródło: https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/

47. 47
Liczba sędziów a procent znalezionych problemów użytecznościowych
Źródło: https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/

48. 48
Stosunek kosztu do ilości sędziów a korzyści
Źródło: https://www.nngroup.com/articles/how-to-conduct-a-heuristic-evaluation/

49. 49

50. 50
10 heurystyk stworzonych przez Jakoba Nielsena ok.
1990 roku. Opracowane zostały na podstawie
ogromnej ilości badań użyteczności. Zasady te są
aktualne do dzisiaj i są uznawane za dekalog
projektanta UX.

51. 51
1
System powinien zawsze w jasny sposób
informować użytkownika w jakim miejscu się
znajduje oraz co aktualnie dzieje się z systemem.

52. 52
Youtube – pasek postępu wgrywania filmu + ładowanie poglądu

53. 53
Windows – stan pamięci systemu

54. 54
ASOS – okruszki (tzw. breadcrumbs); zrozumiała nawigacja

55. 55
Dribbble (przykład) – kroki w procesie składania zamówienia

56. 56
2
System powinien być zrozumiały dla użytkownika,
używać jasnych komunikatów oraz stosować
określenia przyjęte w codziennym życiu.

57. 57
Mac OS– ikona kosza nawiązująca do codzienności

58. 58
Przykładowa aplikacja – nazewnictwo w menu

59. 59
Amazon– prosta komunikacja, dostosowana do użytkownika,
zamiast nie zawsze zrozumiałego „FAQ”

60. 60
3
System powinien umożliwiać cofanie i przywracanie
akcji i dawać użytkownikowi poczucie kontroli nad
tym, co robi.

61. 61
IOS– łatwe cofanie i przywracanie akcji

62. 62
Gmail– możliwość cofnięcia akcji (+pomoc kontekstowa)

63. 63
4
Zachowaj konsekwencję w stosowaniu rozwiązań w
obrębie danej strony.

64. 64
Insight Timer– niezrozumiałe ikony bez podpisu

65. 65
Aplikacje Google – spójne ikony

66. 66
Empik, Zalando, Piotr i Paweł – spójne umiejscowienie koszyka zakupowego

67. 67
5
System powinien chronić użytkownika przed
popełnianiem błędów zapobiegając im wszędzie,
gdzie to możliwe.

68. 68
Booking– nieaktywne daty z przeszłości

69. 69
Gmail – ostrzeżenie przed wysłaniem wiadomości bez załącznika

70. 70
InVision – ostrzeżenie przed usunięciem projektu, konieczność
potwierdzenia

71. 71
6
Użytkownik nie powinien być zmuszony do
zapamiętywania części informacji pomiędzy
ekranami. Instrukcje jak korzystać z systemu
powinny być widoczne i powinien być do nich łatwy
dostęp.

72. 72
Booking– podpowiadanie poprzednich wyszukiwań

73. 73
Amazon– historia ostatnio przeglądanych przedmiotów

74. 74
Quora– podpowiadanie możliwych pytań

75. 75
Windows 8 – ukryta opcja wyłączania komputera

76. 76
7
,,Proste rzeczy powinny być proste, skomplikowane
rzeczy powinny być możliwe.” (Alan Kay)

77. 77
Exchange– schowanie zaawansowanych ustawień

78. 78
Android– tzw. progressive disclosure

79. 79
Twitter– skróty klawiaturowe do szybszego poruszania się po aplikacji

80. 80
8
System nie powinien zawierać zbędnych informacji
lub elementów, utrudniających dostęp do
kluczowych i poszukiwanych treści.

81. 81
Absolvent.pl – Jasne i widoczne Call to Action na stronie głównej

82. 82
Twitter– Wyróżniona najczęstsza akcja użytkowników

83. 83
9
Błędy powinny być zrozumiałe dla użytkownika i
umożliwiać znalezienie wyjścia z sytuacji.

84. 84
Jasne i zrozumiałe komunikaty, pozwalające naprawić błąd

85. 85
Windows 10 – komunikat błędu pozwalający zrozumieć sytuację

86. 86
Airbnb– strona 404 z pomocnymi linkami

87. 87
10
Nawet jeśli system powinien być móc obsługiwany bez
dokumentacji, czasem może być konieczne aby
zapewnić pomoc. Takie informacje powinny być łatwe
do znalezienia, kontekstowe, przedstawiać konkretne
kroki do wykonania i nie zajmować zbyt dużo miejsca.

88. 88
eBay– FAQ z przyjazną wyszukiwarką i kategoriami tematów

89. 89
Slack– onboarding użytkownika w aplikacji Slack

90. 90
Google – pomoc kontekstowa

91. 91

92. 92

93. 93
Źródło: Nielsen Norman Group, 2016
https://www.nngroup.com/articles/computer-skill-levels/

94. 94
26% dorosłych osób
nie potrafi obsługiwać
komputera.

95. 95
Źródło: Nielsen Norman Group, 2016
https://www.nngroup.com/articles/computer-skill-levels/

96. 96
Ty = Top 5-8%
Ty potrafisz to zrobić. 92%–95%
populacji nie potrafi

97. 97
• Niewielka ilość/brak nawigacji niezbędnej do uzyskania
informacji
• Kilka kroków w procesie i minimalna liczba operacji
• Rozwiązywanie problemu, w którym respondent musi
zastosować tylko jednoznaczne kryteria (brak ukrytych
kryteriów)
• Niewielka konieczność monitorowania postępu i reakcji
systemu
• Brak konieczności zestawiania lub łączenia informacji

98. 98
Proto-persona reprezentuje wybraną grupę
docelową naszego produktu lub usługi i zawiera w
sobie opis tej grupy pod kątem jej celów, zachowań
i potrzeb.
Proto-persony są naszym najlepszym
przypuszczeniem w zrozumieniu kto używa (lub
będzie używał) naszego produktu, i dlaczego.

99. 99
W przeciwieństwie do standardowych person, proto-persony
oparte są o założenia, które powinny zostać następnie
zweryfikowane.
• Są prostsze i zawierają mniej informacji o umiejętnościach
danej grupy, demografii czy technologiach, z których ona
korzysta
• Wynikają z dostępnej wiedzy oraz intuicji, a nie z
pogłębionych badań
• Tworzone są przeważnie w ramach pracy grupowej, dzięki
czemu zespół buduje spójną wizję docelowego użytkownika

100. 100
Przykładowa persona

101. 101
Przykładowa proto-persona

102. 102
• Lepsze zrozumienie grupy docelowej przez wszystkich
członków zespołu oraz pomiędzy zespołem a klientem
• Fundament do bardziej merytorycznych i obiektywnych
dyskusji
• Budowanie empatii wobec użytkownika końcowego
• Pomagają podejmować decyzje projektowe na podstawie
potrzeb i celów grupy docelowej, a nie wizji projektanta

103. 103
• 24 lata
• Mieszka w Warszawie, w wynajmowanej kawalerce
• Student zarządzenia na SGH
• Pracuje dorywczo jako kelner w restauracji
• Dużo podróżuje komunikacją miejską i lubi słuchać
muzyki na telefonie
• Nie lubi pobierać piosenek na telefon, ponieważ
zajmują za dużo pamięci
• Uważa, że ściąganie muzyki z Internetu jest nie fair
• Lubi dzielić się ze swoją dziewczyną fajnymi zespołami
• Tworzy playlisty na różne okazje
• Chce móc w łatwy sposób dzielić się muzyką
• Chce w łatwy sposób odkrywać nowe zespoły,
pasujące do jego gustu muzycznego
• Chciałby, żeby aplikacja nie była zbyt droga, ponieważ
nie zarabia dużo
• Chce mieć muzykę w każdej chwili pod ręką
Proto-persona na przykładzie aplikacji Spotify

104. 104

105. 105
Technika polegająca na rozbiciu głównych ścieżek
użytkowników na pojedyncze kroki, pozwalające na
dokładniejszą analizę problemów, potencjałów i
ewentualnych potrzeb występujących na każdym
kroku.
W technice tej skupiamy się głownie na tym, CO
zrobi użytkownik, a mniej na tym JAK może to
zrobić.

106. 106
Jako forma podsumowania lub planowania badań
użyteczności
Podstawa do projektowania makiet, user flowów
i wireframe’ów
Jako rodzaj Customer Journey Map
Przy audytach użyteczności

107. 107
Wejście na
stronę główną
Wyszukanie
konkretnej
piosenki
Odsłuchanie
utworu
Dodanie utworu
do listy
ulubionych
Przełączenie na
kolejny utwór z
listy
podpowiedzi
Zapoznanie się z
proponowanymi
utworami
Przeglądanie
wyników
wyszukiwania w
poszukiwaniu
pasującego utworu
Wybranie
odpowiedniej
playlisty

108. 108

109. 109
Audyt powinien być zaprezentowany w przystępnej
formie, łatwej do zrozumienia
Audyt UX to nie wyklejanie karteczek, ale mozolna,
często wielogodzinna praca, wymagająca dużej
skrupulatności i wnikliwości
Audyt powinien być przeprowadzony przez większą
ilość osób w zespole
Audyt powinien być jedynie uzupełnieniem badań z
użytkownikami, a nie je zastępować

110. 110

111. 111
Jeśli masz jakieś pytania, chcesz wiedzieć więcej lub przesłać mi zadanie domowe – zapraszam
do pozostania w kontakcie ☺
Facebook
Kaja Laura Toczyska
LinkedIn
in/kajatoczyska
Email
kaja.toczyska@gmail.com
Mój blog
uxkwadrat.pl