W życiu projektantów usług i produkt managerów jest pewna grupa ludzi, która mówi im, co mają robić. To oni, choć często niedostępni na wyciągnięcie ręki, wpływają na Twoje działania i na kształt wymagań biznesowych, które tworzysz. Kiedy tych wymagań nie spełniasz, złoszczą się lub odchodzą. To użytkownicy. Wyciągnij ich wprost z narzędzi pomiarowych i zrób wszystko, by ich dobrze poznać. Często to od ich opinii na temat tego, co stworzyłeś i udostępniłeś w sieci, zależy Twój awans, podwyżka oraz to, jakie projekty będziesz realizował w przyszłości.
źródło: Unsplash
Henry Ford powiedział kiedyś "Gdybym na początku swojej kariery zapytał klientów, czego chcą, wszyscy byliby zgodni: chcemy szybszych koni. Więc ich nie pytałem".
Chodzi za mną ten cytat i zastanawiam się, czy jest aktualny w dobie badań ilościowych, jakościowych oraz przeróżnych mechanizmów i algorytmów nie tylko odkrywających przed projektantem kim jest użytkownik, ale również - kim chciałby być. I myślę, że dziś to zdanie, wypowiedziane w latach 20. XIX wieku, może być inspiracją nie tyle dla projektantów usług, co dla przedsiębiorców snujących wizję swoich firm i poszukujących rozwiązań, które pozwolą im dostarczyć na rynek wartości do tej pory przez ludzi nieodkryte i dla nich niedostępne.
Projektanci i Product Managerowie natomiast, mogą i powinni korzystać z szerokiego wachlarza możliwości, jakie dają dostępne dziś na rynku narzędzia do badań zachowań i preferencji użytkowników. Zanim jednak zacznę je wymieniać i zachęcać Cię do ich wykorzystywania, przypomnę, dlaczego my, Product Managerowie i projektanci, w ogóle zabieramy się za te badania:
chcemy wiedzieć, po co użytkownicy odwiedzili usługę
namierzamy, w jaki sposób użytkownicy korzystają z usługi
chcemy wiedzieć, jak często użytkownicy korzystają z usługi
chcemy poznać ich lepiej i wiedzieć, kim są (jakie cechy posiadają)?
na podstawie wiedzy o użytkownikach rozwijamy usługę i optymalizujemy ją
dzięki wynikom badań, trafniej definiujemy priorytety prac w projektach
Użytkownicy, którzy odwiedzają Twoją usługę, zawsze wchodzą z nią w interakcję... bo nawet bezruch i brak interakcji jest reakcją, to z pewnością już wiesz! :). Do namierzania tych interakcji służą dwa modele:
model HEART
model AARRR
W tym artykule opowiem Ci o tym, jakie aspekty współpracy użytkownika z usługą i usługi z użytkownikiem zbadasz, dzięki modelowi HEART. Spójrz na ściągę:
Dzięki modelowi HEART możesz skupić się na najważniejszych aspektach badania interakcji użytkownika z systemem:
Czy użytkownik jest zadowolony z korzystania z usługi? (H - happiness)
Jakie zaangażowanie wykazuje użytkownik na styku z usługą? (E - engagement)
Czy użytkownik (nowy, właśnie pozyskany) używa usługi? (A - adoption)
Czy użytkownik jest lojalny, czy wraca do usługi? (R - retention)
Czy użytkownik wykonuje istotne dla firmy zadania z sukcesem? (T - task success)
A teraz zagadka logiczna. Wyobraź sobie, że jesteś Product Managerem odpowiedzialnym za rozwój i monetyzację serwisu, dzięki któremu ludzie doświadczający wykluczenia społecznego (np. ze względu na orientację seksualną, wyznawaną religię, poglądy polityczne) mogą skorzystać z pomocy psychologa. Usługa umożliwia rejestrację wizyty u specjalisty, gdzie pierwsze spotkanie ze specjalistą jest bezpłatne i wymaga podania danych osobowych w procesie rejestracji. Ostatnio robiłeś redesign formularza rejestracji, dodałeś odpowiednie zdarzenia (events) w Google Analytics i jesteś w stanie zbadać konwersję na formularzu rejestracji. Oznacza to, że wiesz, jaka liczba spośród wszystkich napływających do usługi użytkowników, rozpoczęła proces rejestracji, by umówić wizytę z psychologiem (stosunek liczby wypełniających formularz względem wszystkich użytkowników odwiedzających portal w danym czasie, najlepiej z podziałem na nowych użytkowników i tych już pozyskanych). Wiesz też, jaka liczba spośród wszystkich podjętych procesów rejestracji zakończyła się sukcesem, a jaka porażką (crush rate).
Jak zbadasz, co tam się dzieje ciekawego z użytkownikami? Ja zabrałabym się za to w ten sposób:
zaglądam do Google Analytics, widzę, że adopcja formularza rejestracji wynosi zaledwie 10%. Oznacza to, że tylko 10% napływających użytkowników podjęło próbę rejestracji do usługi
bawię się w detektywa dalej - badam, jaki % z tych, co podjęli próbę wypełnienia formularza (przypominam: jest ich 10%), zakończyli tę próbę z sukcesem (crush rate). Tu sprawa wygląda dobrze - niemal wszyscy z nich zarejestrowali się bez problemu i umówili wizytę u psychologa.
Jakie z tego wnioski? Ano takie, że z formularzem, prawdopodobnie, wszystko w porządku. Moje więc PM-owe działania skupią się na tym:
w jakim miejscu osadzony jest formularz rejestracji? może jest niewidoczny lub zbyt głęboko osadzony w strukturze systemu?
może brakuje informacji o bezpiecznej rejestracji i użytkownicy nie mają pewności, że ich dane są odpowiednio chronione, dostępne... no właśnie, dla kogo?
może zbyt mało widoczna lub w ogóle niedostępna jest informacja, że pierwsza wizyta jest bezpłatna?
może formularz wygląda przerażająco? jest za długi, wymagający podania danych, które nie są pod ręką? (np. peselu?)... ale wówczas to crush rate byłby wysoki...
Oczywiście, pomysły można mnożyć, a teraz chciałabym Ci powiedzieć, jak możesz wykorzystać tę wiedzę, że problem leży w adopcji użytkowników do usługi:
jako UX designer / product designer czy jakkolwiek Cię zwą w strukturze firmy, będziesz wiedział, gdzie jest punkt spustowy wywołujący ból i niepewność użytkowników i usuniesz go - poprawisz interfejs i sprawdzisz, czy adopcja również się poprawiła
jako Product Manager, będziesz wiedział, jak zaplanować prace w sprintach, będziesz też super wiarygodny, bo będziesz wiedział "dlaczego" warto podjąć się wprowadzenia zmian w interfejsie
jako Analityk biznesowy, będziesz wiedział, co powinno znaleźć się w specyfikacji / w wymaganiach biznesowych, pomożesz zaplanować właściwe scenariusze testowe
jako człowiek bez względu na rolę w pracy, będziesz zadowolony, bo wiesz, a nie wróżysz z fusów
Podziel się wiedzą o użytkowniku z deweloperami!
Częstym błędem jest posiadanie danych o użytkownikach i brak nawyku dzielenia się tymi danymi z innymi członkami zespołów projektowych. To wielka strata dla firmy i dla projektanta, który tę wiedzę chowa w swoich pliczkach, zamiast trąbić o tym kim jest użytkownik przy każdej okazji - w kuchni przy obiedzie, na refinementach, planningach i podczas procesu projektowania. Posiadanie wiedzy o użytkowniku:
buduje świadomość, jak dbać o użytkownika - zaspokajać jego potrzeby i rozwiązywać jego problemy
zwiększa wiarygodność wymagań biznesowych, w tym wiarygodność zaprojektowanych rozwiązań funkcjonalnych i samych prototypów
wzmacnia poczucie sensu wykonywanych prac - zespół projektowy wie, dlaczego do wdrożenia wzięliśmy właśnie taki, a nie inny zestaw wymagań
Piękne i ciekawe. Narzędzia do badań podam w kolejnym artykule, a teraz zachęcam Cię byś obejrzał webinar o tym, jak mądrze rozwijać usługi w sieci.
Autor:
Marta Steiner
Subskrybuj newsletter na stronie głównej bloga lub napisz: info@everydayrocket.com.