Case study: wyszukiwarka z drugim dnem

Case study: wyszukiwarka z drugim dnem

Czy zdarzyło Ci się kiedyś pracować przy projekcie UX, który z małego zadania przeistoczył się w bestię wymagającą pracy całego zespołu? Czy zdarzyło Ci się przekonywać klienta do tego, że jego początkowe założenia – prośba o przeróbki w interfejsie nie działającej zbyt dobrze strony – są niewiele warte, jeśli nie zwróci się uwagi na to, co dzieje się pod spodem? Czy patrzyłeś kiedyś w rozszerzające się z przerażenia i zdziwienia oczy, niewidzące sensu w niczym poza „przesuń guzik na lewo”, spoglądające na ciężki od porad dokument wyjaśniający zagadnienia transformacji systemowej dla całej firmy, koniecznej do poprawnego działania produktu?

Mnie się zdarzyło, a raczej zdarzało – i to nie raz.. Dzisiaj, na prośbę miłych kolegów i koleżanek z UsabilityPL, małe case study pod tytułem:

„Jak sięgać po rozwiązania ekstremalne i wychodzić z tego z bananem na ustach, czyli opowieść o wyszukiwarce, błędnych założeniach na temat tego, co trapi użytkownika i kliencie chorym na rozwolnienie, wyleczonym stertą papieru.”

Kremówki, czyli jak się zaczęło

Siedziałem sobie  i oglądałem kotka z bananem (to najlepsza rzecz, jaką widziałem w internecie od początku mojego nim zainteresowania. Zawsze mnie rozmiękcza). Nagle ktoś powiedział:

– A ty co o tym myślisz?

Oderwałem oko od kotka z bananem i rozejrzałem się. Dookoła mnie zobaczyłem twarze ludzi skoncentrowanych na rozmowie o nowym projekcie. Czytałem brief wcześniej; duża firma oferująca raporty w dziedzinie eksploracji paliw kopalnych i innych zasobów naturalnych matuszki Ziemi. Nie spodobali mi się; nie leżał mi ten projekt etycznie, ale nie mogłem fikać, bo miałem pewne zobowiązania wobec pracodawcy. Ogromna organizacja zlecająca armii analityków pisanie raportów, które potem wyszukać i zakupić można za pomocą interfejsu skomplikowanej wyszukiwarki. Chciałem rozprawić się z tym jak najszybciej i oddać się zapomnieniu w oparach dobrego ale i jajecznicy na bekonie. Przed spotkaniem przeczytałem dostępną dokumentację i spojrzałem na stronę. Ta była nieużyteczna, naćkana treścią bez sensu i, ogólnie rzecz biorąc, paskudna. Powiedziałem więc:

– Sądzę, że interfejs jest na tyle zakręcony, że użytkownicy mają problem z jego wykorzystaniem. Nie jest dla mnie jasne, jak filtrować listę wyszukanych raportów; myślę też, że informacja podana jest zbyt gęsto i trudno się przez nią przebić. Interfejs jest zdecydowanie za wolny, nie responsywny i wierzę, że możemy poprzestawiać parę rzeczy tak, żeby stał się bardziej wydajny.

– W porządku – odpowiedział jeden z misiów, Alojzy Niemrawy – zrób, co uważasz za stosowne, ale pamiętaj, że mamy niewielki budżet i czas tylko do spotkania zarządu w przyszłym miesiącu.

– Nie ma sprawy. Uważam, że do tego czasu przetestujemy mały prototyp poprawionego iterfejsu i zaoferujemy serię niewielkich, ale znaczących poprawek, które spokojnie wprowadzi wasz dział front-endowców. Poprawimy mikro-interakcje i będzie cacy.

Świecące oczki i tupiące z radości nogogłaszczki.

Czysta robota. Wjazd, krótka gadka z zespołem klienta (żeby skumać, o co właściwie chodzi w tym produkcie z piekła), spojrzenie na stronę, rozmowa z użytkownikami, prototyp, testy, sru. To już było. Powrót do kociego nieba.

Dupa zimna.

Pierwsze wiadro zimnej wody

Szybko okazało się, że myliłem się – i to bardzo – w kwestii tego, jak zorganizowany jest mój klient. A przede wszystkim, jaką wiedzę na temat swojej bazy użytkowników posiada. Żadnych danych analitycznych po prostu nie było. Nawet logów z serwerów. Choć miałem dostęp do niesamowitych mózgów, te były głównie zaangażowane w pracę z tzw. expert users, którzy to generalnie nie narzekali na nic. Co gorsza, nie potrafili oni znaleźć żadnej drogi do użytkowników mniej zaawansowanych. A całe ich wyobrażenie na temat tego, co trawi klienta zostało zbudowane tylko na podstawie ich własnych doświadczeń. Krótko mówiąc, nawet po przefiltrowaniu tego, co usłyszałem, wciąż wiedziałem tyle, co nic. Zupełnie inaczej niż zwykle. Mimo wszystko, zebrałem pewną solidną dawkę notek na temat tego, jak źle zaprojektowany jest interfejs aplikacji. Z tego można było coś ukręcić.

Jedyną opcją było przyjrzeć się systemowi i zweryfikować utyskiwania klienta, a raczej jego rozumienie utyskiwań użytkowników.

Pewnego deszczowego dnia włączyłem komputer i usiadłem przed moją nową kochanką, stroną internetową złego korpo, w złym guście, złych kolorach i o zepsutych zębach.

Drugie wiadro zimnej wody

Uspokoiłem się. Interfejs naprawdę nie kleił się do kupy. Wyszukiwarka wyrzucała tysiące wyników. To nie martwiło mnie tak bardzo; do dyspozycji były filtry, a przecież w zasobach portalu było ponad 150 tysięcy dokumentów i raportów, a dodatkowo narzędzia do manipulacji danych statystycznych. Wszystko było jakieś takie małe, parchawe i trudne do przeczytania. Ekran przewijał się w nieskończoność. Próba wejścia na portal z komórki skończyła się padem Chrome. Już prawie radośnie zabierałem się do napisania małego, ale konkretnego raportu, wskazującego na serię koniecznych poprawek. Wtedy jednak zadzwonił telefon. Dzwonił Alojzy.

– Słuchaj, mamy jednak dla ciebie paru klientów. To wciąż tacy, co nas bardzo lubią, ale na pewno przekażą ci jakieś ciekawe informacje. Więcej nie będzie, korzystaj więc, póki możesz.

Ucieszyłem się i wykonałem serię telefonów. W ciągu dwóch dni mój humor zmienił się z w miarę radosnego „wiem, o co tu loto i będę w stanie bez wysiłku to poprawić” na „chce mi się kupę i marzę o wylocie do Tajlandii, ale nic z tego nie będzie, bo muszę użerać się z tym pasztetem”. Krótko mówiąc, wpadłem w dół. Telefony do dwudziestu użytkowników systemu rozsianych po całym świecie ujawniły bowiem, że:

  1. Posługiwanie się interfejsem nie nastręcza żadnego kłopotu. Każdy jest w stanie czytać wygodnie te małe literki i nikogo nie wkurza to, co – jak sądziłem – jest beznadziejną organizacją informacji na poszczególnych stronach, czyli paragrafy porozpieprzane na drobne i liternictwo wielkości dziesięciu pikseli.
  2. Nikt tego i tak nie używa z komórki, bo trudno ją podłączyć do siedmiu monitorów pokazujących stan notowań giełdowych na raz. A w domu to się śpi, a nie pracuje nad tego rodzaju rzeczami (cytat).
  3. Jakość informacji oferowanych przez firmę – same raporty i dane – jest doskonała i nie ma sobie równych na rynku.

Wszyscy wspominali jednak o trzech dręczących ich problemach, na które nikt wcześniej mnie nie nakierował:

  1. Tylko wpisywanie bardzo szczegółowych fraz wyszukiwawczych przynosiło sensowe wyniki. Zapytanie o „gaz ziemny w Kolumbii” pokazywało bezsensowną, dziką ilość trudnych do przefiltrowania dokumentów. Dopiero wyszukanie raportu o tytule „Gaz ziemny w Kolumbii, raport Smith & Smith 20.01.2014 wersja 1.4” podawało to, czego szukał klient. I żadne filtrowanie nie przynosiło tu skutku. Albo osiem tysięcy wyników, albo jeden.
  2. Fachowa terminologia używana w raportach nie była ujednolicona. Analitycy ze Stanów nie mogli czasem zakumać, o czym pisali ich koledzy z Wielkiej Brytanii – i vice versa.
  3. Kategoryzacja informacji leżała i kwiczała. Z jakiegoś powodu klienci nie byli w stanie odnaleźć się w strukturze, która wydawała się logiczna – podzielonej na terytoria, rodzaje zasobów i podtypy tychże (podaję z pamięci – za żadne skarby świata nie pamiętam prawdziwej kategoryzacji. Pardon).

Zamiast podpalać biurko i uciekać przez okno, udałem się do specjalisty z działu badającego wydajność danych. I wtedy zaczęło się na dobre.

Trzy miesiące poźniej

Spotkaliśmy się w tym samym pokoju. Drużyna klienta, spece od wydajności danych i mój zespół. To nie był pierwszy raz; w międzyczasie spotykaliśmy się wielokrotnie. Robert, mój kolega z drużyny performance analysis przeniósł swoje biurko do klienta na okres całego miesiąca. Ja działałem z doskoku. Teraz siedzieliśmy przy stole, a przed nami leżał gruby dokument, w którym wyjaśnialiśmy, co następuje:

  1. Projekt, który mądra głowa z działu sprzedaży wypchnęła jako prosty user experience review and recommendation tak naprawdę powinien być sprzedany jako coś zupełnie innego.
  2. Początkowe założenia projektu były błędne. System, dostarczający adekwatne do kontekstu doświadczenie użytkownika, sprawował się bardzo dobrze w sferze interfejsu. Gęstość informacji, chociaż duża, zupełnie odpowiadała klientom. Ilość kliknięć była w porządku. Prędkość – a raczej powolność – też. Krótko mówiąc, niewiele tu trzeba było poprawiać, bo diabeł siedział gdzie indziej.
  3. Dane w systemie były bardzo źle zorganizowane i to na tym polegał główny problem, albowiem:
    1. Raporty nie były prawidłowo opisane metadanymi, bo struktura tych po prostu nie istniała. Każdy analityk dodający raport do systemu jechał po bandzie, przypisując do niego wszystkie możliwe – i wynalezione z głowy – słowa kluczowe (tagi). Tworzyła się z tego zupa nie do przejedzenia.
    2. Architektura informacji była zupełnie nieadekwatna do wymogów rynku. Odkryliśmy, że sama taksonomia „oil & gas” zawiera prawie 25000 podtypów. W systemie naszego klienta było ich niespełna 50. Nic dziwnego, że użytkownicy nie mogli znaleźć, czego szukali.
  4. Apache SOLR, prawdziwe jądro systemu wyszukiwawczego był skonfigurowany na przeszukiwanie jedynie tytułów, tagów i pierwszego paragrafu każdego z dokumentów. W związku z wyżej wspomnianą zupą słów kluczowych i nieistniejącą szczegółową kategoryzacją danych, SOLR nie pokazywał po prostu niczego sensownego.
  5. Wewnątrz organizacji nie istniała żadna komórka, która zajmowałaby się porządkowaniem taksonomii i upewnianiem się, że raporty trafiające do systemu są uporządkowany w sposób umożliwiający ich znalezienie. Przede wszystkim zaś nikt nie sprawdzał ich pod kątem tego, jak mądrze – lub niemądrze – są napisane.

W jednym zdaniu: całe bablanie o niewydolności interfejsu i moje wstępne założenia na ten temat okazały się błędne. Dałem się pożreć rutynowym oczekiwaniom (i kotkowi z bananem). Drużyna kliencka miała o wiele większe zadanie do wykonania niż tylko poprzestawianie paru pikseli. Budżet na badania przekroczył ten założony pierwotnie i to o kilka razy. Jednakże dobra komunikacja z klientem i dowody dostarczane co i rusz (a to w postaci wywiadów, a to w postaci analizy zachowania SOLR) pomogły nam poradzić sobie z rosnącym  (momentami bardzo wybuchowo) niepokojem zespołu projektowego.

Rozwiązanie problemu i wnioski

Co zatem zaleciliśmy?

  1. Zakup poprządnej taksonomii pochodzącej od zewnętrznej firmy. Jest to o wiele lepsza opcja, niż tworzenie jej samemu, zwłaszcza przy tak ogromnej strukturze.
  2. Wprowadzenie zasad ścisłego zarządzania treścią (content governance) i upewnienie się, że żaden szajs nie zostaje publikowany bez poprawek, dopiero w momencie, gdy szajsem być przestaje.
  3. Program treningu dla analityków dostarczających raporty, edukujący ich na temat tworzenia semantycznych treści i architektury informacji. Szkolenia te uwzględniały również różnice terminologiczne w fachowym nazewnictwie.
  4. Serię video-wskazówek dla klientów, którzy gubią się w meandrach informacji.
  5. W miarę możliwości i czasu, przelot przed dokumenty trzymane w bazie i wywałkę staroci (o modelu ROT było już wcześniej).
  6. Wprowadzenie maleńkich poprawek do interfejsu, głównie związanych z metodą filtrowania danych – żeby jednak odrobinę przyspieszyć.

Obecnie klient wprowadza nasze pomysły w życie. Strona zaczyna działać dużo lepiej, a testy dzienniczkowe wykazują ogromny wzrost satysfakcji z użycia systemu. Idzie w dobrą stronę.

Co z tego wynika?

  1. Wierz swojej intuicji, ale wąchaj lepiej i bądź przygotowany na drastyczne obsuwy.
  2. Przyznaj się do spieprzenia sprawy i zrób tak, żeby wyciągnąć ze skiepy jak najwięcej.
  3. Nie bój się podważyć status quo i postaw się kołkiem, jeśli trzeba wprowadzić zmiany tyle drastyczne, co konieczne.
  4. Pracuj z klientem i prowadź go za rękę w chwilach, w których może dostać rozwolnienia.
  5.  Nie oglądaj filmów z kotkiem i bananem na spotkaniach biznesowych.

Pytania? Proszę śmiało walić pod postem, w mailu, na Twitterze lub na Fejsie.


Komentarze

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *