HEART by example

Poćwiczmy. Wyobraź sobie, że jesteś Product Managerem odpowiedzialnym za rozwój i monetyzację sklepu internetowego, w którym (po zarejestrowaniu się) można wystawić na sprzedaż i kupić nowe oraz używane ubrania. 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 w danym czasie rozpoczęła proces rejestracji, aby uzyskać dostęp do funkcjonalności sprzedaży i kupna produktów w sklepie. Wiesz też, dzięki wskaźnikom task success, jaka liczba spośród wszystkich podjętych procesów rejestracji zakończyła się sukcesem, a jaka porażką. Jesteś świadomy, że formularz to oczko w głowie produktu, bo tylko po rejestracji użytkownicy mogą kupować i/lub sprzedawać towary i ten właśnie proces generuje przychód firmy.

Jakie dane sprawdzisz, by mieć pewność, że formularz „robi dobrą robotę”?

Ja w podobnej sytuacji wykonuję takie działania: 

• loguję się do narzędzia Google Analytics. Widzę, że adopcja formularza rejestracji wynosi 7%. Oznacza to, że 7% napływających użytkowników podjęło próbę rejestracji do usługi; warto nadmienić, że przed redesignem adopcja była wyższa i wynosiła 10%.
• Badam, jaki odsetek z tych 7%, którzy podjęli próbę wypełnienia formularza, zakończyli ją z sukcesem. Tu sprawa wygląda dobrze – niemal wszyscy, bo 92,9% z nich zarejestrowało się bez problemu i weszło głębiej w swoje konta; przed redesignem wynik był niższy – 6% z 10% użytkowników, którzy podjęli próbę rejestracji, zakończyło ją z sukcesem.
• Zaglądam do HotJara i sprawdzam „nagrania”, by zobaczyć, jak zachowywali się użytkownicy na formularzu.
• Kopię dalej w HotJarze i sprawdzam Heat Mapy (move, scroll, click). Widzę, że kliknięcia we wszystkie pola rozkładają się w miarę równo, na każdym z pól jest czerwono, co oznacza, że użytkownicy wypełniają pola formularza.

Moja wstępna diagnoza: z konstrukcją formularza i jego działaniem jest wszystko w porządku, o czym świadczy wysoki wynik 92,9% osób, które kończą wypełnianie formularza z sukcesem; użytkownicy nie napotykają na blokady w procesie wypełniania formularza – dobór pól, ich ułożenie, walidacja, treści zgód są poprawne i nie sprawiają problemów.

Drążę dalej: czy po redesignie miejsce osadzenia formularza rejestracji się zmieniło? Może otoczenie tego elementu (layout) jest inne lub zmienił się UI systemu (inne kolory, czcionki)? Może formularz jest teraz niewidoczny lub zbyt głęboko osadzony w strukturze systemu?

Pierwsze hipotezy do udowodnienia w kolejności od najbardziej do najmniej prawdopodobnej:

1. Formularz po redesignie przestał być widoczny, jest zbyt głęboko schowany w systemie.
2. Formularz ma konkurencję – inne, atrakcyjne dla użytkowników CTA odciągają uwagę od rejestracji. 
3. Brakuje informacji o bezpiecznej rejestracji, w związku z czym użytkownicy nie mają pewności, że ich dane są odpowiednio chronione. 
4. Formularz wygląda na skomplikowany (jest za długi, wymaga podania danych, których użytkownicy nie mają pod ręką, przez co w ogóle nie biorą się za jego wypełnianie).

Hipotezy można mnożyć, ale zamiast tego podpowiem Ci, jakie korzyści będziesz miał, jeśli skupisz się na metrykach i danych ilościowych z narzędzi pomiarowych.

• Dzięki śledzeniu metryk z modelu HEART jako specjalista UX namierzysz element wywołujący ból/niepewność użytkowników i usuniesz go – poprawisz interfejs i sprawdzisz, czy adopcja również się poprawiła (jak w przykładzie powyżej).
• Jako Product Manager odpowiednio zaplanujesz pracę w sprintach. Okażesz się też super wiarygodny, bo uzasadnisz „dlaczego” warto podjąć się wprowadzenia zmian w interfejsie.
• Jako analityk biznesowy, będziesz wiedział, co powinno znaleźć się w specyfikacji/ wymaganiach biznesowych, pomożesz przygotować właściwe scenariusze testowe.
• Jako człowiek, bez względu na rolę w pracy, będziesz zadowolony, bo działasz na podstawie wiedzy, a nie uprawiasz czary, w które sam nie wierzysz.

Wiedza musi płynąć ponad zespołami

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 czeluściach swojego komputera, zamiast przekazywać ją deweloperom i przedstawiać ją w wymaganiach biznesowych. Posiadanie informacji o użytkowniku:

• buduje świadomość, jak o niego dbać – 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ń.

Jeśli już zająłeś się adopcją użytkowników do formularza i sprawdzaniem hipotez, to warto, aby Twoje myśli znów powędrowały w stronę formularza wykluczenia problemów technicznych. Zastanów się jeszcze nad poniższymi kwestiami:

• Czy dane są poprawne? Upewnij się, że formularz po redesignie został dobrze otagowany w GTM i zostały dla niego założone zdarzenia w Google Analytics.
• Upewnij się, że zgody przygotowane przez dział prawny dołączone do formularza nie odstraszają użytkowników zawiłą, trudną do zaakceptowania treścią.
• Zbadaj demografię użytkowników i dowiedz się o nich nieco więcej – jeśli usługę kierujesz do młodych ludzi, a w wyniku działań akwizycyjnych przychodzą do Ciebie osoby starsze, to należy poprawić targetowanie kampanii marketingowych.
• Jeśli targetowanie okaże się poprawne, to znów… należy pomyśleć o użytkownikach i ich potrzebach, przyjrzeć się założeniom biznesowym i funkcjonalnym produktu.

Na końcu pomyśl jeszcze raz, co jest siłą pociągową usługi, czyli co generuje przychód, a także w jaki sposób ten formularz wpływa na sukces usługi, którą rozwijasz. Jeśli formularz jest bramą do revenue, bo bez niego nie ma procesów kupna i sprzedaży – mierz, analizuj i optymalizuj do skutku. Nie ma nic ważniejszego w działaniach UX i produktowych niż dostarczanie wartości biznesowej użytkownikom (tego, po co przyszli) w zgodności z celami biznesowymi organizacji.