Research cz. 2 Persony i ścieżki użytkownika
W przypadku Research’u, brakuje mi kroku pomiędzy Develop a Test, bo Develop, to byłoby wykonanie właściwego badania, ale możemy się umówić, że dobre badanie kończy się wnioskami, więc Develop to bedzie przygotowanie tychże wniosków.
A co z proto-personami? Czyli takimi „z głowy”. No cóż, jest to założenie, a jak mnie znacie, to wiecie, co ja sądzę na temat założeń. Trzeba być świadomym, kiedy coś zakładamy.
Moje zdanie jest takie, że jak robimy kolejny system, który kierowany jest do przebadanej wcześniej grupy ludzi, np. konkretny segment konsumentów, albo jakaś grupa społeczna czy zawodowa, możemy przyjąć pewne założenia, że borykają się z podobnymi problemami oraz mają podobne potrzeby.
Jeśli natomiast projektujemy coś niszowego albo nowego, byłabym ostrożna. Bardzo mało ludzi myśli i czyni tak, jak nam się wydaje.
Pewnym uproszczeniem person będą po prostu role, precyzujące co dana osoba (o danej roli) będzie robiła w systemie, oraz informację pomocniczą, na jakim urządzeniu.
To jest przykładowy szablon persony. Można dodać zdjęcie, natomiast uwaga z polem „Description”. Tego pytania nie zadajemy osobom, to sobie wymyślamy i to tylko po to, żeby „uczłowieczyć” personę. Podobnie jest z cytatem. Jedna persona to jest zbiór osób, to nie jest profil tylko jednej osoby, a więc cytat, musi być taki, który najlepiej odzwierciedla co każda z tych osób mogłaby powiedzieć.
Czym persony nie są.
Nie są profilem wszystkiego, czym dana osoba (w tym przypadku księgowa) się zajmuje. Dobre persony są ograniczone do kontekstu systemu, który projektujemy. „Zaśmiecanie” person niepotrzebnymi informacjami bardzo zamazują obraz i nie wiadomo na czym się skupić.
Uwaga! Nie znaczy to, że persona ma się ograniczyć jedynie to tych potrzeb, które wejdą w zakres produktu. Persona może służyć jako roadmapa na wiele lat do przodu, ale zawsze powinna być zamknięta w jakiś kontekst. Po jakimś czasie persony będą już przestarzałe i trzeba będzie je uaktualniać, jak dowiadujemy się nowych rzeczy o naszych użytkownikach. Dotyczy to w szczególności długowiecznych produktów cyfrowych.
Ścieżki użytkownika, czyli którędy drepcze user? Mogą być tworzone na różnych poziomach szczegółowości. Żeby je zrozumieć, trzeba zacząć je tworzyć. Od czego użytkownik zaczyna swoją przygotę z systemem? Co robi następnie? A co, kiedy jest wiele różnych ról? Na przykład, zatrudniamy pracownika. Najpierw trzeba go poinformować, że szukamy, następnie przedstawić ogłoszenie o pracę, pozwolić zaaplikować, przejrzeć aplikację, ewentualnie zaprosić do dalszych etapów, pozwolić pozostałym pracownikom się wypowiedzieć i ostatecznie zatrudnić, bądź odrzucić, o czym wypadałoby zainteresowanego poinformować.
To jedna z możliwych ścieżek. Ale mogą też być o wiele bardziej szczegółowe, np. jeden wycinek z tego wysokopoziomowego procesu, powiedzmy samo aplikowanie. Zaczynamy od konkretnego ekranu, następnie użytkownik musi wypełnić kolejne pola. Niektóre obowiązkowe, inne opcjonalne. W pewnym momencie kliknie „Aplikuj” i być może otrzyma maila z potwierdzeniem.
UX ponadto mierzy jakie emocje towarzyszą na każdym kroku, z jakich urządzeń korzysta, itp, itd.
Czasami analityk biznesowy narysuje jak użytkownik powinien korzystać z systemu, a UX research wróci z zupełnie innymi krokami (życie!) Różnice pomiędzy jednym obrazkiem a drugim, to właśnie „gapy”.
Możecie się jeszcze spotkać z pojęciem „Flow”. User Journey to rodzaj flow (po polsku, to po prostu przepływ). Znaczy, którędy płyną informacje. Przyjęło się, że flowy są o wiele mniejsze i bardziej szczegółowe niż journey’e.
Journey, to dosłownie wyprawa, duże kroki i szeroki kontekst. Flow, to szczegóły każdego etapu wyprawy.
NN Group proponuje jeden z wielu szablonów, jak można stworzyć User Journey.
Niektórzy twierdzą, że ścieżki użytkownika nie są niezbędne. Że są „nice to have”. Nie zgodzę się. Nieznajomość „lotu ptaka” zwykle prowadzi co ślepych zaułków, które skutkują dziwnymi doraźnymi rozwiązaniami, które przysparzają użytkownika o ból głowy.
Zatem sprawdźmy, jaką wartość przyniósł cały ten „risercz”.
Pewien koniec fazy badawczej, zwykle wyznacza spotkanie, na którym omawia się dotychczasowe wyniki. Słowa „pewien” i „dotychczasowe” nie są przypadkowe. Dowiadywanie się rzeczy o naszych użytkownikach (i biznesie) w zasadzie nigdy się nie kończy.
Kich-off, to takie właśnie spotkanie. Zderzamy z nim potrzeby biznesowe z potrzebami użytkowników. Zwykle jest wiele sprzeczności i cała zabawa polega na tym, żeby znaleźć złoty środek, gdzie oba zespoły są szczęśliwe.
Warto też w tym momencie ustalić zasad dalszej współpracy.
