Debugging Design [PL]

18
Debugging design Magdalena Ostoja-Chyżyńska mchyzynska WARSAW USABILITY FIX #1 28 JAN 2014

description

Introduction to quick Usability Testing. In Polish language. Presentation has been prepared for the first Usability Fix in Warsaw.

Transcript of Debugging Design [PL]

Page 1: Debugging Design [PL]

Debugging designMagdalena Ostoja-Chyżyńska

mchyzynska

WARSAW USABILITY FIX #1 28 JAN 2014

Page 2: Debugging Design [PL]

1. Testy ilościowe a jakościowe.

2. Dlaczego je robimy?

3. Optymalna liczba użytkowników do testów.

4. Przygotowanie i przeprowadzenie testu.

5. Po teście. I co dalej?

Page 3: Debugging Design [PL]

testowanie użyteczności

JakościoweIlościowe

Page 4: Debugging Design [PL]

Testy ilościowe

udowodnienie tezy

Czy nowa witryna jest lepsza od poprzedniej?

mierzenie współczynnika udanych prób i czasu wykonywania zadań

Testy jakościowe

pozyskiwanie informacji w celu ulepszenia projektu

można zmieniać protokół w trakcie

wywiad z moderatorem

nie występuje formalne zbieranie danych

Page 5: Debugging Design [PL]

“The information is in the people, not in your head.”

Edward T. Hall

Page 6: Debugging Design [PL]

Dlaczego to działa?

1. Nic nie jest doskonałe.

2. Poważne problemy łatwo jest znaleźć.

3. Obserwacja użytkowników jest cenna.

Page 7: Debugging Design [PL]

N (1-(1- L ) n )

N - liczba wszystkich problemów użyteczności interfejsuL - procent odnalezionych problemów po sesji z pojedynczym użytkownikiem (zazwyczaj L = 31%)

Page 8: Debugging Design [PL]

Przygotowanie do testu

Tworzenie zadań/scenariuszy1. wypisać główne funkcje strony

2. przepisać je na zadania

3. rozwinąć je do formatu scenariuszy

Układ tester/obserwator

Testujący powinien siedzieć przed komputerem.

Zadania powinny być wydrukowane 2 razy (dla użytkownika i dla Ciebie).

Opcjonalna zgoda na nagranie testu.

Obserwator nie powinien przytłaczać testera.

Page 9: Debugging Design [PL]

NAGRYWANIE WIDEO

Page 10: Debugging Design [PL]

rozpoczynamy test

ustawić neutralną stronę np. Google

,,Testujemy interfejs a nie Ciebie.’’

,,Nie martw się, że urazisz nasze uczucia…’’

nie na każde pytanie możesz/powinieneś odpowiadać

użytkownik może poprosić o przerwę w trakcie

włączyć nagranie (podpisana zgoda)

,,Nagranie zostanie użyte tylko w celu poprawy jakości strony.’’

wyczyścić historię przeglądarki

Page 11: Debugging Design [PL]

Thinking aloud protocol

?@#!

Page 12: Debugging Design [PL]

TesT: Część 11 min. ROZMOWA

rozmowa z użytkownikiem

Jakie strony oglądasz?

Jakie są twoje ulubione strony?

Ile godzin dziennie spędzasz na korzystaniu z Internetu?

Co robisz na co dzień?

Page 13: Debugging Design [PL]

Test: Część 22 min. WALIDACJA KONCEPTU STRONY GŁÓWNEJ

Co można na niej zrobić?

O czym jest?

Co Cię w niej uderza na pierwszy rzut oka?

Jak myślisz czyja to strona?

Użytkownik może przewijać stronę, lecz nie powinien opuszczać strony głównej.

Page 14: Debugging Design [PL]

“If I asked the people what they wanted, they would have said ‘Faster Horses’.

Henry Ford

Page 15: Debugging Design [PL]

Test: część 312 min. ZADANIA

Przed rozpoczęciem zadania powinieneś przeczytać głośno scenariusz użycia.

Ułóż całą historę, tak by osoba mogła z łatwością ,,wejść w buty” opisywanej osoby.

Właśnie zachorowałeś i chciałbyś udać się do lekarza pierwszego kontaktu, aby Cię zbadał i ocenił twój stan zdrowia.

Jeśli użytkownik nie może czegoś znaleźć możesz bardzo dyskretnie mu pomóc. (unikać)

Podziękować za test.

Być neutralnym!

Page 16: Debugging Design [PL]

I co dalej?

Wylistować 3 najpoważniejsze (według Ciebie) problemy interfejsu użytkownika.

Spotkać się z zespołem projektowym na lunch i omówić zauważone przez każdego najważniejsze problemy.

Znaleźć najłatwiejszy możliwy sposób na poprawienie najpoważniejszych 3 błędow.

Zaimplementować poprawki!

Page 17: Debugging Design [PL]

“The ability to simplify means to eliminate the unnecessary so that the necessary may speak.”

Hans Hofmann

Page 18: Debugging Design [PL]

Dziękuję za uwagę!

Magdalena Ostoja-Chyżyńska mchyzynska

Pamiętaj! Przeprowadzanie szybkich testów użyteczności jest dużo lepsze od nietestowania

niczego.