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