Rozpoznanie bojem

By rzeczywiście zadbać o ergonomię i użyteczność produktu informatycznego, do jego testów należy zaangażować użytkownika.

By rzeczywiście zadbać o ergonomię i użyteczność produktu informatycznego, do jego testów należy zaangażować użytkownika.

"To nie działa!" - podniesionym głosem peroruje mężczyzna siedzący na wprost monitora. I dalej "Trzeci raz przechodzę tę instalację, a tu mi ciągle wyskakuje jakiś głupi komunikat, że jest coś źle". Co jest źle, przecież wszystko wpisuję tak jak w instrukcji?! - pyta się sam siebie użytkownik. "Co za bełkot, co to jest to asynchroniczne cyfrowe coś tam, o czym dostaję komunikat? Durnia ze mnie robią, czy co?" - dodaje, wyraźnie zirytowany. Ma dość.

Taki obrazek wcale nie należy do rzadkości w laboratoriach użyteczności. Jeżeli jesteś programistą, informatykiem, osobą odpowiedzialną za wdrożenie i działanie systemu informatycznego, czy też administratorem interaktywnego portalu webowego itp., to zadaj sobie proszę pytanie: "Kiedy ostatnio zdarzyło ci się widzieć tak sfrustrowanego użytkownika twojego produktu?" Nigdy? Czy to dlatego, że masz produkt tak wysokiej jakości, że to niemożliwe?

Być może jesteś jednym z tych szczęśliwców, ale na 90% oznacza to, że nie sprawdziłeś, w jaki sposób z twojego produkt będą korzystać "prawdziwi użytkownicy".

Tutaj na ogół padają słowa protestu - "Jak to nie był przetestowany? Testowali go przecież najlepsi nasi informatycy z wieloletnim doświadczeniem; spełniamy niemal wszystkie standardy właściwych metodologii projektowania; jesteśmy w stałym kontakcie z klientami". Itd., itp. Powiem szczerze: to bardzo dobrze. To znaczy, że dla twojej firmy jakość ma znaczenie, że decyduje ona o wartości produktu. Pomimo tego tak często, zbyt często, omijany zostaje zapewne najistotniejszy etap tworzenia produktu czy usługi, którego nie zastąpią testy wykonywane przez samych programistów - prawdziwe badanie przez użytkowników końcowych. Dlaczego ten etap jest najbardziej istotny?

Tempo bieżących zmian technologicznych jest - zwłaszcza w zestawieniu z dotychczasową historią cywilizacji - wręcz szokujące. Wystarczy sobie przypomnieć, jak się żyło raptem ćwierć wieku temu. Wyobraźmy to sobie: nie było tych wszystkich komputerów wokół nas... Paradoksalnie jednak, najmniej świadomą konsekwencji tych zmian grupą są właśnie ci, którzy za tempo zmian odpowiadają: twórcy techniki. Tylko ta bowiem grupa w pełni nadąża za zmianami i tylko dla niej są one naturalne. Osoba niezaangażowana w ten świat nie śledzi już jego niuansów z taką uwagą, chociaż to właśnie ona będzie potem korzystać z efektów entuzjastycznej pracy informatyków.

Jeszcze nie tak dawno takiego dysonansu pomiędzy twórcą i odbiorcą techniki nie było. Każdy, zdając na prawo jazdy, był zobowiązany do znajomości budowy silnika, a do pełnej obsługi komputera właściwie wystarczyło znać trochę komend w DOS-ie i umieć złożyć składak. Dzisiaj tam, gdzie w grę wchodzi zaawansowana myśl informatyczna, interwencja przeciętnego użytkownika ogranicza się do gwałtownego wezwania na pomoc specjalisty. Ale i to bywa za mało, gdyż coraz trudniej o wzajemne zrozumienie. Pod względem językowym informatycy to właściwie obcokrajowcy - używają bowiem skomplikowanego dla zwykłego śmiertelnika żargonu, pełnego dziwnych skrótów, obco brzmiących nazw i masy liczb o niejasnym znaczeniu. Przesadzam? A co powie "typowy informatyk" na wieść o tym, że ktoś nie odróżnia USB od DSL, albo jeszcze lepiej: nie umie posługiwać się myszką?

Rosnąca dysproporcja pomiędzy światem twórców techniki a światem jej odbiorców jest nieunikniona i właściwie nawet pożądana. Czasy "informatyków od wszystkiego" dawno się skończyły, a specjalizacja postępuje, oczekuje się jej także od dobrego programisty. Siłą rzeczy im bardziej nowoczesny i skomplikowany jest produkt, tym bardziej wyspecjalizowani muszą być jego twórcy i tym większy jest dystans pomiędzy nimi, a przyszłym "przeciętnym użytkownikiem". To prowadzi nas do kolejnej konkluzji - twórca techniki (programista, webmaster czy informatyk) to najgorsza z możliwych osób do testowania nowych produktów informatycznych. Dlaczego tak jest? Chodzi o kontekst informacyjny - za dużo z własnej wiedzy musieliby zapomnieć.

Powyższe stwierdzenie można nawet nieco rozszerzyć: do testowania produktów nie nadają się osoby zaangażowane w jego kreację (także od strony biznesowej). Nie mają one żadnych szans wczuć się w rolę przyszłego użytkownika, zapomnieć o tym co wiedzą itp. Jedyny sposób, w jaki prawidłowe testy powinny się odbywać, to zaproszenie rzeczywistych użytkowników (czyli typowych przykładowych użytkowników, którzy będą korzystać z danego produktu), stworzenie im (na ile się da) warunków odpowiadających naturalnym i obserwacja ich podczas interakcji z produktem czy usługą. Jak to powinno wyglądać?

Typowe badanie w usability lab (laboratorium użyteczności) rozpoczyna się od doboru testerów. Są to osoby, które mają być później użytkownikami końcowymi produktu, najlepiej o różnym poziomie zaawansowania umiejętności posługiwania się tego typu oprogramowaniem. Jeżeli tworzy się system dla banku, to testujemy go na pracownikach banku, ale nie na administratorach sieci (chyba że chodzi o funkcje dostępne jedynie dla nich) - czyli np. na osobach odpowiedzialnych za ewidencjonowanie operacji finansowych.

Specyfiką testów użytkownika jest niewielka próba badawcza (w praktyce rzadko przekracza ona kilkanaście osób), więc każda źle zrekrutowana do badania osoba może bardzo zaburzyć dalsze wnioski. Przetestowanie systemu już tylko na bazie 6-8 osób pozwala wychwycić zdecydowaną większość istotnych błędów.

Przebieg testów użyteczności

Dla testerów przygotowuje się zadania, jakie mają wykonać w ramach swojej pracy z produktem. Definiowane są w taki sposób, jak użytkownik naprawdę sam formułuje swoje problemy poznawcze, czyli "mając do dyspozycji X złotych, zaplanuj urlop", a nie "w menu dane odnajdź opcję hotele i hotel Perła, a potem sprawdź ceny". Następnie użytkownik w dowolny, wybrany przez siebie sposób rozwiązuje zadania. Cały czas jest uważnie obserwowany. Usability lab zwykle dysponują lustrami weneckimi albo przynajmniej transmisją wideo, tak by badanie mógł również obserwować właściciel produktu - w sposób niestresujący dla użytkownika. Jest to znakomita okazja dla twórców oprogramowania, by przekonać się naocznie, czy ich dzieło jest już skończone. Jednocześnie uczy to pewnej pokory, gdy użytkownicy zaczynają zachowywać się tak jak w opisie otwierającym ten artykuł.

Zazwyczaj lepiej nie wprowadzać elementu oceny (punktowanie wykonania zadania), ani rywalizacji (jednoczesne testy na kilku stanowiskach), bo istotne, by użytkownik czuł się możliwie naturalnie. Pamiętajmy też, że oceniamy system, nie człowieka, bo to system należy do oczekiwań odbiorcy dopasować. Generalna reguła - "użytkownik ma prawie zawsze rację".

Wnioski z obserwacji i spontanicznie zgłaszane uwagi testera są następnie rozwinięte i uzupełnione pogłębionym wywiadem indywidualnym, podczas którego staramy się dociec nie tylko uświadomionych, ale też nieuświadomionych potrzeb użytkownika. To bardzo istotny element, gdyż nieprzewidziane na etapie projektowania i kreowania usługi potrzeby użytkowników są odpowiedzialne za ok. 80% kosztów usprawniania produktów już obecnych na rynku.

Kiedy najlepiej podejmować takie działania proergonomiczne? Oczywiście jak najwcześniej. Wbrew pozorom nie trzeba mieć gotowego produktu, by móc przetestować logikę jego działania - ergonomia dysponuje całym arsenałem środków służących uwzględnieniu wymogów użytkownika na wcześniejszym etapie kreacji usługi. Do testów może wystarczyć papierowa makieta, nazwy opcji w menu, graficzny model interfejsu itp. Nawet na etapie powstawania koncepcji produktu można sięgnąć po opinie użytkowników za pomocą tzw. grup kreatywnych.

Im wcześniej zaczniemy uwzględniać wymogi ergonomiczne, tym taniej będzie modyfikować produkt. Dobra ergonomia oznacza dobrą ekonomię: 1 euro wydane na wczesne testy ergonomiczne oszczędza nawet ponad 100 euro niezbędnych do modyfikacji produktu, który już trafił na rynek. I druga reguła: interwencja ergonomiczna powinna mieć charakter iteracyjny, a nie incydentalny. Wykonywanie testów koncepcyjnych na początku procesu projektowania nie wyklucza sprawdzenia za pomocą testów korekcyjnych, czy finalny produkt na pewno charakteryzuje wystarczająco dobra jakość.

Testy wykazują

Okazuje się, że są takie rodzaje błędów systemu, czy też - nazwijmy je umownie - niedoskonałości, które diagnozuje się bardzo często (a niektóre niemal zawsze). Przyjrzyjmy się kilku takim przykładom:

  • język użyty w komunikatach, opisach itd. nie jest językiem użytkownika;
  • struktura zawartych informacji odzwierciedla strukturę organizacji, a nie logikę stosowaną przez użytkownika (bardzo częste zjawisko w przypadku witryn internetowych firm);
  • wykorzystany został szablon interakcji/interfejsu z innego produktu, który nie sprawdza się w danym rozwiązaniu;
  • produkt jest zwykłym tłumaczeniem produktu zagranicznego, bez adaptacji kulturowej (zwykle razi to w warstwie informacyjnej, ale czasem nawet w budowie interfejsu);
  • przyjęte oznaczenia graficzne (zwłaszcza ikony) są niezrozumiałe dla użytkowników;
  • konstrukcja menu nie spełnia oczekiwań użytkownika, który poszukuje informacji w zupełnie innych miejscach niż przewidywał to programista (w efekcie użytkownik często poddaje się, nie mogąc ich znaleźć);
  • sprzęt czy usługa działają wprawdzie poprawnie, ale użytkownik nie jest w stanie samodzielnie przejść przez instalację (zestaw samoinstalacyjny);
  • wygląd witryny internetowej jest nieadekwatny do celów, jakim ma ona służyć (np. kojarzy się z witryną firmową, a nie rozrywkową czy klubową);
  • prawidłowe użytkowanie programu czy systemu wymaga kwalifikacji znacznie wyższych niż posiadane przez grupę docelową.
Każdy z powyższych błędów obniża poziom satysfakcji użytkowników z korzystania z danego produktu, a niekiedy nawet je uniemożliwia. Często błędy te występują jednocześnie i wcale nie wynika to z zaniedbania czy niekompetencji programistów. Po prostu nie da się przewidzieć choćby najważniejszych wymogów użytkownika bez zapytania go o zdanie. W efekcie swoją opinię użytkownik przedstawi w jedyny dostępny mu sposób: nie kupując kolejnego produktu firmy.

Polska szara rzeczywistość

Skoro ergonomia jest tak nieodzowna, to można by sądzić, że zapewne wszelkie produkty informatyczne są starannie testowane. Niestety nie... Działalność, o jakiej opowiadam (tj. laboratoryjne testy użytkownika), jest w Polsce ciągle unikatowa. Od około dwóch lat funkcjonuje laboratorium ergonomii w Telekomunikacji Polskiej (piszący te słowa wprowadzał testy użytkownika do praktyki funkcjonowania tego operatora), przy kilku uczelniach działają wyspecjalizowane ośrodki prowadzące czasem pewne badania, ale w praktyce bardzo brakuje komercyjnych placówek świadczących tego typu usługi. Gdy rozmawia się na świecie z osobami odpowiedzialnymi za tworzenie nowych produktów informatycznych, to typową reakcją jest często zdumienie - "Jak to możliwe, że Polacy wymyślili ergonomię (warto wiedzieć, że twórcą tego terminu był półtora wieku temu profesor Wojciech Jastrzębowski), a niemal nie przeprowadzają testów użytkownika?".

Microsoft już kilka lat temu zatrudniał ponad 100 psychologów, specjalistów od użyteczności, zajmujących się tylko testami nowych produktów firmy. Tymczasem w Polsce mało kto wymaga takich badań i niewielu je oferuje. Traci na tym użytkownik, ale i same polskie firmy IT, które wraz z rozwojem technologii będą coraz mniej konkurencyjne wobec liderów światowych.

To, że warto mieć produkt wysokiej jakości, bo na dłuższą metę to się zawsze opłaci, jest rzeczą dość oczywistą - niemniej jednak badania użyteczności potrafią się zwrócić nieomal błyskawicznie. Przytoczę przykład z własnej praktyki badawczej: proszę sobie wyobrazić, że w instrukcji instalacji jest mało wyraźnie wyeksponowany pewien komunikat, w efekcie czego 80% użytkowników ignoruje go i wykonuje "ratunkowy" telefon na helpdesk. Załóżmy, że takich użytkowników końcowych będzie 10 tys. Statystyki zachodnie szacują koszt jednego takiego połączenia na 6-8 euro, ale przyjmijmy, że w polskich warunkach niech będzie to tylko 2 euro. Ta kwota pomnożona przez liczbę dzwoniących klientów kilkukrotnie przekroczy całkowity koszt testów użytkownika! Tymczasem mówimy o jednej tylko drobnej usterce i drobnej modyfikacji dającej znaczne oszczędności. Co więcej, są to ułamkowe kwoty tych, które zwykle idą na marketing produktu przeznaczonego dla masowego użytkownika (tyle że operacyjnym celem marketingu jest wyłącznie coś sprzedać, a niekoniecznie usatysfakcjonować klienta). To ciekawy paradoks, że wydaje się wielkie sumy na skłonienie do zakupu produktu, zamiast zadbać także o to, by ten sam siebie obronił swoją jakością.

Na zakończenie: pamiętajmy, kto ma korzystać z produktów naszej pracy. Bądźmy w kontakcie z tymi osobami, pytajmy o ich wymagania, nie narzucajmy potrzeb. Te proste reguły uczynią nasz produkt lepszym, a klientów zadowolonymi. Bo w końcu o to przecież nam wszystkim chodzi.

Generalne wnioski o testach użyteczności

Historia badań użyteczności pozwala na sformułowanie kilku podstawowych wniosków:

  • Testów użytkownika nie da się zastąpić żadnym innym badaniem czy testowaniem. Badania rynku (czyli procedura również angażująca przyszłych użytkowników) służą poznaniu wyłącznie deklaracji i postaw konsumentów.
  • Opinie eksperckie i inne procedury oceny produktu bez udziału użytkownika dają prawie zawsze mniej wartościowe rezultaty niż testy użytkownika. Badania porównawcze, wykonywane od początku lat 90., wskazywały zwykle na to, że ponad połowa znalezionych "ekspercko" błędów nie była problemami faktycznie występującymi (jednocześnie ok. 35% rzeczywistych problemów nie udawało się w ten sposób zdiagnozować).
  • Kwestionariusze satysfakcji są niewystarczające. Często zdarza się, że użytkownik ocenia produkt jako dobry, biorąc winę za źle wykonane zadanie na siebie. W efekcie niektórzy użytkownicy będą twierdzili, że produkt jest dobry, ale sami go nie używają, bo np. dla nich jest zbyt skomplikowany. Zgodnie z normami ISO, oprócz samej satysfakcji użytkownika, należy również zwrócić uwagę na takie czynniki, jak efektywność, wydajność, łatwość nauki obsługi systemu i jego elastyczność.

Marcin Charkiewicz jest pracownikiem Laboratorium Badań Ergonomii Usług Telekomunikacji Polskiej (przeprowadził pierwsze pełne badania z udziałem użytkowników); wykłada również na Wydziale Psychologii Uniwersytetu Warszawskiego. Z wykształcenia ekonomista (dyplom Szkoły Głównej Handlowej) i psycholog (Uniwersytet Warszawski).

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200