Projektowanie zorientowane na uŝytkownika

Transkrypt

1 Uniwersytet Jagielloński Interfejsy graficzne Wykład 2 Projektowanie zorientowane na uŝytkownika Barbara Strug 2011

2 Hall of shame

3 Hall of shame

4 Model wodospad

5 Feedback

6 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!!

7 Projektowanie iteracyjne

8 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

9 Model spiralny Projektowanie Ocena Implementacja

10 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.

11 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

12 Projektowanie dla uŝytkownika (2) 1. Analiza zadań 2. Rysunki 3. Prototypy papierowe 4. Wewnętrzne testy 5. Prototyp komputerowy 6. Ocena heurystyczna 7. Implementacja 8. Testowanie na uzytkownikach

13 Analiza uŝytkowników i zadań Pierwszy etap procesu analiza uŝytkownika : kim jest uŝytkownik analiza zadań : co uŝytkownicy potrzebują zrobić

14 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

15 Analiza uŝytkownika (3) Wiele aplikacji ma kilka klas uŝytkowników Przykład: szpital Lekarz Pielęgniarki Rejestracja Administracja Pacjenci Rodziny Administrator(-rzy)

16 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

17 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

18 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ć

19 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)

20 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

21 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?

22 Analiza zadań(4) Wywiady z uŝytkownikami Bezpośrednia obserwacja uŝytkowników

23 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

24 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)

25 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!

26 Participatory design Włącz przedstawicieli uŝytkowników do procesu projektowania W szpitalu lekarz/pacjent (czas!!)

27 Kolejny wykład Architektura interfejsu Podejście MVC