Wypuszczanie Produktów i Startupów na Rynek: Wyniki audytu

0:00W zależności od tego, jak złożony jest nasz produkt, projekt, aplikacja.

0:04Będziemy musieli poświęcić parę dni na prawdopodobnie na audyt, ale chciałbym Ci

0:09powiedzieć, że możemy oczywiście to zrobić w sposób zwinny, tak jak robią to

0:13startupy, a możemy to zrobić w sposób moim zdaniem niepotrzebny, czyli

0:18tak jak robią to duże firmy.

0:20Zlecić gdzieś ten audyt, zatrudnić jakąś agencję UX ową.

0:24Oczywiście zakładam, że chcemy to zrobić po gospodarsku, przeznaczyć

0:29na to jak najmniej zasobów.

0:30Ale jest jeszcze jedna ważna rzecz, która płynie z tego, że tak naprawdę

0:34to my powinniśmy robić ten audyt.

0:36To naszym, naszym zadaniem jest wyznaczenie tego kierunku produktu i nie

0:41powinniśmy raczej nikogo do tego zatrudniać.

0:43To są naprawdę jedne z najważniejszych rzeczy, które musimy zrobić przed

0:46premierą, więc opracowanie tego jest po prostu błędem moim zdaniem.

0:51I jeśli już zrobimy te screeny, przejrzymy te nagrania, przejrzymy

0:55też Hotjar i tak dalej.

0:57Warto wytypować osoby w naszym zespole Pole, albo najlepiej, jeśli nasz zespół

1:02jest większy jeszcze zrobić jakąś jedną większą sesję brainstormującą te wszystkie

1:06rozwiązania na poziomie, powiedzmy bardziej ogólnym.

1:09Czyli na tym etapie nie schodzimy jeszcze w każdy kolejny przycisk, w każdy

1:13komponent, tylko przedstawiamy te wyniki takiego audytu i w

1:18zespole zastanawiamy się nad tym, jak można by było przygotować do premiery nasz

1:22produkt, aby jego ostateczny kształt był po prostu lepszy.

1:25Na bazie tego feedbacku i na bazie tego feedbacku bardzo często po prostu

1:29poszczególne komponenty czy elementy naszego procesu onboardingu i tak dalej,

1:35zostają tutaj wyscreenowane znowu w gamie, a obok nich znajdują się bardzo konkretne

1:41rady, co powinno się tutaj wydarzyć.

1:43Na przykład, że zdjęcie powinno być domyślnie powiększane.

1:47Pole opisu powinno zawierać edytor tekstowy, możliwość wyboru kilku zdjęć

1:51jednocześnie, to powinna być i tak dalej.

1:52Czyli wszystkie te uwagi po prostu zestawiamy z istniejącym ekranem i

1:57funkcją, która aktualnie istnieje w naszym narzędziu i wypisujemy już na zasadzie nie

2:01kciuk w górę, kciuk w dół, tylko po prostu wypisujemy, co powinno być tutaj zrobione.

2:06I najczęściej iterujemy to w zespole tak, aby każdy miał możliwość też wypowiedzieć

2:10się i przeliterować przez ten feedback.

2:13To też dużo daje, jeśli mamy większy zespół czy founderów, że każdy trochę

2:17lepiej rozumie to jak ta aplikacja będzie na koniec dnia wyglądać.

2:20No i wszystkie te rzeczy są tutaj właśnie wypisane.

2:23To jest akurat jeden fragment tego audytu i jest tutaj też tworzone takie jego

2:29podsumowanie, czyli każdy element naszego produktu.

2:34Na przykład mamy tutaj tworzenie produktu, mamy tutaj jakieś inne rzeczy, ustawienia,

2:39dashboard w przypadku właśnie SAS u i narzędzi to właśnie tak będzie wyglądało,

2:44że każdy obszar, który adresuje nasz produkt jest tutaj wypisane.

2:47W przypadku innych narzędzi typu framework, info, produkty.

2:51Prawdopodobnie będziesz chciał chciała zaadresować każdą z każdy z elementów tego

2:56procesu, czyli od procesu zakupowego, przez proces feedbackowania,

3:01zaangażowania użytkowników itd.

3:03No i sam wygląd oczywiście naszego produktu, dostęp do niego, to jak się go

3:07pobiera to jak można zgłaszać opinie, feedback i cały ten proces

3:11w takim audycie i w jego podsumowaniu powinien się znaleźć.

3:14I tutaj są bardzo konkretne wytyczne, to, co powinniśmy zrobić.

3:17Więc można powiedzieć, że jest to podsumowanie takiego audytu.

3:20I ja też robię to wszystko w fig jamie, tak żeby mieć po prostu w jednym miejscu

3:24wszystkie rzeczy, które są związane z tego typu audytem.

3:28Następnie robimy, robimy.

3:31W przypadku akurat narzędzi robimy podsumowanie tego,

3:36jak to narzędzie się będzie zmieniać.

3:38Czyli przykładowo, jeśli chcemy wprowadzić jakieś zmiany do jednego z menu, na

3:42przykład tu mamy główne menu z karta i zdecydowaliśmy się, że z audytu wyszło

3:47nam, że powinniśmy inaczej podzielić to menu.

3:49No to projektujemy te zmiany.

3:52Uzasadniamy je też, dlaczego te zmiany powinny takie być na bazie właśnie tego

3:57naszego audytu i jak powinniśmy na przykład właśnie zmienić to menu.

4:01Jak powinniśmy zmienić panel ustawień?

4:03Jak powinniśmy zmienić każdy z kolejnych widoków, Czyli albo każdy element

4:07procesu, albo każdy kolejny panel.

4:09Wszystko jest tutaj dosyć jasno wypisane.

4:12Następnie zbieramy sobie informacje do tego, aby

4:18ewentualnie inaczej ułożyć czy rozłożyć opcje w funkcje naszego produktu.

4:22Przykładowo, jeśli mamy w naszym produkcie zakładki

4:26podstawowe ustawienia, ustawienia produktu, warianty ceny.

4:28I uwierz mi, że mimo, że jest to bardzo specyficzne dla Sasa, możesz to spokojnie

4:32odnieść też dla Twojego info produktu nawet.

4:35Bo chodzi tutaj o to, czy mogę na przykład lepiej zrobić rozdziały w moim ebooku, czy

4:41mogę lepiej ułożyć treść, czy mogę lepiej i w jaki sposób ten produkt dostosować,

4:46tak aby ludzie rozumieli go jeszcze lepiej, aby korzystanie z niego

4:49było jeszcze bardziej przyjemne?

4:51No i oczywiście w przypadku Sassa aplikacji Narzędzia będzie to zdecydowanie

4:56bardziej skomplikowane i złożony proces, który będzie się sprowadzał później do

4:59stworzenia nowego UI, tak jak Ci to zaraz pokażę, ale w przypadku prostszych

5:04produktów będzie tego dużo mniej.

5:05Natomiast zawsze ten proces moim zdaniem jest wartościowy i daje sporo,

5:10sporo właśnie tego, co powinniśmy tu poprzestawiać.

5:12Może na przykład ludzie nie rozumieją tego, za co płacą i gdzie klikają w guzik

5:18pobrania produktu, więc powinniśmy to zmienić, przełożyć, może przełożyć to

5:22między zakładkami, może między podstronami, może

5:26dać jakąś informację dodatkową do maila.

5:28To właśnie te wszystkie rzeczy powinny się tutaj znaleźć, w tym, w tym całym audycie.

5:34No i tak to zrobiliśmy, czyli rozdzieliliśmy rzeczy i postaraliśmy się

5:38lepiej na przykład rozdysponować odpowiednie funkcje, które teraz mamy w

5:42karcie pomiędzy różne zakładki, czyli czy to stworzyć nowe zakładki, czy zostawić

5:47istniejące i przypisać tutaj feature'y funkcje, które tutaj albo stąd wypadają na

5:53czerwono, albo tutaj wchodzą, albo się nie zmieniają.

5:56I właśnie w ten sposób zaprojektować od nowa cały układ naszej aplikacji.

5:59Podobnie będę pokazywał Ci tego typu rzeczy w przypadku strony internetowej.

6:04Czym się jeszcze później zajmiemy?

6:06Będę pokazywał Ci jak stworzyć sobie nową site mapę.

6:09Jak zobaczyć jak ludzie korzystają z naszej strony i jak przygotować docelową

6:15strukturę tej strony, taką, jaka powinna być też na bazie

6:20naszego wrażenia tego feedbacku, który zebraliśmy i będziemy to

6:23robić w bardzo podobny sposób.

6:24Więc można powiedzieć, że w tym przypadku robię to osobno dla narzędzia i później

6:28będę robił to osobno dla strony internetowej.

6:30W każdym razie wyniki tego, tego całego researchu powinny skutkować

6:35tym, że będziemy mieli jakby kolejny poziom architektury naszego

6:41narzędzia czy aplikacji ustalony.

6:43Będziemy dokładnie wiedzieli, co chcemy przestawić, co chcemy zrobić, po to, aby

6:47korzystanie z tego produktu było bardziej intuicyjne i po prostu

6:50dawało większą wartość.

6:51Więc wynikiem takiego całego researchu po prostu jest to, że dokładnie mamy

6:56rozpisane, co zmieniamy, gdzie w produkcie I nie robimy tego jeszcze w produkcie,

7:00Czyli nie pracujemy na przykład.

7:01Gdybym chciał zmieniać stronę internetową, nie wchodzę od razu do Webflow i nie

7:04zmieniam tego, tylko raczej robię screeny.

7:06Wszystko robię w fig jamie i piszę co trzeba zmienić.

7:09Nawet jeśli te zmiany są drobne, chcę to mieć wszystko zebrane i

7:12rozpisane w jednym miejscu.

7:13I zwykle odbijam to jeszcze od kogoś, czyli staram się na przykład

7:17właśnie z jakąś osobą z zespołu.

7:19Jeśli mamy co-foundera czy większy zespół, odbić te myśli i po prostu przejść przez

7:23te rzeczy, bo często zdarza się, że jesteśmy zafiksowani na jakieś jedno

7:27rozwiązanie, a ktoś podrzuci nam jeszcze ciekawsze i powie a to w zasadzie dlaczego

7:32w ogóle nie skasujemy tego tego jednego menu, skoro można by było to

7:36przenieść tutaj, to przenieść tutaj?

7:37No i faktycznie w ten sposób zmieniamy trochę to, jak nasz produkt funkcjonuje.

7:41Można powiedzieć, że użytkownicy, którzy są przyzwyczajeni do

7:45używania naszego produktu w jeden sposób, będą musieli przyzwyczaić się do

7:49tego funkcjonowania w inny sposób.

7:50No i musimy pomyśleć tutaj też o tych trade offach.

7:53Czy faktycznie chcemy zmusić ludzi do nauczenia się innej rzeczy, Czy to będzie

7:57tak wartościowe, bo rzeczywiście ta zmiana ma sens.

8:00Czy może lepiej pozostawić to tak, jak jest, bo niektórzy użytkownicy

8:03są już do tego przyzwyczajeni?

8:04Na pewno powinniśmy priorytetyzować nasz przyszły produkt, czyli wersję 1.0,

8:08ponieważ zakładam, że ta nasza cała premiera pozwoli nam dotrzeć do

8:13niespotykanej wcześniej liczby ludzi.

8:15Tych osób będzie dużo więcej, które będą korzystały z naszego produktu,

8:19więc warto to priorytetyzować.

8:20Ale oczywiście trzeba pomyśleć o pewnej kompatybilności wstecznej, zwłaszcza jeśli

8:24już mamy użytkowników, którzy z tego produktu korzystają, więc te rzeczy

8:28też są uwzględnione w takim audycie.

8:29No i można powiedzieć, że to wszystkie wnioski, które z niego płyną.

8:33Wydaje mi się, że jest to bardzo prosty, ale poukładany proces, który

8:37trzeba zrobić na początku.

8:38Polecam Wam do tego figam i narzędzia, o których wspomniałem i rezultaty.

8:42Mam nadzieję, że będziecie już mieli i będą te rezultaty, które wprost są po

8:48prostu tym rozpisanym, całym gotowym, gotową receptą na to, jak produkt

8:53powinien zostać poprawiony.

8:55To wszystko na teraz i w sekcji związanej z audytem.

8:58Do usłyszenia już za chwilę.