Analiza konkurencji

Przegląd Analityki produktu (GA, Yandex, Excel ...)

Wywiady ze stakeholderami

W pierwszym kroku chcemy poznać wartości, jakie wyznaje klient, pomoże nam to dopasować się do jego oczekiwań oraz wizji na produkt/zmiany. Klient na pewno ma zdefiniowaną jakąś strategię rozwoju. Często może nawet o tym nie wiedzieć. Cele marketingowe, selling pointy, to też przykłady strategii. Chcemy od klienta dostępu do jak największej ilości zasobów, które dadzą nam informacje o nim oraz produkcie.

Materiały marketingowe, prześledzenie jego strony. Jeśli istnieje to koniecznie dostęp do danych - Google Analytics, Yandex Metrica, Hotjar, Excel. Sprofilowanie typowego klienta.

Warto pamiętać o zdefiniowaniu stakeholderów produktu. Często osoba, która się z nami kontaktuje nie musi posiadać największej wiedzy o produkcie. Warto porozmawiać ze sprzedawcami/marketingowcami. Poznać proces sprzedaży - wiele nam powie o tym jak klient postrzega produkt oraz jego silne strony. Warto spytać o znaną konkurencję, rozwiązania, które się podobają itp.

Z zebranych danych wyciągamy high levelowe wnioski. Informacje, które zbieramy możemy kolekcjonować w formie moodboarda. Z tej fazy warto przygotować krótką prezentację oraz przedstawić ją interesariuszom aby zaangażować ich już od początku oraz zebrać szybko feedback. Jak najszybsze wykrywanie błędów jest dobrym podejściem.

Dokumentowanie pracy na każdym etapie zaowocuje na wielu płaszczyznach. Klient będzie widział, że praca została wykonana, za co płaci. Na koniec pracy nie trzeba będzie przygotowywać ogromnej prezentacji wstecz szperając w pamięci co to tam zrobiliśmy i postanowiliśmy.

Do wniosków z fazy strategii warto wracać, jeśli w późniejszych etapach pojawią się pytania i problemy z podjęciem decyzji. To będą nasze kluczowe wytyczne pokazujące wspólnie (razem z klientem) obrany kierunek.

Audyt rozwiązań konkurencji

Analiza contentu klienta

Audyt rozwiązania klienta

Trendy

Badania, raporty

Po otrzymaniu od klienta kluczowych informacji oraz zdefiniowaniu strategii czas na pogłębienie wiedzy domenowej. Faza discovery pozwoli nam zanurkować bardziej w świecie klienta oraz produktu.

Zaczynamy od przeanalizowaniu materiałów podesłanych przez klienta. Mogą nam one poszerzyć założenia z wcześniejszej fazy.

Szukamy na własna rękę konkurencyjnych rozwiązań. Nie ograniczamy się do platformy, w którą celuje produkt. Możliwe, że bardzo podobny pomysł istnieje na innym rynku, warto sprawdzić. Przykład: Jeśli klient chce stworzyć konfigurator/generator koszulek szukamy konkurencji oraz tego jak wyglądaja konfiguratory innych produktów jak tkaniny, akcesoria itp. Chcemy zobaczyć jak można zrobić to inaczej.

Ze zbioru rozwiązań konkurencyjnych, które mogliśmy dostać od klienta oraz znaleźć sami wybieramy kilka najciekawszych. Przeprowadzamy ich audyt: mocne, słabe strony. Dobre/złe/ciekawe rozwiązania. Próbujemy znaleźć selling pointy.

Jeśli produkt już istnieje, a my go będziemy rozwijać/przerabiać - przeprowadzamy podobny audyt również dla niego.

Podczas zgłębiania rynku, na którym ma istnieć produkt staramy się znaleźć powtarzalne elementy, wzorce trendy. Możemy je wykorzystać jako nasza mocną stronę lub próbować je złamać w zależności od tego, co lepiej będzie odpowiadało preferencjom klienta.

Wysoce prawdopodobne, że część naszej pracy już ktoś kiedyś wykonał. Mając informacje od klienta o potencjalnych użytkownikach aplikacji staramy się znaleźć raporty, analizy z nimi (z ich zachowaniami) związane. Przykład: Klient chce wejść ze swoim produktem w rynek analizy preferencji zakupowych wykorzystując do tego iBeacon. W sieci możemy znaleźć przydatne informacje na ten temat: https://kk.org/extrapolations/tag/time-spent-shopping/ .

Przydatne linki do researchu oraz audytu:

http://boxesandarrows.com/competitive-analysis-understanding-the-market-context/

https://www.uxpin.com/studio/ebooks/ux-checklist/

https://uxdesign.cc/ux-checklists-bf2dda85787f

Wnioski z tej fazy spisujemy w formie prezentacji, którą przedstawiamy klientowi, zanim pójdziemy dalej aby poznać jego opinię na ten temat. Warto często konsultować się z klientem, aby brał czynny udział, mógł nas wyprowadzić z błedu oraz.... widział za co płaci

Persony

Scenariusze użycia (przez Persony)

Customer Journey?

Card sorting

Analiza konkurencji

SWOT (od klienta)

Przegląd Analityki produktu (GA, Yandex, Excel ...)

Po fazie odkrywania - researchu należy zwalidować nasze założenia strategii. Istnieje możliwość, że po uzyskaniu większej ilości informacji, są one już nieaktualne.

W tej fazie możemy stworzyć persony odpowiadające naszym typowym użytkownikom. Techniki tworzenia oraz używania person są dobrze zaprezentowane na YouTube np: https://www.youtube.com/watch?v=vZ578SqL1oA  https://www.youtube.com/watch?v=tCAeHfvsjoM

Materiały, które stworzymy na tym etapie, wymienione na wcześniejszym slajdzie, pozwolą nam lepiej zrozumieć kto oraz jak będzie korzystał z naszego produktu. Arkusze person czy też User Stories powinny nawiązywać wizualnie do naszych prezentacji ponieważ klient zwróci na nie uwagę. Persony to jeden z pierwszych buzzwordów, na które trafi.

Mapa strony

Wireframe

Wybranie frameworka*

Prototypy

Testy korytarzowe - testowanie/zbieranie feedbacku na podstawie prototypów pokazanych współpracownikom. Można pomyśleć o stworzeniu cyklicznych spotkań z grupą zainteresowanych osób w firmie, które będą naszymi królikami doświadczalnymi​

Assety, które powstają na tym etapie powinny być konsultowane z zespołem developerów, którzy będą go implementować jeśli istnieje taka potrzeba aby zwalidować pomysł pod względem możliwości implementacji.

Następnie rozwiązania pokazujemy klientowi i jak we wcześniejszych etapach - dokumentujemy postęp pracy w formie prezentacji z ciekawymi widokami, iteracjami pomysłów oraz funkcji.

Makiety / Prototypy Hi-Fi

"Final" Review

Assety

Przekazanie do dev

Testy

Na tym etapie pracujemy nad finalnymi plikami. Nie ma znaczenia czy będą to .sketch czy też widoki złożone już ze statycznego .html'a. Wytwarzamy assety high-fidelity czyli ze wszystkimi detalami. Pixel perfect. W zależności od projektu mogą być one przekazane do wewnętrznego dev lub do klienta.

Ważne, aby przeprowadzić final review - zorganizować spotkanie ze stakeholderami, w tym zespolem developerów aby wszyscy mogli zapoznać się z efektem naszej pracy i móc zadać pytania. Jeśli ludzie będą brali czynny udział w spotkaniu może nam ono zagwarantować wczesne (tanie) wykrycie problemów.

Jeśli jest to możliwe powinniśmy dążyć do testów po implementacji. Nie chodzi tutaj o testy z użytkownikami ponieważ najprawdopodobniej nie będzie kolejnej iteracji, ale o odebranie pracy zespołu programistów przez projektantów oraz biznes. Można powiedzieć, że kolejne review mające na celu sprawdzenie poprawności implementacji czegoś, na co wszyscy się zgodzili, że tak właśnie ma wyglądać/działać. Warto aby w systemie znajdowały się jakieś realne dane.