Budowanie listy potrzeb użytkownika i organizacji wg. modelu GDS

Nie od dzisiaj wiadomo, że nie samymi danymi analitycznymi projektant żyje. Opisywany przeze mnie w odcinkach model GDS ładnie systematyzuje działania, które podjąć można w celu określenia wymagań projektowych. Spróbuję przybliżyć metody pracy, które w prosty sposób prowadzą do zrozumienia, jak można poprawić produkt (lub stworzyć go z sensem od zera).

W artykule dzielę się przykładowym arkuszem Excela, którego możesz użyć do katalogowania potrzeb zarówno użytkownika jak i organizacji.

Jeżeli to, co przeczytałeś we wstępie brzmi jak coś nowego, spojrzyj proszę na poprzednie artykuły w tym cyklu.

Jedziemy!

Ustaliliśmy już, że porządny projekt pozwala spotkać się założeniom organizacyjnym i potrzebom użytkownika. W przypadku większości prostych stron czy aplikacji (a także wraz ze wzrostem doświadczenia) łatwo jest czasem nakreślić podstawowe ramy projektu. W mojej opinii nie jest jednak dobrze się zapędzać. Zaangażowanie się w porządną analizę daje lepsze rezultaty, nawet, kiedy wydaje się, że walczymy z oczywistościami. Jeśli tylko mamy na to siłę i czas, poznać powinniśmy wymagania obu grup.

Jako potrzebę użytkownika (i organizacji) rozumiem zadanie zdefiniowane w następujący sposób:

• Jako… [kim jest użytkownik?]
• Chcę/potrzebuję/oczekuję… [jaką mam potrzebę?]
• A przez wypełnienie tej potrzeby mogę… [co będzie efektem spełnienia mojej potrzeby?]

GDS podaje jeszcze, że można rozbudować ten mikro-model o:

• Dzieje się tak, kiedy… [co powoduje, że potrzebuję tego, a nie innego rozwiązania?]
• Jednakże… [coś mnie ogranicza]

Przykład:

Jako fan zespołu Cinematic Orchestra chcę kupić bilet po to, by odwiedzić koncert w Warszawie.

Jak złożyć do kupy listę potrzeb użytkownika i organizacji?

Jest kilka rzeczy, które (zgodnie z modelem GDS) robię, próbując dowiedzieć się, gdzie leży wspomniany wcześniej złoty środek.

1. Patrzę na mapę strony – jeśli taka jest – ażeby wyrobić sobie na jej temat jakąś opinię. Próbuję intuicyjnie począć, czy wszystko jest na swoim miejscu. Jeśli mapy nie ma, to czasem buduję ją za pomocą np. Xenu.
2. Dobieram się do danych z Google Analytics (lub czegoś podobnego) serwisu, którego przebudowaniem ma zająć się mój zespół. Jeżeli nie mam dostępu do tych danych, staram się znaleźć dane dla serwisu o podobnej tematyce, lub przycisnąć klienta i dane wydusić. Większość szanujących się organizacji dysponuje jakąś dozą informacji. Patrzę na strony, które są odwiedzane najczęściej i te, które intuicyjnie wydają mi się ważne. Zapisuję ich listę w arkuszu Excela, jednocześnie rzucając okiem na te strony w serwisie, które nie są odwiedzane w ogóle lub bardzo rzadko.
3. Staram się zrozumieć, na jakie potrzeby użytkownika i biznesu odpowiadają poszczególne strony. Porządne serwisy internetowe zbudowane są według konceptu, w którym każda strona odpowiada na jedną potrzebę użytkownika. Nieporządnie zbudowane – a tych jest więcej – mogą wymagać spojrzenia na każdą stronę z osobna. Trzeba wtedy wysupływać szereg informacji z całego strumienia tekstu. Sporządzam notatki w przypadku poszczególnych stron, których dotyczy powyższy problem i staram się rozbić potrzeby na pojedyncze. Robię tak i dla potrzeb użytkownika, i organizacji.
4. Kategoryzuję potrzeby wg. dwóch kryteriów: biznes/użytkownik i przypisuję im typ wg. modelu Google: do, know i go. Robię to głównie po to, by zidentyfikować potrzeby transakcyjne i, by przygotować stronę dla kolegów z działu optymalizacji czy marketingu. Potrzeba do (robić) oznacza, że użytkownik chce wykonać jakąś czynność. Know to po angielsku “wiedzieć” – użytkownik chce zatem dowiedzieć się czegoś. Go – pójść (nawigować) gdzieś. Na przykład:
   1. Kup bilet do kina, obejrzyj film online, doznaj oczyszczenia przy oglądaniu zdjęć kociąt – do. Google określa to jako transactional content. Być może przykład z kociętami nie jest idealny, ale pewnie łapiesz, o co chodzi.
   2. Know – informational content: jak daleko jest do Ullapool? Co to jest komosa ryżowa i dlaczego cały świat mówi na toto quinoa? Ile centymetrów wzrostu ma Sean Connery?
   3. Go – navigational content – strony, do których najczęściej trafia się prosto z serwisów wyszukiwawczych, takie, które odwiedzają klienci zaznajomieni przynajmniej z brzmieniem nazwy marki. Przykładem potrzeby go jest zauważenie na autobusie reklamy Victoria Secret i nawigacja do tejże marki strony internetowej. Uwaga: czasem trudno jest rozróżnić go od know i nie powinieneś na tym łamać sobie zębów. Tak na końcu chodzi o to, by zrozumieć intencje odwiedzających stronę.
5. Dzielę się swoją pracą z klientem i proszę go o przejrzenie mojej listy w celu zidentyfikowania stron i potrzeb, które trzeba zaktualizować lub usunąć. Nie oznacza to, że zabieram użytkownikom to, czego chcą; pytam głównie o odpady korporacyjne, duplikaty i rzeczy wyjątkowo stare, wymagające aktualizacji. Jeżeli stron jest dużo, proszę klienta o kategoryzację tychże wg. modelu ROT – redundant (niepotrzebne), outdated (wymagające aktualizacji), trivial (trywialne, można zostawić, niech się kisi w ogonie).
6. Rozmawiam z klientem. Staram się zrozumieć, jakie potrzeby ma organizacja. Często istnieje cała pula potrzeb nieudokumentowanych, zwłaszcza takich, których nie komunikowano na stronie internetowej (lub komunikowano niejasno). Jeżeli jest ich bardzo dużo (w przypadku dużej organizacji lub biznesu zakręconego jak świński ogonek), proszę klienta, ażeby przygotował dla mnie listę. Uwaga: ten etap może trwać długo i składać się z całej serii spotkań i warsztatów. Rzecz normalna; im głębiej, tym lepiej. Staram się stworzyć przynajmniej tytuł strony, która powinna odpowiadać potrzebie i znaleźć argument świadczący za tym, że ma ona sens – w postaci zbadania potrzeby użytkownika. To można zrozumieć z badań.
7. Jeżeli tylko mogę (bo czasem nie mogę, w którym to przypadku sięgam po wiedzę zgromadzoną przez drużynę kliencką), organizuję serię wywiadów, spotkań lub przynajmniej telefonicznych rozmów z użytkownikami serwisu końcowego po to, by dowiedzieć się, jakie ich potrzeby nie zostały spełnione przez stronę internetową. To bowiem jest największy problem z poleganiem jedynie na danych analitycznych: dane te nigdy nie pokażą Ci, czego na stronie nie ma. Brzmi jak oczywistości, ale wcale takie nie jest, szczególnie często w oczach kiepskich marketingowców, którzy wierzą tylko w numerki. Zgodnie z tym, co napisałem powyżej, kiedy cisnę użytkowników wykorzystuję też możliwość walidacji potrzeb wcześniej zdefiniowanych “na świeżo” w trakcie pracy z klientem.

Cały ten proces kontynuuję do czasu, aż spuchnę – albo aż do momentu, w którym jestem pewien, że wiem, czego potrzebują użytkownicy i organizacja, która powołuje usługę do życia. Co w praktyce oznacza, że przekazuję klientowi arkusz już długo po tym, jak nasz projekt osiągnie stań alfa lub beta, a w międzyczasie korzystają z niego projektanci architektury informacji, content writerzy i wszyscy dookoła.

Warto zresztą pamiętać o tym, że lista user and business needs powinna być stale poddawana recenzjom i aktualizowana na bieżąco.

Jeżeli to, co napisałem powyżej przypomina Ci audyt zawartości serwisu internetowego, to wysunąłeś bardzo poprawną konkluzję. To, co robię to pierwszy krok tego procesu.

W następnym wpisie w tym cyklu wyjaśnię, co dalej robić ze skonstruowanym modelem potrzeb użytkownika wg. GDS. Monitoruj kanał RSS i połącz się ze stroną Byle do przodu! na Facebooku – wtedy niczego nie przegapisz.

Niespodzianka!

Praktyczny szablon, w którym możesz gromadzić informacje o potrzebach użytkownika i organizacji - plik Excel, około 33kb – modyfikuj i udostępniaj do woli (tylko przyznaj się innym, skąd masz).

Przydatne zasoby

Poniższe linki prezentują zawartość w języku angielskim.

1. Start by learning user needs – jak robi to GDS. Ładne podsumowanie z przykładami.
2. Start with one thing per page, jedna potrzeba = jedna strona.
3. Query classification – do, know, go – model klasyfikowania zapytań Google, przydatny w analizie potrzeb użytkownika.
4. Do, Know, Go: How to Create Content at Each Stage of the Buying Cycle – więcej na temat klasyfikacji potrzeb.
5. Xenu – praktyczny kawałek oprogramowania do crawlingu, czyli budowania map stron internetowych.