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
• 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!!
Problem z modelem „waterfall”
Projektowanie iteracyjne
• 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 iteracyjny - problem
Projektowanie
Ocena Implementacja
Model spiralny
• 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 iteracyjne w UI
• 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
Projektowanie dla u Ŝytkownika (2)
1. Analiza zadań2. Rysunki 3. Prototypy papierowe4. Wewnętrzne testy5. Prototyp komputerowy6. Ocena heurystyczna7. Implementacja8. Testowanie na uzytkownikach
• Pierwszy etap procesu� analiza uŜytkownika : kim jest uŜytkownik� analiza zadań : co uŜytkownicy potrzebują zrobić
Analiza u Ŝytkowników i zada ń
• 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 (2)
• Wiele aplikacji ma kilka klas uŜytkowników• Przykład: szpital
� Lekarz� Pielęgniarki� Rejestracja� Administracja� Pacjenci� Rodziny� Administrator(-rzy)
Analiza u Ŝytkownika (3)
• Technikiu Ankietau Wywiadu Obserwacja
• Przeszkodyu Projektanci i uŜytkownicy mogą być
odizolowani.u Wsparcie techniczne oddziela projektantów od
uŜytkownikówu Marketing oddziela uŜytkowników od
projektantówu Koszt kontaktu z niektórymi osobami jest
wysokis Lekarze, kierownictwo
Analiza u Ŝytkownika (4)
• 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
Przykład : kasa samoobsługowa
• 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 Wprowadzić produkt do kasyu Zapakować produktyu Zapłacić
Analiza zada ń
• Co ma być zrobione?� Cel
• Co naleŜy zrobić najpierw aby było to moŜliwe?� Warunki wstępne
u Zadania od których zaleŜą inne zadaniau Informacje jakie uŜytkownik musi mieć
• Jakie kroki są związane z wykonaniem tego zadania?� Podzadania� Podzadania mogą być dzielone rekurencyjnie
(dekompozycja)
Analiza zada ń (2)
• Cel� Wprowadzić produkt do kasy
• Warunki wstępne� Wszystkie produkty są juŜ w koszyku klienta
• Podzadania� Wprowadzenie produktów opakowanych� Wprowadzenie produktów luzem
Przykład : kasa
• 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 ń (3)
• Wywiady z uŜytkownikami• Bezpośrednia obserwacja uŜytkowników
Analiza zada ń(4)
• Powielenie złych praktyk/procedur w oprogramowaniu• NiedostrzeŜenie dobrych elementów aktualnej procedury• Niedokładna informacja od uŜytkowników
Analiza zada ń (5) - ryzyka
• 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 ń (6)
• 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!
Analiza zada ń (7)
• Włącz przedstawicieli uŜytkowników do procesu projektowania
• W szpitalu lekarz/pacjent (czas !!)
Participatory design
• Architektura interfejsu• Podejście MVC
Kolejny wykład