Professional Documents
Culture Documents
TOMASZ SKRSKI
UYTECZNO
R A P O R T
BADANIA UYTECZNOCI
O CO ZAPYTA SPECJALIST?
SPIS TRECI
Wstp
Streszczenie dokumentu
Geneza powstania
rdo
3
3 3 3
4
4 4 4 5
6 7
7 7
Uzyskaj przydatne i dokadne odpowiedzi
Wykorzystanie uzyskanych wynikw
Lista rzeczy do sprawdzenia
Robert Drzd
Tomasz Skrski
8 9 10
11 11
WSTP
Streszczenie dokumentu
Dokument jest zbiorem istotnych pyta, ktre powiniene zada swojemu dostawcy usug uytecznoci (usability) i wyjania czego szuka w jego odpowiedziach. Mona go uy jako kontrolnej listy podczas analizy zapyta ofertowych, formuowania SIWZ (Specykacja Istotnych Wymaga Zamwienia) i podczas rozmw ze specjalistami.
Geneza powstania
Coraz wicej rm tworzcych oprogramowanie, agencji interaktywnych i reklamowych, a take niezaleni konsultanci (freelancerzy) oferuj usug nazywan potocznie uytecznoci (usability) lub badaniem uytecznoci (usability testing). Poziom i jako oferowanych przez nich usug znaczco si od siebie rni. Zatrudnianie specjalisty, ktry wprowadzi w bd lub udzieli nieprzydatnych wskazwek sprawi, e badany przez Ciebie system (np. serwis www, system selfcare, aplikacja mobilna) wcale nie zostanie poprawiony. Informacje zawarte w niniejszym przewodniku powinny uatwi wybr profesjonalistw.
rdo
Niniejszy dokument zosta stworzony na podstawie rekomendacji UK Usability Professionals Association oraz dostosowany do lokalnych warunkw przez czonkw Usability Professionals Association: Roberta Drzda i Tomasza Skrskiego na przeomie sierpnia i wrzenia 2010 roku.
Kluczowe pytania
1.Jakie metody oceny uytecznoci (usability) swaciwe dla Twojego projektu? 2. Wedug jakich standardw bdzie si odbywao badanie i co zostanie ocenione? 3. Jacy uytkownicy wezm udzia w badaniu? 4. Czy otrzymane odpowiedzi bd pomocne i dokadne? 5. Jak przydatny bdzie dostarczony raport?
Z ostronoci naley podchodzi do ofert analiz ktre nie posiadaj zdeniowanej techniki bada. Ryzyko otrzymania niskiej jakoci raportu, z oglnymi opiniami, bez uzasadnie i konkretnych rekomendacji jest wwczas bardzo wysokie.
Badania z uytkownikami
Istnieje wiele podej do bada z uytkownikami: od diagnostycznych i analitycznych do pomiarw skutecznoci realizacji celw stawianych przed serwisem. W badananiach diagnostycznych rekomendujemy testy jeden do jednego, z moderatorem i badaczem obserwujcym uytkownika, ktry korzysta z badanego systemu i wykonuje postawione przed nim zadania. Zazwyczaj w trakcie takich bada uytkownicy s zachcani do opisywania swoich myli (gonego mylenia) nad kolejnymi krokami - co znane jest pod nazw Thinking Aloud Protocol. W wikszoci przypadkw moderator pracuje tylko z jednym badanym jednoczenie - nie rozpraszajc swojej uwagi pomidzy wiksz liczb uytkownikw.
Specjalici powinni przedstawi Ci podejcia najbardziej pasujce do Twoich oczekiwa, okreli parametry (metryki) wedug ktrych bdmierzy i przedstawi korzyci wynikajce z ich stosowania.
Zalecamy ostrono przy wyborze bada zdalnych, z uwagi na mniejsz skutecznoi kontrol przebiegu badania, zwaszcza dla bada niemoderowanych. Obecnie proponujemy przeprowadzanie zdalnych bada jedynie jako uzupenienie bada innego typu, a nie jako jedynego testu.
ZNAJOMOSTANDARDW
Dobry specjalista do spraw uytecznoci powinien wiedzie jak mierzy uyteczno. Poprzez mierzenie uytecznoci w czasie kadego badania, bdzie moliwe okrelenie czy twj system ulega poprawie czy nie. Najbardziej podstawow miar uytecznoci jest liczba uytkownikw ktra ukoczya postawione przed nimi zadanie. Istnieje rzecz jasna szereg innych, rwnie istotnych czynnikw, ktre mona mierzy.
Profesjonalny dostawca powinien wykorzystywaw swojej pracy wiedz i wskaniki zdeniowane przez organizacjInternational Standards Organisation (ISO) w ISO 9241, 13407 i innych.
Powszechnie przyjta denicja uytecznoci (wedug ISO 9241-11) zawiera w sobie efektywno (z ang. effectiveness - poziom ukoczenia zadania), wydajno (z ang. efciency - jak wiele wysiku zaja realizacja zadania) i satysfakcj (z ang. satisfaction - pozytywne nastawienie do produktu, brak dyskomfortu). Dostawca powinien zasugerowa sposb mierzenia tych elementw podczas badania uytkownikw. Innymi popularnymi mierzonymi parametrami s przyswajalno (z ang. learnability - wysiek i zasoby potrzebne do poznania systemu) i zapamitywalno (z ang. memorability - jak dobrze uytkownicy zapamitaj jak uywa systemu po jakim okresie czasu). Parametry te maj najwiksze znaczenie przy systemach z ktrych korzysta si czesto, takich jak serwisy intranetowe, bazy wiedzy oraz IVR (systemy telekomunikacyjne umoliwiajce interaktywn obsug osoby dzwonicej) Czsto s mierzone i traktowane jako cz wydajnoci i efektywnoci.
Specjalista powinien umie wykaza, e mierzenie okrelonego parametru ma sens tylko gdy istnieje podstawa do porwna - na przykad inny projekt graczny lub konkurencyjny serwis/usuga.
W kadym przypadku wyniki powinny co znaczy - subiektywne oceny takie jak serwis jest uyteczny dla 60% uytkownikw s bezuyteczne, tak dugo jak uyteczno nie zostanie okrelona bardziej precyzyjnymi wskanikami a 60% nie bdzie si odnosio do istniejcych kryteriw (benchmarkw). Jeli twoim celem jest raczej odwieenie (redesign) serwisu, ni proste badanie wydajnoci - wnioski, e 80% uytkownikw miao problemy z ukoczeniem zadania nie pomog Ci bez odpowiedzi na pytanie dlaczego tak si dzieje? i co powinienemzrobi?. Jednym ze standardw, do ktrego dostawca moe si stosowa jest ISO 9241-210:2010 (wczeniejsza wersja tego standardu to ISO 13407), ktre zbiera rzne aspekty uytecznoci w proces rozwoju oprogramowania nakierunkowany na uytkownika (user-centred development process).
Jeli chcesz tylko okreli problemy, wystarczy niewielka liczba uytkownikw. Jeli chcesz mierzy wydajno uytkownika w serwisie, potrzebujesz ich wicej.
Wyniki powinny koncentrowa si na tym, gdzie i dlaczego uytkownicy nie byli w stanie zrealizowa swoich zada oraz gdzie i dlaczego si frustrowali. Gdy mowa o tematach dla testu uytecznoci, radzimy ustali, tam gdzie to moliwe, oglne scenariusze, a nie konkretne zadania. Przykad scenariusza: Mylisz o tym aby kupi kwiaty na Dzie Matki - skorzystaj w tym celu ze strony. Przykad zadania: Wylij bukiet 10 lilii do Twojej mamy. Scenariusze daj wicej moliwoci dziaania (wczajc w to moliwo rezygnacji) ni zadania i s lepszym przyblieniem rzeczywistego zachowania. Uytkownicy czsto dziel si przemyleniami na temat korzystania z systemu. Najlepszym sposobem, aby je uzyska jest zadawanie im otwartych pyta, takich jak Co chcesz teraz zrobi?, Co tutaj zauwaasz?, albo Co wedug Ciebie stanie si, jeli to zrobisz?. Niewiele dadz pytania zamknite, takie jak Czy podoba Ci si ten formularz?, Czy bdziesz uywa tej funkcji? Rwnie wane jest, aby osoba prowadzca badanie nie dawaa uytkownikom podpowiedzi ani wskazwek. Na przykad, jeli na Twojej stronie znajduje si link Produkty, badacz nie powinien prosi, aby uytkownicy poszukali produktu, poniewa wyapi podpowied. Wyniki takiego badania nie bd do niczego przydatne. Najczciej celem badania jest uzyskanie oceny Twojego systemu bezporednio przed wdroeniem, albo uzyskanie wskazwek do przeprojektowania systemu. Jeli tak jest, upewnij si, e Twj dostawca moe wyj poza okrelenie, gdzie ludzie popeniali bdy i zacz opisywa, dlaczego tak si dzieje i jakie jest rozwizanie. Profesjonalny projekt badawczy prowadzi do spostrzee i rekomendacji, ktre da si zastosowa. Czasem, aby upewni si, e problem zosta rozwizany, warto przygotowa i dodatkowo zbada prototyp rozwiazujcy problem Twojego systemu.
Twoich przeoonych. Dlatego te sposb przekazania wnioskw musi by zrozumiay i pasowa do sytuacji, w ktrej si znajdujesz. Prezentacje wynikw mog si rni pod wzgldem tego, co wybierzesz, jaki zastosujesz format i w jaki sposb wykorzystasz pomoc dostawcy badania.
Jeli testy i projekty prowadzimy szybko, w sposb iteracyjny (np. Agile i SCRUM) - bogato ilustrowane raporty nie bd potrzebne. W takiej sytuacji dokadno i przydatno wynikw ma pierwszestwo nad sposobem ich dostarczenia. Sposb prezentacji zaley od natury Twojej organizacji i procesw w niej funkcjonujcych. Moe by tak, e deweloperzy maj cierpliwo i kompetencje, aby przebrn przez list wszystkich spostrzee i rekomendacji. Czsto jednak zareaguj lepiej jeli najpierw ich przeoeni dostan wyniki na wyszym poziomie abstrakcji. Typowymi elementami do zaprezentowania s: podsumowanie dotyczce priorytetowych problemw szczegowy dziennik obserwacji z okreleniem wanoci napotkanych bdw ilustracje znalezionych spostrzee - albo opisane zrzuty ekranu, albo nagrania wideo pokazujce dokadne miejsce, gdzie wystpi problem cytaty z wypowiedzi i komentarzy badanych diagramy i komentarze analityczne wyniki bada ilociowych w przypadku okrelonej prby propozycje rozwiza i rekomendacji, jeli istnieje potrzeba - w postaci makiet Wyniki bada bd najbardziej uyteczne, jeli pokaemy je w nastpujcej kolejnoci: streszczenie (executive summary) gwny raport analityczny surowe dane albo dzienniki obserwacji opisy metod badawczych. W akceptacji i popularyzacji wynikw bada przyda mog si atrakcyjnie zaprezentowane treci, takie jak nagranie video z uytkownikiem. Agencje badawcze rni si co do poziomu wsparcia dla klienta w komunikacji wynikw. Niektrzy po prostu dostarcz spisany raport. Bdziesz jednak czsto potrzebowa osobistej prezentacji. Cz specjalistw przeprowadza warsztaty na temat interpretacji wynikw, co zajmuje czasem nawet kilka spotka. To co wykracza poza opisany standard, powinno by traktowane jako usugi projektowe, a nie wycznie badawcze.
O AUTORACH
Robert Drzd Tomasz Skrski
O d ro k u 2 0 0 4 w r a m a c h s w o j e j r m y WebAudit.pl prowadzi audyty jakoci serwisw internetowych, projektuje rwnie architektur informacji. Pisze popularnego bloga na temat uytecznoci, marketingu oraz technologii (blog.webaudit.pl). Absolwent Szkoy Gwnej Handlowej. W wolnych chwilach biega, czyta ksiki (ostatnio na Kindle) i redaguje polsk Wikipedi.
Od 9 lat uczestniczy w projektach informatycznych w Polsce i za granic. Od dwch lat pracuje jako konsultant z dziedziny architektury informacji i user experience w ramach rmy 4UX.eu. Absolwent Wydziau Informatyki Politechniki Szczeciskiej. Prowadzi codziennego bloga, powiconego user experience - uxlabs.pl.
Kontakt
Robert Drzd e-mail: rd@webaudit.pl telefon: +48 608 335 233 www: http://www.webaudit.pl
Kontakt
Tomasz Skrski e-mail: tomasz@4ux.eu telefon: +48 502 584 014 www: http://4ux.eu