Projektowanie UX: proces z użytkownikiem zawsze w centrum uwagi

Pisaliśmy poprzednio o projektowaniu zorientowanym na użytkownika i jego wpływie na konwersję stron internetowych czy aplikacji. Przyjrzeliśmy się bliżej standardom przemysłowym dotyczącym użyteczności i wygody użytkowania systemów informatycznych. Ale jak w praktyce przebiega takie projektowanie UX?

Nasz zespół UX korzysta ze standardowego, podzielonego na cztery etapy procesu projektowania. Podział ten jest o tyle praktyczny, że nie tylko pozwala na projektowanie użytecznego oprogramowania, ale też pozwala łatwo zająć się optymalizacją już istniejących produktów. Etapy te nie przebiegają bowiem liniowo, lecz w iteracyjnych cyklach, przenosząc między sobą nowe odkrycia i rozwiązania.

Analiza

Jeśli przychodzi nam optymalizować istniejący już produkt, to po wstępnych pracach zaczynamy od analizy. Dzięki niej możliwe jest zrozumienie użytkownika i kontekstu, w jakim produkt będzie używany. Staramy się odpowiedzieć na pytania — kto będzie z niego korzystał? Co użytkownik chce za jego pomocą osiągnąć? Jak się użytkownik zachowuje w sieci?

Z naszego doświadczenia wynika, że właściciel strony czy aplikacji rzadko kiedy jest w stanie dobrze na te pytania odpowiedzieć. Odpowiedzi tych nie znajdziemy w Google, wcale też nie jest tak, że nasi eksperci podczas analizy od razu takie odpowiedzi dostarczą. Owszem, główne błędy łatwo wypatrzeć, ale problem w tym, że to nie jest ścisła wiedza. Nie ma gotowych heurystyk pozwalających powiedzieć, że to jest dobre a to jest złe. Ocena zależy od kontekstu, a kontekst dostarczyć mogą tylko realni użytkownicy produktu.

Dlatego stawiamy na metody oparte na aktywnym angażowaniu reprezentatywnych użytkowników końcowych. Przede wszystkim sprawdzają się tu informatyczne narzędzia rejestracji interakcji użytkowników. Ludzie w laboratorium UX zachowują się inaczej, niż w realnych scenariuszach użytkowania, np. ze smartfonem w sypialni czy przed pecetem na biurku w pracy.

Wykorzystując testy A/B i mechanizmy nagrywania zachowań, takie jak np. Yandex.Metrica, pozwalamy użytkownikom działać w ich naturalnym środowisku i biernie generować potrzebne nam dane. Wystarczy kilka tygodni takich testów, by wyciągnąć istotne wnioski.

Mamy więc pierwszych dane o użytkownikach, wiemy coś o tym, czego potrzebują, czego oczekują. Następnym krokiem jest stworzenie z tej wiedzy persony użytkownika. Czym jest ta persona? Definicja z Wikipedii jest prosta: Persony to fikcyjne postacie, stworzone aby reprezentować różne typy użytkowników, którzy mogą korzystać z marki, aplikacji czy strony internetowej w podobny sposób. Szybko się okaże, że tych person będzie co najmniej kilka — i to dla nich będziemy optymizować nasz produkt.

Trzeba tu podkreślić jedną rzecz. Persona, o której mówimy w UX, nie jest tym samym, czym jest persona dla marketingu. My tu skupiamy się na uchwyceniu celów użytkowników i ich wzorców zachowań, a nie tworzeniu jakichś barwnych historyjek dla zarządów. Nasze persony zawsze bazują na realnych ludziach i analizie danych o ich aktywności.

A co, jeśli zajmujemy się zupełnie nowym projektem? Tutaj też wychodzimy od analizy, choć z konieczności jest ona znacznie skromniejsza, być może mamy jedynie najprostsze prototypy, historyjki użytkownika. Nie szkodzi, do pełnej analizy jeszcze wrócimy. Po tej uproszczonej analizie weźmiemy się od razu za pierwsze…

Specyfikacje

Mamy już jakieś persony (albo chociaż ich zarysy) mamy pierwsze spostrzeżenia użytkowników. Zacznijmy zabawę. Nie tylko projektanci mogą w niej uczestniczyć, warto tu zaprosić też menedżera projektu, programistów, analityków biznesowych i ludzi od QA. W ten sposób dajemy szansę każdemu lepiej zapoznać się z produktem, w przyszłości zaś unikniemy różnych zbędnych pytań od niewtajemniczonych członków zespołu.

Całemu zespołowi należy przedstawić teraz dane pozyskane na etapie analizy. Zadaniem projektantów będzie opisanie odkrytych wymogów naszych użytkowników jak i ustalonych przez możliwości i ograniczenia techniczne wymogów eksploatacyjnych. Powstaje w ten sposób kanwa, na której będziemy projektować — specyfikacje, w obrębie których będziemy się poruszać.

W wypadku optymalizacji istniejącego produktu zwykle już mamy jakąś specyfikację. To że ją mamy, wcale nie znaczy że to dobra specyfikacja. Bywa i tak, że jej podstawowe założenia są błędne — jeśli widzimy duży rozdźwięk między danymi z etapu analizy, a tym, co opisano w wymogach, pozostaje poważnie porozmawiać z klientem. Może próbuje robić zupełnie coś innego, niż powinien?

Projektowanie UX

Teraz zespół może wziąć się za to, co najciekawsze, czyli za projektowanie UX. Prosimy wszystkich o zdefiniowanie celów dla użytkownika, w oparciu o nasze specyfikacje. Wpisujemy te cele na oddzielne karteczki i przyklejami do tablicy, podzielonej na pola dla każdej z person.

W ten sposób zaczyna powstawać mapa scenariusza każdej historyjki użytkownika. Obejmuje ona kolejne kroki niezbędne do realizacji celu, zestawione z pomysłami, jak strona czy aplikacja pomagają je zrobić. Na przykład na żółtych karteczkach opisujemy kroki zbliżające do celu, a na różowych to, co w zakresie tym robić ma oprogramowanie.

Brzmi to prosto, jak ma się jedną personę i jedno zadanie, ale w sytuacji, gdy jest wiele person mających wiele celów, tablica zamienia się w pstrą mozaikę. A przecież to nie wszystko — jeśli produkt jest skomplikowany, na przykład zajmujemy się sklepem internetowym, musimy jeszcze określić jak użytkownicy będą przechodzić od jednego celu do drugiego, stworzyć całą architekturę informacji. Dzięki niej powinniśmy móc uniknąć sytuacji, w której użytkownik się zagubi i nie będzie wiedział, co robić dalej.

Potem jest już czyste projektowanie. Nie staramy się robić jakichś wiernych makiet interfejsu, to zwykłe szkice, robione najpierw na kartce, potem w programie Sketch. Chodzi o to, by nie marnować czasu na dokładne rysowanie, a raczej eksperymentować z różnymi projektami, różnymi pomysłami, które spełniałyby określoną architekturę informacji.

Przygotowane tak makiety eksportujemy do narzędzia do pracy grupowej Zeplin. Członkowie zespołu mają wówczas okazję wypowiedzieć się w komentarzach, co sądzą o danym rozwiązaniu, podpowiedzieć inne możliwości. Zeplin upraszcza też dalszą pracę projektantów i programistów, zapewniając doskonałe narzędzia do tworzenia podręcznika redakcyjnego i eksportowania zasobów wizualnych.

To etap, w którym mamy wiele wersji, wiele opcji, wiele opinii, łatwo się w nim pogubić. Jeśli czujemy się zagubieni, wracamy do tablicy i jeszcze raz czytamy o personach, które zostały zdefiniowane. W końcu projektujemy dla użytkownika, a nie dla siebie.

Gdy ten twórczy chaos uda się okiełznać, na podstawie zebranych informacji projektant buduje już dokładne interaktywne makiety. Lubimy do tego celu korzystać z narzędzia InVision. W wielu wypadkach pozwala on na dostarczenie czegoś, co będzie można przenieść do kolejnego etapu.

Ewaluacja

Podczas oceny opracowanego rozwiązania w projektowaniu zorientowanym na człowieka zawsze testuje się je pod kątem wymogów użytkownika końcowego. Nie można jednak zrobić tego na kolegach z pracy. Jako eksperci, są oni wszystkim tylko nie reprezentatywną grupą docelową. Ponownie należy dążyć do obserwacji reakcji realnych użytkowników. Tym razem można już się pokusić także o ankiety, wywiady i testy użyteczności.

Jeśli nie jest to możliwe, staramy się opracować koncepcje testów A/B, które uwzględniałyby realne zachowania użytkowników stron czy aplikacji. Wyznaczamy odpowiednie wskaźniki (KPI) i obserwujemy, jak poszczególne wersje przygotowanych optymalizacji sprawdzają się w praktyce. Im bardziej podzielimy zoptymalizowane rozwiązanie na niezależne segmenty, tym precyzyjniej będziemy mogli ustalić, co jest dobre, a co nie się nie sprawdza.

Po osiągnięciu oczekiwanego poziomu wzrostu KPI, można przygotować ze zweryfikowanych segmentów końcowe rozwiązanie — i skierować je do ostatniej oceny. Niekiedy zdarza się jednak tak, że suma tych najlepszych wariantów wcale nie daje najlepszej całości. Nic nie szkodzi, to przecież z założenia ma być proces iteracyjny. Wracamy do tablicy, wnioski zebrane podczas ewaluacji pozwolą ulepszyć projekt.

Zwykle takich powrotów do tablicy jest od trzech do pięciu. Efekt jednak jest tego wart. W końcu otrzymujemy rozwiązanie zgodne z wymogami, rozwiązanie, które znacznie lepiej konwertuje.

Następnym razem opowiemy, jak tworzy się grupę fokusową i pozyskuje od niej informacje, które pozwolą na lepszą konwersję.