Interfejsy graficzne Projektowanie zorientowane na uŜytkownika

Uniwersytet Jagielloński
Interfejsy graficzne
Wykład 2
Projektowanie zorientowane
na uŜytkownika
Barbara Strug
2011
Hall of shame
Hall of shame
Model „wodospad”
Feedback
Problem z modelem „waterfall”
• Projektowanie interfejsów jest ryzykowne
• Łatwo zrobić to źle.
• UŜytkownicy nie biorą udziału w walidacji aŜ do
momentu testów akceptacyjnych.
• Zatem aŜ do końca nie dowiemy się o błędach.
• Błędy w UI często powodują zmiany w opisie
wymagań i w projekcie.
• Musimy zatem wyrzucić dobre i przetestowane
fragmenty kodu!!
Projektowanie iteracyjne
Model iteracyjny - problem
• KaŜda iteracja odpowiada pewnemu produktowi
• Ocena (uwagi krytyczne) są przekazywane do
kolejnej wersji projektu
• Wykorzystujemy (płacących) klientów do oceny
funkcjonalności interfejsu
• Nie będzie im się to podobać
• Nie kupią kolejnej wersji
Model spiralny
Projektowanie
Ocena
Implementacja
Projektowanie iteracyjne w UI
• Wczesne iteracje uŜywają tanich prototypów
MoŜliwe jest projektowanie równoległe (wiele prototypów
pozwala zbadać alternatywy)
• Późniejsze iteracje, po wyeliminowaniu
ryzyka UI, uŜywają bardziej zaawansowanych
implementacji
• Więcej iteracji oznacza zazwyczaj lepszy
interfejs
• Na zewnątrz wychodzą tylko „dojrzałe”
iteracje.
Projektowanie dla uŜytkownika
• Projektowanie iteracyjne
• Zorientowanie na uŜytkownika i zadania na
wczesnym etapie projektu
analiza uŜytkownika : kim jest uŜytkownik
analiza zadań : co uŜytkownicy potrzebują zrobić
włączenie uŜytkowników jako osoby oceniające,
konsultantów, a czasami takŜe projektantów
• •Ciągła ocena
UŜytkownicy biorą udział w kaŜdej iteracji
KaŜdy prototyp jest jakoś oceniany
Projektowanie dla uŜytkownika (2)
1.
2.
3.
4.
5.
6.
7.
8.
Analiza zadań
Rysunki
Prototypy papierowe
Wewnętrzne testy
Prototyp komputerowy
Ocena heurystyczna
Implementacja
Testowanie na uzytkownikach
Analiza uŜytkowników i zadań
• Pierwszy etap procesu
analiza uŜytkownika : kim jest uŜytkownik
analiza zadań : co uŜytkownicy potrzebują zrobić
Analiza uŜytkownika (2)
• Określ cechy charakterystyczne docelowego
uŜytkownika
Wiek, płeć, narodowość
Wykształcenie
MoŜliwości fizyczne
Doświadczenie w uŜytkowaniu komputera
Umiejętności (pisanie na maszynie, czytanie?)
Doświadczenie w danej dziedzinie
Doświadczenie z dana aplikacją
Środowisko pracy /kontekst społeczny
Wzorce komunikacyjne
Analiza uŜytkownika (3)
• Wiele aplikacji ma kilka klas uŜytkowników
• Przykład: szpital
Lekarz
Pielęgniarki
Rejestracja
Administracja
Pacjenci
Rodziny
Administrator(-rzy)
Analiza uŜytkownika (4)
• Techniki
u
u
u
Ankieta
Wywiad
Obserwacja
• Przeszkody
u
u
u
u
Projektanci i uŜytkownicy mogą być
odizolowani.
Wsparcie techniczne oddziela projektantów od
uŜytkowników
Marketing oddziela uŜytkowników od
projektantów
Koszt kontaktu z niektórymi osobami jest
wysoki
s
Lekarze, kierownictwo
Przykład : kasa samoobsługowa
• Kim są uŜytkownicy?
Zwykli kupujący
Szeroki zakres wieku (10-80) i moŜliwości fizycznych
(wzrost, ograniczenia ruchowe, siła)
śadnego doświadczenie z uŜyciem komputera
śadnego szkolenia: po prostu wchodzą
Znajomość sprzedawanych produktów, ale nie systemu
magazynowego sklepu
Kupujący często proszą się nawzajem o pomoc w
znalezieniu róŜnych produktów
• Klasy uŜytkowników
Zakupy często robione przez kobiety, często z małymi
dziećmi
Pracownicy sklepu pomagający klientom
Analiza zadań
• Określ indywidualne zadania jakie problem
moŜe rozwiązać
• KaŜde zadanie jest celem (co, ale nie jak)
• Często warto zacząć od określenia ogólnego
celu systemu, a potem podzielić go
hierarchicznie
• Cel ogólny : klienci płaca za produkty
Zadania:
u
u
u
Wprowadzić produkt do kasy
Zapakować produkty
Zapłacić
Analiza zadań (2)
• Co ma być zrobione?
Cel
• Co naleŜy zrobić najpierw aby było to
moŜliwe?
Warunki wstępne
u
u
Zadania od których zaleŜą inne zadania
Informacje jakie uŜytkownik musi mieć
• Jakie kroki są związane z wykonaniem tego
zadania?
Podzadania
Podzadania mogą być dzielone rekurencyjnie
(dekompozycja)
Przykład : kasa
• Cel
Wprowadzić produkt do kasy
• Warunki wstępne
Wszystkie produkty są juŜ w koszyku klienta
• Podzadania
Wprowadzenie produktów opakowanych
Wprowadzenie produktów luzem
Analiza zadań (3)
• Gdzie jest wykonywane zadanie?
Przy wyjściu z marketu, na stojąco
• Jak często zadanie jest wykonywane?
Co najwyŜej kilka razy w tygodniu
• Jakie są ograniczenia czasowe/inne zasoby?
Minuta lub dwie
• Jak uŜytkownik poznaje/uczy się zadania?
Próbując
Obserwując innych
Z pomocą personelu
• Co moŜe pójść źle?
•
Kod paskowy uszkodzony lub brakujący
Ktoś kupuje alkohol lub papierosy
Kto jeszcze bierze udział w zadaniu?
Analiza zadań(4)
• Wywiady z uŜytkownikami
• Bezpośrednia obserwacja uŜytkowników
Analiza zadań (5) - ryzyka
• Powielenie złych praktyk/procedur w oprogramowaniu
• NiedostrzeŜenie dobrych elementów aktualnej procedury
• Niedokładna informacja od uŜytkowników
Analiza zadań (6)
• Pytania do zadania uŜytkownikom
Dlaczego to robicie? (cel)
Jak to robicie? (podzadanie)
• Poszukaj słabości/problemów w aktualnej sytuacji
Problemy z celem, marnowanie czasu, niezadowolenie
uŜytkowników
• Badanie kontekstu
• Projektowanie włączające ( Participatory design)
Analiza zadań (7)
• Obserwuj uŜytkowników wykonujących rzeczywiste
zadania w rzeczywistej sytuacji
Bądź konkretny
UŜytkownik pokazuje co i jak robi
Prowadzący wywiad obserwuje i zadaje pytania
• Odrzuć/zbadaj załoŜenia i przygotuj się na
niespodzianki!
Participatory design
• Włącz przedstawicieli uŜytkowników do procesu
projektowania
• W szpitalu lekarz/pacjent (czas !!)
Kolejny wykład
• Architektura interfejsu
• Podejście MVC