Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło 1
Użyteczność Obrazek zaczerpnięty z: http://my.opera.com/usability/blog/ 2
Użyteczność (ang. usability, web-usability) - nauka zajmująca się ergonomią interaktywnych urządzeń oraz aplikacji. W Polsce pojęcie użyteczności stosowane było często w odniesieniu do ergonomii serwisów WWW oraz aplikacji użytkowych. Użyteczność w ich przypadku skupia się na: intuicyjnej nawigacji, ułatwieniu skanowania w poszukiwaniu informacji, zapewnieniu zrozumiałej dla użytkownika komunikacji. Problemy z terminologią - funkcjonalność, użyteczność czy może używalność 3
Norma ISO 9241 ISO 9241 - Wymagania ergonomiczne dotyczące pracy biurowej z zastosowaniem terminali wyposażonych w monitory ekranowe (VDT). Składa się z 17. części: Part 1: General introduction Part 2: Guidance on task requirements Part 3: Visual display requirements Part 4: Keyboard requirements Part 5: Workstation layout and postural requirements Part 6: Guidance on the work environment Part 7: Requirements for display with reflections Part 8: Requirements for displayed colours Part 9: Requirements for non-keyboard input devices... 4
Norma ISO 9241... Part 10: Dialogue principles Part 11: Guidance on usability Part 12: Presentation of information Part 13: User guidance Part 14: Menu dialogues Part 15: Command dialogues Part 16: Direct manipulation dialogues Part 17: Form filling dialogues 5
Mierniki użyteczności Użyteczność stara się formalizować ocenę funkcjonalności wprowadzając mierniki użyteczności: 1. Skuteczność: czy udało się zrealizować zadanie? 2. Nauka obsługi: czy łatwo się jej nauczyć? 3. Ergonomia: po nauczeniu się, czy szybko się używa? 4. Pamiętalność - czy łatwo przypominamy sobie to czego się nauczyliśmy? 5. Błędy: czy błędów użytkownika jest niewiele i są odwracalne? 6. Satysfakcja: czy systemu używa się z przyjemnością? 6
Mierniki mają różną wagę... Wagi mierników zależą od aktualnego użytkownika: początkujący potrzebuje nauki obsługi sporadyczni użytkownicy pamiętalności zaawansowani ergonomii Niestety żadnego użytkownika nie da się ściśle przydzielić do jednej z kategorii: mamy do czynienia z ekspertami z dziedziny w ramach której działa aplikacja, którzy są początkujący w przypadku naszej aplikacji, niektóre elementy / właściwości systemu mogą być rzadko wykorzystywane. 7
Użyteczność to 'filozofia' Użyteczność z jednej strony jest nauką, a z drugiej filozofią zgodnie z którą czas/satysfakcja użytkownika są postawione na jednym z najważniejszych miejsc. W ramach użyteczności: stosujemy się do wytycznych na wszystkich etapach wytwarzania produktu szanujemy zdanie użytkownika wykonujemy testy tworzymy system zgodnie z pewnym procesem 8
Użyteczność czym NIE jest? Testowaniem użyteczności tuż przed wdrożeniem. Prostym stosowaniem zaleceń projektowych w fazie projektu. Prowadzeniem ewaluacji bez stosowanych zaleceń dotyczącym procesu. Własną wypracowaną metodą opartą na doświadczeniu lub heurystykach. Nie jest tylko kosmetyką, estetyką projektu. Własnością, która zależy tylko od produktu. 9
Co to jest test użyteczności? Podczas testu użyteczności pewna grupa reprezentatywnych użytkowników wykonuje przy pomocy systemu typowe z góry założone zadania. W tym samym czasie grupa obserwatorów wśród których są także programiści śledzi, słucha i robi notatki. Testy te oczywiście wykonuje się bardzo często wykonuje się nie na gotowych produktach, lecz ich prototypach. Sun's usability test labs in Menlo Park http://blogs.sun.com/designatsun/entry/sun_s_usability_test_labs 10
1. Czego oczekuje się po teście? Przed każdą iteracją testów użyteczności określa się oczekiwania od testu oraz wstępnie wyodrębnia się potencjalne problemy, które chcemy zweryfikować. Powinniśmy: Dzięki temu podczas testu możemy skoncentrować się na najważniejszych zagadnieniach. (Klasyczne zagadnienie problemu efektywnej pracy.) Dokładnie określić w jakim celu przeprowadzamy test. Traktować system jako całość pod względem biznesowym. Upewnić się, że system/prototyp jest gotowy do testów. Przygotować listę zadań do wykonania dla użytkowników. Przygotować listę odpowiednich kandydatów do testu (powinni nie znać systemu). Zaplanować jakie dane będziemy podczas testu notować. Jeżeli to możliwe przygotować test w środowisku pracy użytkownika, tak aby nie musiał zaznajamiać się z nową klawiaturą lub myszką. Nastawić się do bycia obiektywnym. 11
Nawiąż kontakt z osobą testującą. Spraw aby użytkownik czuł się swobodnie. 2. Podczas testu... Przedstaw podstawowe założenia testu. Wytłumacz użytkownikowi przede wszystkim, że testowany jest system, a nie on sam. Niech nie starają się zastanawiać jak system byłby użytkowany przez współpracowników. Zwróć się z prośbą aby podczas testu użytkownik głośno wyrażał swoje uwagi i odczucia. Nie pomagaj. W trakcie zwykłego użytkowania systemu Ciebie nie będzie. Pamiętaj, że nie na wszystkie pytania musisz znaleźć odpowiedź. Nie odbieraj uwag osobiście. Najprawdopodobniej podczas testu dowiesz się, że system nie jest doskonały. Podziękuj użytkownikowi. :-) 12
Co oznacza hmm podczas testu? 2. Słuchaj i Obserwuj! Zwracaj uwagę nawet na mimikę użytkownika i przypominaj o prośbie głośnego wyrażania odczuć i uwag. Notuj wszystkie obserwacje. Później opracowując raport uzupełnisz i posortujesz notatki. W trakcie nie przeszkadzaj ani nie zadawaj pytań o użyteczność. Dopiero po teście: Zadaj wszystkie pytania aby rozwiać wątpliwości. Teraz użytkownicy nie będą przez ciebie rozproszeni, a pamiętają jeszcze swoje odczucia. Przeanalizuj notatki i spróbuj je przełożyć na modyfikacje systemu. 13
3. Czego możemy dowiedzieć się podczas testu? W typowym przypadku podczas testu użyteczności: odkrywamy problemy związane z użytecznością produktu zbieramy ilościowe dane o wynikach osiągniętych przez testerów badamy satysfakcję użytkowników Wykonanie testu pozwala odpowiedzieć na szereg pytań: Czy uczestnicy są w stanie zrealizować scenariusze zadań? Zakładając zrealizowanie zadania, ile czasu im to zajęło? Zakładając zrealizowanie zadania, ile ekranów, kliknięć myszką itp. musiał wykonać uczestnik? Czy uczestnicy byli wystarczająco wydajni? Jak bardzo uczestnicy są usatysfakcjonowani? Jakie zmiany są potrzebne w systemie/serwisie aby poprawić jego użyteczność? W przypadku bardziej szczegółowych pytań mogą być to: Czy uczestnicy przeglądają strony w poszukiwaniu informacji czy używają funkcjonalności wyszukiwania? Jakich słów najczęściej wyszukują? Czy okno poszukiwania jest umiejscowione prawidłowo? itp... 14
Podstawowe zasady Wyróżnia się cztery główne zasady o, których trzeba pamiętać: Zasada 1. Testujesz system, a nie uczestników Co za niezgrabny uczestnik. Powinien nauczyć się posługiwać myszką. Zasada 2. Bardziej polegaj na informacji zmierzonej ilościowo, a nie na preferencjach Hej, ale użytkownikowi bardziej podobał się przycisk 'Szukaj' na dole ekranu. Zasada 3. Wykorzystuj zdobytą wiedzę W sumie, to dzisiaj uczestnicy niewiele nam pomogli. Nie ma co interpretować dzisiejszych wyników. Poczekajmy, może w następnym teście pójdzie lepiej. To co? Idziemy na piwo pod kotwicę? Zasada 4. Spróbuj znaleźć najlepsze rozwiązanie biorąc pod uwagę rzeczywistość swoją i użytkowników O rany! Aby zadowolić tych użytkowników i aby pracowali wydajnie to musielibyśmy go rozwijać przez najbliższe 2 lata! 15
Mierzalne kryteria testu użyteczności (...) Zasada 2. Bardziej polegaj na informacji zmierzonej ilościowo, a nie na preferencjach (...) Typowe kryteria testu użyteczności: Czas czas potrzebny na odszukanie informacji, czas potrzebny na wprowadzenie danych, czas samodzielnego rozwiązania błędu przez użytkownika, itp. Dokładność liczba bezproduktywnych wyborów związanych z nawigacją, zakończonych niepowodzeniem poszukiwań, błędów popełnionych podczas używania aplikacji, itp. Ogólny sukces Satysfakcja liczba wykonanych zadań zakończonych sukcesem, liczba wywołań systemu pomocy przez użytkowników, liczba odwołań do instrukcji, itp. może być mierzone poprzez wypełniany kwestionariusz, kryteria satysfakcji mogą dotyczyć całości systemu lub mogą być rozbite na mniejsze takie jak nawigacja, wyszukiwanie, jakość informacji, jakość prezentacji informacji, itp. 16
Do czego powinien prowadzić test? Zwiększenie prędkości przyswajania (uczenia się obsługi). Miernik: czas potrzebny użytkownikowi do osiągnięcia określonego poziomu zaawansowania? Aspekt ten jest najbardziej istotny w przypadku aplikacji używanych sporadycznie. Zwiększenie prędkości używania (ergonomia). Jak dużo czasu zajmuje zaawansowanemu użytkownikowi wykonanie określonego zadania? Szczególnie ważne kryterium w przypadku systemów intensywnie wykorzystywanych. (Przykład: System CRM, Kasjer na Poczcie, itp.) Minimalizacja popełniania błędów. W których miejscach i jak dużo błędów popełnia przeciętny użytkownik podczas typowej sesji z systemem? Wspomaganie szybkiego przypominania. Jak dużo czasu zajmuje sporadycznemu użytkownikowi przypomnienie sobie obsługi? Które elementy sprawiają najwięcej kłopotów? Podniesienie poziomu atrakcyjności. Jaka część użytkowników odbiera system pozytywnie? Ilu osobom podoba się system wizualnie? Które elementy systemu są najbardziej atrakcyjne? 17
Dlaczego potrzebujemy tylko 5 użytkowników? Procentowa liczba problemów z użytecznością znalezionych podczas testu: Żródło: http://www.useit.com/alertbox/20000319.html Użytkownicy w dużej części powtarzają te same błędy: im więcej użytkowników tym większe prawdopodobieństwo powtórzenia. Stosuj iteracyjny proces projektowania systemu (zamiast 15 użytkowników podczas jednego testu wykonaj trzy testy w różnych iteracjach). Testuj na większej liczbie użytkowników tylko gdy produkt jest skierowany do różnych grup odbiorców. Więcej na ten temat: http://www.useit.com/alertbox/20000319.html 18
Testowanie na podstawie scenariuszy Scenariusz: Szczegółowy, sekwencyjny, krok po kroku AKCJI wykonywanych przez UŻYTKOWNIKA do osiągnięcia CELU w interakcji z elementami interfejsu (przyciski, menu, itp.) w trakcie wykonywania określonego ZADANIA. w konkretnej sytuacji po konkretnymi warunkami w określonym przedziale czasowym będąc wspieranym przez system komputerowy AKCJA proste, pojedyncze, niepodzielne zadanie nie wymaga rozwiązywania problemów, dotyczy sprzętu lub oprogramowania CEL warunek kończący procedurę wykonywania ZADANIA ZADANIE sekwencja prostych akcji, których rezultatem jest osiągnięcie jakiegoś celu źródła: introspekcja, konferencje z użytkownikiem, obserwacje, analiza 19
Testowanie na podstawie scenariuszy Skrypt: Notatki: Ukończył Błędy Czas Podpowiedzi Uwagi! Włóż kartę bankową do terminala ATM. OK 5 s Wprowadź 8923 jako swój PIN. OK 1 10 s Nie wcisnął enter. Wybierz opcję wypłaty 110 PLN. OK 15 s Wybierz opcję Inna kwota.... 20
Bruce "Tog" Tognazzini is a principal with the Nielsen Norman Group, the "dream team" firm specializing in human-computer interaction. Tog was lead designer at WebMD, the supervertical start-up founded in February, 1996 by Jim Clark, founder of Silicon Graphics and Netscape. Before that, Tog was Distinguished Engineer for Strategic Technology at Sun Microsystems. During his 14 years at Apple Computer, he founded the Apple Human Interface Group and acted as Apple's Human Interface Evangelist. Tog has published two books, Tog on Interface and Tog on Software Design, both from Addison Wesley, and is currently publishing the free webzine, "AskTog." Bruce Tognazinni Podstawy projektowania interakcji 21
Wytyczne Bruce'a Tognazziniego Na podstawie tłumaczenia: http://www.eioba.pl/a2186/podstawy_projektowania_interakcji (Eryk 'eof' Orłowski) 1. Oczekiwania 2. Autonomia 3. Nierozpoznawanie kolorów 4. Spójność 5. Wartości domyślne 6. Efektywność użytkownika 7. Interfejsy dla odkrywców 8. Prawo Fitts ów 9. Obiekty interfejsu użytkownika 10. Redukcja opóźnienia 11. Łatwość uczenia 12. Użycie metafor 13. Ochrona pracy użytkowników 14. Czytelność 15. Śledzenie użytkownika 16. Widoczna nawigacja 22
Oczekiwania, Autonomia Oczekiwania zaspokojenie potrzeb użytkownika Autonomia swoboda = szybka nauka paradoks braku ograniczeń autonomia nie istnieje bez poczucia kontroli, a kontrola bez aktualnej informacji przez wiele lat system operacyjny Macintosh pokazywał użytkownikom ikonę kosza, którego stan napełnienia wskazywał na nadchodzącą eksplozję, nawet po skasowaniu pojedynczego pliku... 23
Nierozpoznawanie kolorów, Spójność Nierozpoznawanie kolorów nie wszyscy użytkownicy widzą kolory, lub nie widzą jednego ze składników: czerwonego, niebieskiego lub zielonego Spójność Poziomy spójności: 1. interpretacja zachowań użytkowników, 2. niewidoczne struktury, 3. niewielkie widoczne struktury, 4. ogólny wygląd aplikacji bądź usługi - ekrany powitalne (splash screens), 5. gama produktów, 6. spójność wewnętrzna, 7. spójność ogólna. 24
Niespójność, Niespójność wyróżnienie obiektów, które zachowują się odmiennie należy unikać uniformizacji obiektów odpowiedzialnych za różne zadania Najważniejsza jest spójność z oczekiwaniami użytkowników. Można ją zapewnić wyłącznie w drodze testów z udziałem użytkowników. 25
Wartości domyślne, Efektywność użytkownika Wartości domyślne powinny być łatwe do zmodyfikowania wartości domyślne powinny być adekwatne do oczekiwanych danych - unikaj sformułowań typu "domyślna wartość" w polach wartości Efektywność użytkownika ludzie kosztują znacznie więcej niż maszyny czas z punktu widzenia użytkownika, a nie maszyny (prędkość podgrzewania wody 1:10 czy 1:11) ankieta na dyskietkach czy papierowych formularzach 26
Efektywność użytkownika cd. Etykiety poleceń, menu etc. poprzedzaj słowami kluczowymi. Źle: Wstaw podział strony Dodaj stopkę Zaktualizuj spis treści Dobrze: Wstaw podział strony stopkę spis treści Dodatkowa informacja (dodaj, zaktualizuj) z lewego przykładu nie równoważy zalety szybkiego skanowania słów kluczowych. 27
Interfejsy dla odkrywców Interfejsy dla odkrywców Daj użytkownikom dobrze oznakowane drogi i pozwól włączyć napęd na cztery koła. Staraj się nie więzić użytkowników w zamkniętej ścieżce danej usługi - oferuj raczej linię najmniejszego oporu. Czasami konieczne jest dostarczanie rutynowych rozwiązań Wskazuj użytkownikom wyraźnie i w sposób dla nich intuicyjny, gdzie znajduje się punkt wejścia ("start"). Pozwalaj na odwracalność wykonywanych poleceń. Zawsze udostępniaj możliwość cofnięcia wydanych wcześniej poleceń. (zamiast: Czy na 100% chcesz usunąć dokument?) Badania dowiodły, że ludzie pracujący w "niebezpiecznym" środowisku popełniają dokładnie tyle samo błędów, ile popełniają w wyposażonym w odpowiednie zabezpieczenia. 28
Prawo Fitts ów, Obiekty interfejsu użytkownika Prawo Fitts ów Czas potrzebny do osiągnięcia celu jest funkcją odległości i rozmiaru celu. Koncepcja pokazywania wyśrodkowanych w pionie podmenu: Źródło obrazka: http://www.asktog.com/columns/022designedtogivefitts.html Obiekty interfejsu użytkownika Obiekty użytkownika to foldery, dokumenty, kosz. Pojawiają się w środowisku użytkownika i mogą, ale nie muszą być odzwierciedlone w obiektach kodu aplikacji. 29
Redukcja opóźnienia Redukcja opóźnienia - Kiedy to możliwe, używaj wielu wątków w celu uniknięcia latencji. potwierdzaj kliknięcia wszystkich przycisków wizualnie bądź dźwiękowo w ciągu 50 milisekund wyświetlaj klepsydrę dla zadań wykonujących się w czasie pomiędzy 50 milisekund do 1 sekundy animuj klepsydrę, pokazując, że system pracuje (nie zawiesił się) wyświetlaj informację o szacunkowym czasie wykonywania zadania trwającego dłużej niż 2 sekundy informuj o postępach procesu absorbuj uwagę użytkowników oczekujących na wykonanie dłużej trwających procesów, na przykład wyświetlając informację o aktualnie wykonywanej czynności bądź czasie pozostałym do zakończenia informuj użytkownika dźwiękowo o zakończeniu procesów trwających dłużej niż 10 sekund, aby mogli wykonywać inne zadania poza aplikacją i powrócić do niej w odpowiedniej chwili uniemożliwiaj wielokrotne naciśnięcia przycisków. Ponieważ interfejsy stron www reagują z opóźnieniem, użytkownicy często klikają wielokrotnie w celu wymuszenia reakcji, co powoduje dalsze opóźnienia. 30
Łatwość uczenia Łatwość uczenia W idealnej sytuacji produkty nie miałyby krzywej uczenia - użytkownicy korzystając z nich po raz pierwszy osiągaliby poziom eksperta natychmiast. W praktyce nawet najprostsze aplikacje charakteryzują się krzywą uczenia. Unikaj kompromisów. Użyteczność nie musi wykluczać łatwości uczenia i odwrotnie. Na początek zdecyduj, która wartość jest w danym przypadku istotniejsza i próbuj osiągnąć obie. Wzrost łatwości uczenia nie przychodzi jednak automatycznie wraz z łatwością użycia. 31
Użycie metafor, Ochrona pracy użytkowników Użycie metafor Rozważnie wybieraj metafory, powinny one umożliwić użytkownikowi szybkie pojęcie szczegółów modelu koncepcyjnego aplikacji. Dobre metafory są historiami, tworzącymi obrazy w wyobraźni użytkowników. Ochrona pracy użytkowników http://www.doradztwofinansowe.pl/ Upewnij się, że użytkownicy nie mogą utracić efektów swojej pracy w wyniku własnych błędów, błędów transmisji przez sieć, bądź z jakiegokolwiek innego powodu, który można przewidzieć bądź go uniknąć. 32
Czytelność, Śledzenie użytkownika Czytelność Zapewniaj czytelność tekstu poprzez wysoki kontrast, najlepiej czarnego fontu na jasnym tle. Unikaj szarego tła. Używaj wielkości fontów wystarczającej do swobodnego czytania tekstu na standardowych monitorach. Zwracaj szczególną uwagę na potrzeby osób starszych. Śledzenie użytkownika czy jest to pierwszy raz, kiedy użytkownik korzysta z aplikacji gdzie znajduje się użytkownik dokąd zmierza użytkownik gdzie użytkownik był w czasie sesji pracy z systemem gdzie był użytkownik przed opuszczeniem systemu 33
Widoczna nawigacja Widoczna nawigacja Unikaj niewidocznej nawigacji. Sieć www pełna jest serwisów wypełnionych wymyślnymi systemami menu, w efekcie niewidocznymi dla użytkownika. Użytkownicy często nie mają możliwości dowiedzieć się więcej ponad to, na jakiej stronie się znaleźli. Nawigacja powinna być maksymalnie uproszczona, przejrzysta i naturalna dla użytkownika. http://www.brillpublications.com/ 34
Interakcja Dziękuję za uwagę. Chcemy być coraz lepsi! Jeżeli coś cię zainteresowało napisz e-maila: robert@iem.pw.edu.pl Jeżeli coś cię bardzo znudziło napisz e-maila: robert@iem.pw.edu.pl Jeżeli zauważyłeś błąd napisz e-maila: robert@iem.pw.edu.pl 35