Projektowanie Graficznych Interfejsów Użytkownika Robert Szmurło

Projektowanie Graficznych Interfejsów
Użytkownika
Robert Szmurło
Użyteczność
Źródło obrazu: http://my.opera.com/usability/blog/
1
Użyteczność
(ang. usability, web-usability) - dziedzina zajmująca się ergonomią
interaktywnych urządzeń oraz aplikacji, której jednym z celów jest
formalna ocena jakości interfejsu
–
Mierniki użyteczności – zbiór kryteriów, które możliwie obiektywnie starają się ocenić
interfejs
–
Testy użyteczności – przeprowadzane koniecznie z udziałem docelowych odbiorców
badania
–
Ogólne wytyczne projektowe (zalecenia)
–
Udział użytkownika – zaangażowanie w proces wytwórczy (UCD lub HCD)
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ść”
2
Użyteczność to 'filozofia'
Użyteczność z jednej strony jest nauką, a z drugiej filozofią,
sposobem postępowania do projektowania interfejsu zgodnie, z
którym czas/satysfakcja użytkownika są postawione na jednym z
najważniejszych miejsc.
Postępując w zgodzie z Użytecznością:
–
stosujemy się do wytycznych na wszystkich etapach wytwarzania produktu od
analizy, projektu aż do implementacji,
–
szanujemy zdanie użytkownika (dane użytkownika, a nie integralność danych
systemu w każdym momencie są najważniejsze),
–
wykonujemy testy użyteczności (weryfikujemy przy udziale rzeczywistych
użytkowników jakość interfejsu),
–
tworzymy system zgodnie z pewnym procesem (staramy się podejść do projektu
metodologicznie w sposób iteracyjny),
–
angażujemy użytkownika w proces wytwarzania (konsultujemy bieżące postępy
projektu z odbiorcami systemu).
3
Cele Użyteczności w GUI
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? Systemy intensywnie wykorzystywane. (Przykład CRM, Kasjer na Poczcie,
itp.)
Minimalizacja popełniania błędów.
–
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?
Podniesienie poziomu atrakcyjności.
–
Jaka część użytkowników odbiera system pozytywnie? Ilu osobom podoba się
system wizualnie?
4
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?
- Stosunek zadań ukończonych do liczby wszystkich zadań.
2. Nauka obsługi: czy łatwo się jej nauczyć?
- Ile czasu zajmuje wykonanie poszczególnych zadań użytkownikowi, który ma do
czynienia z systemem po raz pierwszy.
- Jaki jest stosunek czasu wykonania poszczególnych zadań użytkownika podczas
pierwszego wykonywania zadania do ponownego.
3. Ergonomia: po nauczeniu się, czy szybko się używa?
- Jaki jest czas wykonania zadania po kliku lub kilkunastu operacjach.
4. „Pamiętalność” - czy łatwo przypominamy sobie to czego się nauczyliśmy?
- Jaki jest czas wykonania zadania przy powtórnym teście po pewnym czasie.
5. Błędy: czy błędów użytkownika jest niewiele i są odwracalne?
- Liczba błędów popełnianych przez użytkowników w trakcie wykonywania zadania.
Wprowadza się różne typy błędów: pomyłki użytkownika, cofnięcia operacji,
anulowanie operacji, komunikaty o błędach walidacji itp.
6. Satysfakcja: czy systemu używa się z przyjemnością?
- Określane na podstawie ankiety. Najbardziej subiektywny miernik związany z
użytecznością.
5
Mierniki mają różną wagę...
Wagi mierników zależą od aktualnego użytkownika:
–
początkujący użytkownicy potrzebują nauki obsługi,
–
sporadyczni użytkownicy „pamiętalności”,
–
zaawansowani ergonomii.
Niestety żadnego użytkownika nie da się na stałe 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,
–
zawsze znajdą się elementy / właściwości systemu, które będą rzadko wykorzystywane
nawet przez zaawansowanych użytkowników,
Nie możemy kategoryzować użytkowników na podstawie fizycznych
osób - Janina Kowalska, lecz na podstawie abstrakcyjnych ról, które
spełniają w systemie.
–
Obowiązuje tutaj analogia do aktorów w diagramach UML, gdzie aktorzy powinni być
rolami jakie pełnią fizyczne osoby w ramach systemu, np..: ankieter, dostawca,
kierownik działu sprzedaży, itp.
6
Użyteczność - element Inżynierii Oprogramowania
Projektanci oprogramowania
muszą zajmować się
wieloma aspektami systemu:
–
Funkcjonalność,
–
Wydajność,
–
Koszt,
–
Bezpieczeństwo,
–
Użyteczność,
–
Rozmiar,
–
Wiarygodność,
–
Standardy.
Wiele decyzji projektowy stanowi kompromis pomiędzy tymi
aspektami.
Podczas kursu przyjmiemy krańcową postawę:
Użyteczność będzie naszym podstawowym celem.
7
Źródła informacji...
Skąd czerpać informacje jak budować interfejs użytkownika aby
był efektywny, wygodny, estetyczny.
●
●
Norma ISO 9241
Wiedza heurystyczna (wytyczne projektowe, np.: Jacob
Nielsen, Bruce Tognazzini, własne doświadczenie)
●
Testy użyteczności (Usability Tests)
●
Budowanie prototypów z porzuceniem
●
Audyt profesjonalnych firm zajmujących się użytecznością
8
Przestarzała 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
●
...
9
Przestarzała 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
Postanowienia normy zawarte są zazwyczaj w dokumentach
Dotyczących wytycznych projektowych dla poszczególnych platform.
Obecnie to właśnie te dokumenty są dużo lepszym źródłem informacji.
Ogólnie: Google + user interface guidelines [android|windows 8|ios|Gnome]
Przegląd linków do dokumentów poszczególnych producentów:
http://usabilitygeek.com/official-usability-user-experience-user-interface-guidelines-from-companies/
10
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 często wykonuje
się na jeszcze nie gotowych
produktach,
na ich prototypach.
Sun's usability test labs in Menlo Park
http://blogs.sun.com/designatsun/entry/sun_s_usability_test_labs
11
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ć.
●
Dzięki temu podczas testu możemy skoncentrować się na najważniejszych
zagadnieniach.
Powinniśmy:
–
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.
12
2. Podczas testu...
Nawiązujemy kontakt z osobą testującą.
–
Spraw aby użytkownik czuł się swobodnie.
Przedstawiamy 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.
Zwracamy się z prośbą aby podczas testu użytkownik głośno wyrażał
swoje uwagi i odczucia.
Nie pomagamy.
–
W trakcie zwykłego użytkowania systemu Ciebie nie będzie.
Pamiętamy, że nie na wszystkie pytania musimy znaleźć odpowiedź.
„Nie bierzemy do siebie” uwag testerów.
–
Najprawdopodobniej podczas testu dowiesz się, że system nie jest doskonały.
Dziękujemy użytkownikowi. :-)
13
2. Słuchaj i Obserwuj!
Co oznacza „hmm” podczas testu?
–
Zwracaj uwagę nawet na mimikę użytkownika i przypominaj o prośbie głośnego
wyrażania odczuć i uwag.
Notujemy wszystkie obserwacje.
–
Później opracowując raport uzupełnisz i posortujesz notatki.
W trakcie nie przeszkadzamy ani nie zadajemy pytań o użyteczność.
Dopiero po teście:
–
Zadajemy wszystkie pytania aby rozwiać wątpliwości. Teraz użytkownicy nie zostaną
rozproszeni, a pamiętają jeszcze swoje odczucia.
–
Analizujemy i uzupełniamy notatki. Spróbuj się je przełożyć na potrzebne modyfikacje
systemu.
14
3. Czego możemy dowiedzieć się z 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...
15
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!”
16
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
●
–
Dokładność
●
–
czas potrzebny na odszukanie informacji, czas potrzebny na wprowadzenie danych, czas
samodzielnego rozwiązania błędu przez użytkownika, itp.
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
●
–
liczba wykonanych zadań zakończonych sukcesem, liczba wywołań systemu
pomocy przez użytkowników, liczba odwołań do instrukcji, itp.
Satysfakcja
●
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.
17
Ostateczny efekt testów Użyteczności?
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?
18
Potrzebujemy testu tylko dla 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
19
Testowanie na podstawie scenariuszy
Scenariusz:
–
Szczegółowy, sekwencyjny zbiór CZYNNOŚCI wykonywanych krok po kroku 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
CZYNNOŚĆ – 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 czynności, których rezultatem jest
osiągnięcie jakiegoś celu
–
źródła: introspekcja, konferencje z użytkownikiem, obserwacje, analiza wymagań
20
Testowanie na podstawie scenariuszy
●
Skrypt:
Czynność
–
–
–
Włóż kartę bankową do terminala
ATM.
Wprowadź 8923 jako swój PIN.
Wybierz opcję wypłaty 110 PLN.
●
Notatki:
Ukończył Błędy Czas Podpowiedzi
OK
OK
OK
Uwagi!
5s
1
Nie
wcisnął
enter.
10 s
15 s
Wybierz
opcję
„Inna
kwota”.
...
21
Użyteczność – typowe błędy!
–
Testowanie użyteczności tuż przed wdrożeniem.
Czyli w rzeczywistości ograniczenie użyteczności do samych testów użyteczności.
–
Proste stosowanie zaleceń projektowych w fazie projektu.
Powinniśmy konsultować projekt z użytkownikiem. Nie możemy polegać tylko na
własnej wiedzy.
–
Prowadzenie ewaluacji bez stosowanych zaleceń dotyczącym procesu.
Mamy większe szanse na sukces gdy będziemy wytwarzać produkt zgodnie z
pewnym procesem, który jest tak skonstruowany aby nie pominąć użyteczności.
–
Stosowanie wyłącznie własnej, wypracowanej metody opartej na
doświadczeniu lub heurystykach.
Musimy polegać na opinii użytkownika.
–
Użyteczność nie jest tylko kosmetyką, estetyką projektu.
Użyteczność to przede wszystkim wydajność i efektywność.
–
Własnością, która zależy tylko od produktu.
Użyteczność stosuje zależy przede wszystkim od użytkowników.
22
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
23
Wytyczne Bruce'a Tognazziniego
Na podstawie tłumaczenia:
http://www.eioba.pl/a2186/podstawy_projektowania_interakcji
(Eryk 'eof' Orłowski)
●
1. Oczekiwania
●
9. Obiekty interfejsu użytkownika
●
2. Autonomia
●
10. Redukcja opóźnienia
●
3. Nierozpoznawanie kolorów
●
11. Łatwość uczenia
●
4. Spójność
●
12. Użycie metafor
●
5. Wartości domyślne
●
13. Ochrona pracy użytkowników
●
6. Efektywność użytkownika
●
14. Czytelność
●
7. Interfejsy dla odkrywców
●
15. Śledzenie użytkownika
●
8. Prawo Fitts’ów
●
16. Widoczna nawigacja
24
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...
25
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.
26
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.
27
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
28
Efektywność użytkownika cd.
–
Etykiety poleceń, menu etc. poprzedzaj słowami kluczowymi.
Dobrze: Wstaw
Źle:
Wstaw podział strony
Dodaj stopkę
Zaktualizuj spis treści
–
podział strony
stopkę
spis treści
Dodatkowa informacja (dodaj, zaktualizuj) z lewego przykładu nie równoważy zalety
szybkiego skanowania słów kluczowych.
29
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.
30
Prawo Fittsa, Obiekty interfejsu użytkownika
Prawo Fittsa
–
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.
31
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.
32
Ł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.
33
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.
http://www.doradztwofinansowe.pl/
Microsoft Bob (rok 1995)
34
Ochrona pracy użytkowników
Ochrona pracy użytkowników
– 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ąć.
35
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
36
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/
37
Interakcja
Dziękuję za uwagę.
Chcemy być coraz lepsi!
Jeżeli coś cię zainteresowało napisz e-maila:
–
[email protected]
Jeżeli coś cię bardzo znudziło napisz e-maila:
–
[email protected]
Jeżeli zauważyłeś błąd napisz e-maila:
–
[email protected]
38