Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Audyt UX metodą wędrówki poznawczej

1,656 views

Published on

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

Published in: Design

Audyt UX metodą wędrówki poznawczej

  1. 1. 1
  2. 2. 2
  3. 3. 3 EKSPERCKI AUDYT UŻYTECZNOŚCI Tzw. Opportunity review ANALIZA MOŻLIWOŚCI/POTENCJAŁÓW BENCHMARKING
  4. 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. 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. 6
  7. 7. 7
  8. 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. 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. 10 Przykładowa lista kontrolna do audytu UX
  11. 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. 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. 13 Przykładowa ewaluacja heurystyczna – pojedyncza i z analizą konkurencji
  14. 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. 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. 16 User flow pozwalający ustalić procesy dla wybranej ścieżki
  17. 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. 18
  19. 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. 20
  21. 21. 21
  22. 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. 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. 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. 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. 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. 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. 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. 29 Google Analytics – analiza przepływów i porzuceń na stronie
  30. 30. 30 Hotjar– przykładowa clickmapa na stronie
  31. 31. 31 Lookback– nagranie sesji na stronie
  32. 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. 33 Przykładowa persona
  34. 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. 35 Przykładowy user flow procesu
  36. 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. 37 • Określenie wagi błędu - np. błąd kosmetyczny, poważny i krytyczny • Zawsze z perspektywy użytkownika, nie z biznesowej
  38. 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. 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. 40 Ogólne wrażenie • Czy interfejs wydaje się być przejrzysty? • Czy to, co widzę, zachęca mnie do interakcji?
  41. 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. 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. 43
  44. 44. 44
  45. 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. 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. 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. 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. 49
  50. 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. 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. 52 Youtube – pasek postępu wgrywania filmu + ładowanie poglądu
  53. 53. 53 Windows – stan pamięci systemu
  54. 54. 54 ASOS – okruszki (tzw. breadcrumbs); zrozumiała nawigacja
  55. 55. 55 Dribbble (przykład) – kroki w procesie składania zamówienia
  56. 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. 57 Mac OS– ikona kosza nawiązująca do codzienności
  58. 58. 58 Przykładowa aplikacja – nazewnictwo w menu
  59. 59. 59 Amazon– prosta komunikacja, dostosowana do użytkownika, zamiast nie zawsze zrozumiałego „FAQ”
  60. 60. 60 3 System powinien umożliwiać cofanie i przywracanie akcji i dawać użytkownikowi poczucie kontroli nad tym, co robi.
  61. 61. 61 IOS– łatwe cofanie i przywracanie akcji
  62. 62. 62 Gmail– możliwość cofnięcia akcji (+pomoc kontekstowa)
  63. 63. 63 4 Zachowaj konsekwencję w stosowaniu rozwiązań w obrębie danej strony.
  64. 64. 64 Insight Timer– niezrozumiałe ikony bez podpisu
  65. 65. 65 Aplikacje Google – spójne ikony
  66. 66. 66 Empik, Zalando, Piotr i Paweł – spójne umiejscowienie koszyka zakupowego
  67. 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. 68 Booking– nieaktywne daty z przeszłości
  69. 69. 69 Gmail – ostrzeżenie przed wysłaniem wiadomości bez załącznika
  70. 70. 70 InVision – ostrzeżenie przed usunięciem projektu, konieczność potwierdzenia
  71. 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. 72 Booking– podpowiadanie poprzednich wyszukiwań
  73. 73. 73 Amazon– historia ostatnio przeglądanych przedmiotów
  74. 74. 74 Quora– podpowiadanie możliwych pytań
  75. 75. 75 Windows 8 – ukryta opcja wyłączania komputera
  76. 76. 76 7 ,,Proste rzeczy powinny być proste, skomplikowane rzeczy powinny być możliwe.” (Alan Kay)
  77. 77. 77 Exchange– schowanie zaawansowanych ustawień
  78. 78. 78 Android– tzw. progressive disclosure
  79. 79. 79 Twitter– skróty klawiaturowe do szybszego poruszania się po aplikacji
  80. 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. 81 Absolvent.pl – Jasne i widoczne Call to Action na stronie głównej
  82. 82. 82 Twitter– Wyróżniona najczęstsza akcja użytkowników
  83. 83. 83 9 Błędy powinny być zrozumiałe dla użytkownika i umożliwiać znalezienie wyjścia z sytuacji.
  84. 84. 84 Jasne i zrozumiałe komunikaty, pozwalające naprawić błąd
  85. 85. 85 Windows 10 – komunikat błędu pozwalający zrozumieć sytuację
  86. 86. 86 Airbnb– strona 404 z pomocnymi linkami
  87. 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. 88 eBay– FAQ z przyjazną wyszukiwarką i kategoriami tematów
  89. 89. 89 Slack– onboarding użytkownika w aplikacji Slack
  90. 90. 90 Google – pomoc kontekstowa
  91. 91. 91
  92. 92. 92
  93. 93. 93 Źródło: Nielsen Norman Group, 2016 https://www.nngroup.com/articles/computer-skill-levels/
  94. 94. 94 26% dorosłych osób nie potrafi obsługiwać komputera.
  95. 95. 95 Źródło: Nielsen Norman Group, 2016 https://www.nngroup.com/articles/computer-skill-levels/
  96. 96. 96 Ty = Top 5-8% Ty potrafisz to zrobić. 92%–95% populacji nie potrafi
  97. 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. 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. 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. 100 Przykładowa persona
  101. 101. 101 Przykładowa proto-persona
  102. 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. 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. 104
  105. 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. 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. 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. 108
  109. 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. 110
  111. 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

×