W polskich badaniach użyteczności przyjęło się określać badanie eksperckie serwisu albo aplikacji nazwą „audytu”. Czasem może to być mylące, ale z rozmów ze świadomymi klientami wynika, że wcześniej spotkali się z nazwą „audyt” w znaczeniu oceny użyteczności, a więc samo słowo musiało się dobrze zakorzenić w polskiej świadomości. Ja będę używał słowa „ekspercka ocena użyteczności serwisu”, choć to pojęcie też jest dość wąskie. Skupię się na celach jakie ma realizować takie badanie, spory semantyczne odstawię na boczny tor.
Przed przystąpieniem do realizacji zlecenia musisz poczynić pewne kroki przygotowawcze, żeby w ogóle wiedzieć z jakim zadaniem masz do czynienia.

Zanim napiszesz choć jedno słowo

Poznaj cel serwisu

Serwisy internetowe mogą realizować wiele różnych celów, najczęściej w projektach biznesowych jest to różnie pojęty zysk. Liczony w twardej walucie, np. „serwis sprzedający e-booki musi tyle i tyle zarobić w danym czasie”, albo „serwis hostujący pliki musi zarobić określoną ilość pieniędzy z pozyskanych abonamentów ludzi wykupujących dostęp”. Serwis może też mieć inne cele nie przekładające się bezpośrednio na twardy zysk, np. serwis ma informować pacjentów o ofercie nowych leków, skierowany jest do ludzi starszych. Celem serwisu jest wówczas zbudowanie świadomości dotyczącej stosowania leku w tej grupie wiekowej.

W Internecie nazywamy to konwersją (wskaźnik konwersji), czyli stosunkiem liczby osób, które wykonały jakieś zadanie (np. wykupiły abonament, zalogowały się na stronie) do liczby osób które np. odwiedziły serwis. Użyteczność ma wspierać główny cel serwisu i mniejsze cele, ale zawsze ma służyć konwersji przez na przykład dobrze zaprojektowany proces zakupowy lub ogólny wygląd i dopracowanie szczegółów formularza kontaktowego. Jeśli znasz cel to poznaj też użytkowników serwisu. Zanim zagłębisz się w statystyki, porozmawiaj ze swoim klientem, zapytaj dla kogo jest serwis, kogo chcą przyciągnąć, co się udaje a co nie, jaką rolę odgrywają działania offline. Im więcej wiesz, tym bardziej precyzyjnie będziesz myślał.

Kim są użytkownicy

Zdarza się, że właściciel serwisu myśli, że jego klientami są mężczyźni po 40 roku życia, a okazuje się, że ta grupa nie stanowi większości klientów. Skonfrontuj to co mówi tobie klient na temat użytkowników z rzeczywistymi statystykami serwisu. Gdy usłyszysz, że serwis jest stworzony dla wszystkich, zapytaj dla kogo szczególnie i czy ci „wszyscy” mają takie same cele w serwisie.

Rzuć okiem na statystyki serwisu

Numer dwa po rozmowach z klientem to dostęp do statystyk serwisu, najlepiej Google Analytics. Nie musisz ich studiować z zapałem, ale ważne, żebyś miał ogólny ogląd na temat ilości użytkowników, dynamiki wzrostu, źródeł odwiedzin, wskaźnika odrzuceń w poszczególnych segmentach użytkowników oraz tego kiedy użytkownicy rezygnują z surfowania po serwisie. Takie podstawowe dane pozwolą Ci przejść do punktu trzeciego, czyli….

Poznaj ścieżkę konwersji użytkownika

Jest to punkt bezpośrednio związany z punktem drugim, ale warto o nim szczególnie pamiętać. Każdy serwis powinien mieć zdefiniowane ścieżki konwersji. Idąc do np. do supermarketu podążasz precyzyjnie zaprojektowaną ścieżką – ktoś postawił regał z pieczywem daleko od wejścia, żebyś musiał przemierzyć cały sklep by dotrzeć do bułek, umieścić batony i kondomy przy kasach, żebyś mógł dokonać zakupów w ostatniej chwili. Ktoś też rozpylił zapach lawendy i wymyślił to co ma mówić do ciebie sprzedawca. W Internecie podejmowane są podobne działania, masz zobaczyć produkt, sprawdzić jego opis, i kupić Nic prostszego, nie możesz tylko po drodze zgubić się w gąszczu podobnie wyglądających przycisków, które wykonują różne funkcje, być zmuszonym do podawania imienia swojego barta ciotecznego i numeru NIP przy zakupie, czy też nie mieć możliwości powiększenia zdjęcia produktu. Kiedy już zidentyfikujesz ścieżki konwersji, (czasem będziesz musiał budować je od podstaw), łatwiej Ci będzie znaleźć wąskie gardła serwisu, czyli miejsca gdzie odpada większość użytkowników. Pytanie do Ciebie: dlaczego użytkownicy rezygnują z zakupu? Może proces zakupowy ma 16 korków i zajmuje 30 minut, a może cena przesyłki przewyższa cenę produktu…a może właściciel serwisu ma zupełnie inne cele…

Wejrzyj w bebechy

Potrzebne są Ci tylko podstawowe informacje dotyczące technologii budowy serwisu/aplikacji, będzie to ważne później kiedy będziesz formułował wskazówki dla developerów. Ważne żebyś miał jakieś oględne pojęcie o technologii.

A teraz do dzieła, weź pióro i zacznij badanie

Eksperckie badanie = min. dwóch ekspertów

Dlaczego akurat dwóch – dlatego, że to lepsze wyjście, niż jeden ekspert. Zawsze możesz coś pominąć, nie wychwycisz 100% błędów, potrzebujesz drugiej osoby, która w tym samym czasie również będzie badała serwis. Pewnie pod koniec samego badania okaże się, że macie wspólnych 90% błędów, ale to 10% stanowi właśnie wartość dodaną.

Wciel się w użytkownika

Kluczowa część każdego badania użyteczności. Jesteś użytkownikiem, który korzysta z różnych funkcjonalności badanego serwisu. Weźmy pierwszy z brzegu przykład, czyli typowy sklep internetowy, jako wcielający się w rolę badanego spróbuj zamówić coś z tego sklepu, dowiedzieć się czegoś o danym produkcie, przejść przez proces zakupowy, etc. Jesteś użytkownikiem i śledzisz napotkane przez siebie przeszkody w toku realizacji poszczególnych zadań w serwisie. Wiesz jacy użytkownicy korzystają z serwisu, jakie są jego cele, na czym szczególnie zależy zleceniodawcy. Może np. kluczową rolę z pkt widzenia konwersji odgrywa dział „odzież damska” bo to najczęściej kupują klienci i na tym właściciel sklepu ma najwyższą marżę. Zastanów się jak możesz pomóc właścicielowi w konwersji ruchu napływającego do działu z odzieżą damską, może większość kupujących to mężczyźni, którzy potrzebują profesjonalnej pomocy w postaci video tutoriali wyjaśniających czym jest rozmiar stanika?

Określ kategorię błędu

Każdy błąd użyteczności w serwisie może być problematyczny dla użytkownika, ale tylko te które uniemożliwiają mu, albo drastycznie zmniejszają prawdopodobieństwo wykonania zadania powinny być traktowane jako błędy kluczowe, które należy poprawić w pierwszej kolejności. Do takich błędów możemy np. zaliczyć: puste linki, nieklikalne buttony, nie działające formularze, brak podstawowych informacji o firmie/produkcie/ofercie, brak optymalizacji serwisu sprawiający, że nawet przy dużej przepustowości łącza serwis bardzo długo się ładuje, brak optymalizacji pod najważniejsze przeglądarki. Jaki błąd będzie przez nas traktowany jako krytyczny zależy od specyfiki serwisu – na pewno do krytycznych zaliczany będzie każdy błąd, który sprawia, że użytkownik nie może, albo ma bardzo ograniczone możliwości przejścia przez najważniejsze ścieżki konwersji w serwisie.

Do lżejszych błędów na pewno możemy zaliczyć te, które w umiarkowany sposób przeszkadzają użytkownikowi w ukończeniu zadania. Do takich błędów możemy zaliczyć np. brak spójnych oznaczeń linków w serwisie, trudność rozpoznania, który element jest linkiem, skomplikowaną i nie logiczną nawigację w serwisie (błędy projektowe nawigacji, umieszczanie wielu poziomów zagłębień w serwisie), brak prawidłowej walidacji pól formularzy, brak przyjaznych URL, brak atrybutów alt przy obrazkach,

Do trzeciej kategorii możemy zaliczyć wszelkie pozostałe problemy, typu: brak podlinkowania logo do strony głównej, brak możliwości dokonania zakupu w sklepie internetowym jeśli nie założy się w nim konta, używanie technicznego języka dla nietechnicznych użytkowników.

Rzecz jasna przykłady, które podałem nie zawsze muszą znajdować się akurat w tej grupie w której wskazałem. Wszystko zależy od serwisu i jego celów.

Rekomenduj pozytywne rozwiązania

Nie możesz przygnieść klienta negatywnymi opiniami o jego serwisie, wskaż co najmniej kilka rozwiązań pozytywnych. To taki psychologiczny zabieg – nikt nie lubi być ciągle krytykowany.

Opisz koszty implementacji zmiany

Trudna sprawa, ale zawsze można określić problem z implementacją: trudne w implementacji, wymaga zmian takich i takich w kodzie, zaangażowania developerów, zmian innego rodzaju, umiarkowanie trudne, łatwe – zmiany w CSS, elementy front endu. Jeśli nie masz wiedzy technicznej poproś znajomego developera o pomoc w oszacowaniu czasu pracy nad implementacją proponowanych przez ciebie zmian. Pierwszeństwo mają krytyczne problemy w serwisie, ale często jeden problem wpływa na drugi, jeden generuje drugi i rozwiązanie tego pierwszego sprawi, że drugi również się rozwiąże, albo nie będzie taki uciążliwy. Poprawki należy zacząć od tego typu błędów krytycznych w serwisie, czyli nie poprawiamy jak leci, ale poprawiamy tak, by eliminacja jednego błędu, automatycznie wyeliminowała inny błąd użyteczności.

Rekomenduj zmiany

Twoje rekomendacja powinna być jasna i zrozumiała w ciągu kilku sekund Pokazuj zdjęcia dobrych rozwiązań, sam zaprojektuj kilka ekranów, pokażesz klientowi, że nie tylko umiesz identyfikować błędy, ale i projektować.

Opisuj błędy w sposób zrozumiały

Co to znaczy? Czy to oznacza, że musisz stworzyć kilka kategorii, np. nawigacja gdzie wrzucasz wszystkie problemy związane z nawigacją w serwisie? Możesz tak zrobić, ale czy taki podział będzie optymalny z punktu widzenia developerów wprowadzających zmiany na podstawie Twojego dokumentu? Moim zdaniem nie, raport powinien być podzielony według kryterium ważności błędów. Innymi słowy na samym początku przedstawiasz błędy krytyczne z punktu widzenia najważniejszych ścieżek konwersji w serwisie. Poprawki mają tak szybko jak to tylko możliwe wpłynąć na wzrost zysku serwisu. Jako najważniejsze z najważniejszych umieszczasz te problemy kluczowe, które generują inne problemy kluczowe, będziesz mógł je zidentyfikować dzięki pomocy developera.

Stwórz podsumowanie dla zarządu

Zarząd lubi krótkie i zrozumiałe fragmenty. Twojego raportu nie będzie czytał nikt z zarządu, a tylko odpowiedzialni za projekt project managerowie oraz wprowadzający zmiany web developerzy. Jeśli jakimś cudem wpadnie on w ręce kogoś z zarządu, to ta osoba musi w ciągu 60 sek, czytania tego raportu przekonać się, że pieniądze firmy zostały dobrze wydane. Wszelkie wykresy typu ROI, zyski, itp mile widziane, nawet jeśli dotyczą one innych projektów, co rzecz jasna należy wskazać.

Testuj!

Ten punkt może być naprawdę obszerny, ale z podstawowych zadań jakie powinieneś wykonać to:

• sprawdź jak serwis wyświetla się na urządzeniach przenośnych, przede wszystkim telefonach komórkowych, serwis nie musi być specjalnie projektowany pod urządzenia mobilne, choć byłoby to najlepsze rozwiązanie, jednak dobrze zoptymalizowany serwis powinien bez problemu być dostępny przynajmniej w jakimś procencie przez telefon komórkowy
• sprawdź jak szybko serwis się ładuje: http://tools.pingdom.com
• sprawdź meta tagi
• używaj web developer add on, dodatku do firefoxa, za pomocą którego szybko przetestujesz wszystkie elementy serwisu
• sprawdź czy serwis dobrze wyświetla się na różnych przeglądarkach i jeśli to konieczne również na różnych systemach operacyjnych
• waliduj, za pomocą checkerów w3c, ale bądź ostrożny, strona Google też nie przechodzi testów walidacji
• sprawdź czy serwis nie ma linków prowadzących donikąd

Nie zapominaj o dostępności

Temat często traktowany po macoszemu jako niewielki dodatek do raportu dotyczącego użyteczności, jest tak naprawdę bardzo ważnym elementem. Nie będę się tutaj rozwodził na temat zasad jakie spełniać ma serwis, oprócz tylko jednej – zapewnij użytkownikowi alternatywny dostęp do treści i funkcji serwisie. To jest najważniejsza zasada – serwis powinien być tak samo dostępny, czytelny i w dużym stopniu możliwy do używania, bez obrazków, arkuszy stylów, javascriptu, elementów flash. Temat dostępności będzie rozwijany w następnych postach.

Wyjdź do ludzi

Testujesz serwis sklepu internetowego, zadzwoń do konsultanta i zapytaj go o pomoc, zamów produkt ze sklepu, wypytuj o szczegóły, staraj się go zdenerwować. Jeśli masz możliwość idź do sklepu w realu, bądź namolnym klientem, sprawdź jak reaguje obsługa. Użyteczność serwisu to tylko etap, dalej mamy kontakt z klientem, wysyłkę, obsługę po sprzedażową, to tak buduje się zaufanie i zyskuje lojalnych klientów na lata.

Wyślij

Bądź dostępny

Twój raport powinien być dostępny zarówno w wersji elektronicznej jak i papierowej. Przekazując go klientowi umieść kopię na FTP, napisz o tym w samym raporcie, do wersji papierowej dodaj raport nagrany na płycie DVD, najlepiej z oznaczeniem twojej firmy lub nazwisk i telefonu na samym nośniku (lightscribe nie markerem po płycie!).

Sprawdź czy wprowadzono zmiany

Bolączką wielu badaczy jest to, że zmiany są wprowadzane wolno, albo czasem nawet wcale. Ciężko w takiej sytuacji tworzyć case studies i samemu weryfikować swoje własne wskazówki. Bądź cierpliwy i monitoruj proces wdrażania zmian. W końcu sam raport powstaje właśnie w tym celu.

Ten wpis opublikowano w dniu sobota, Sierpień 21st, 2010 o godzinie 23:09 w kategorii użyteczność WWW. Subskrybuj RSS 2.0 komentarze. Zostaw komentarz, albo trackback ze swojej strony.