Przygotuj się do Miesięcznego Design Sprintu
W tym rozdziale dowiesz się jakie są nasze doświadczenia w tworzeniu MDS i wrzucimy rady odnośnie całego procesu
Dlaczego Design Sprint działa?
Design Sprint to 4-5 dniowy framework pracy, który kończy się przygotowanym prototypem, przetestowanym z realnymi potencjalnymi użytkownikami. Zobacz filmik Michała, dlaczego Design Sprint działa?
Czym właściwie jest prototyp, który powstaje podczas Miesięcznego Design Sprintu?
Prototyp, jak wszystko co robimy w życiu, powinien mieć pewien określony cel.
Prototyp to, w skrócie, zamarkowany produkt finalny, pozbawiony realnych funkcji, który ma na celu stworzenie wczesnej wersji produktu.
Wczesna wersja produktu posłuży Ci, w głównej mierze, jako baza do przeprowadzenia testów z użytkownikami. Przyda się również w sytuacjach, kiedy musimy pokazać Proof of Concept (wykazanie słuszności wymyślonego produktu) przed zarządem, czy jako baza do dalszego rozwoju.
Prototypowanie to najlepsza forma testowania wymyślonych rozwiązań. Daje nam ono możliwość zaprezentowania, sobie i innym, chociaż namiastki docelowego produktu. Dobrze zrobiony prototyp musi oddać najlepszą możliwą wartość dla końcowego odbiorcy, a zarazem jest to najlepszy i stosunkowo najtańszy sposób na weryfikację, czy wymyślony przez nas koncept ma jakikolwiek sens.
Kiedy warto postawić na prototyp?
Dzięki szerokiej gamie narzędzi, prototypowanie może odbywać się zarówno na początku cyklu życia produktu, jak i na samym końcu. Dlaczego? Dlatego, że faza testów nie powinna się kończyć - zawsze można coś poprawić, ulepszyć. Skok konwersji nawet o jeden punkt procentowy może okazać się zbawienny w skutkach, a przecież zarząd zawsze lubi maksymalizować przychody i zyski.
Należy podkreślić więc fakt, że utrzymywane są ze sprzedaży, na którą same zapracowały wraz z zespołem. Optymalizacja tego procesu najczęściej zależy od właściciela produktu, po angielsku Product Ownera. To Product Owner jest odpowiedzialny za optymalizację procesów, dowożenie wartości i kształt, w jakim finalnie znajduje się produkt.
Co jednak w przypadku, kiedy mamy już produkt, ale nie zarabia on tak, jak byśmy oczekiwali? Co kiedy mamy pomysł na produkt, ale nasz budżet jest ograniczony? Co w momencie, kiedy mamy insighty z rynku, że nasz produkt nie spełnia oczekiwań użytkowników? W końcu, co w przypadku, gdy zarząd domaga się prezentacji pomysłu, aby zatwierdzić budżet na rozwój, a Ty masz ograniczony budżet na prezentację i walidację pomysłu? W ten czas, z wielką pomocą przychodzi właśnie prototypowanie.
Prototypowanie ma jedną z kluczowych w biznesie zalet - minimalizuje ryzyko, że produkt się nie uda.
Oczywiście, nie działa to w ten sposób, że wyklucza ryzyko całkowicie - ryzyka w żadnym z przypadków nie da się uniknąć, ale da się je zminimalizować do minimum właśnie dzięki prototypowaniu.
Jak widać jest wiele scenariuszy, w których warto w ostrożny sposób zweryfikować dalszy kierunek rozwoju produktu. Nie ma tu jednak jednej złotej zasady - faktem jest jednak to, że w Movade stawiamy na zrobienie prototypu w 90% realizowanych projektów. Wynika to głównie z szacunku do ogromnych kosztów wytwarzania produktów. Najlepszym sposobem zaś oszczędności jest weryfikacja zakresu projektu i wyrzucenie zbędnych elementów produktu.
Zespół produktowy powinien czuć jaka jest biznesowa wartość prototypu
Prototyp w oderwaniu od biznesu nie jest zbyt wiele wart. Trzeba to powiedzieć jasno. Dlatego bardzo ważnym aspektem prototypowania jest odpowiedzialność biznesowa. Jak pisałem wcześniej, każdy produkt tworzony jest po to, by produkować zysk i to jest podstawowy element egzystencji każdego produktu i firmy, która za nim stoi. Biznesowo więc przetestowany prototyp daje nam podstawy, aby sądzić, że zaspokajamy potrzebę rynku.
Tworzenie prototypów daje też inną wartość: daje pewność, że nasz produkt ma biznesowe szanse na rynku. W naszym podejściu nieoderwalnym od prototypowania procesem jest Business Model Canvas. Business Model Canvas to dzisiaj jeden z najpopularniejszych szablonów do opracowywania modelu biznesowego, głównie przez startupy, ale nie tylko. Alex Osterwalder, który jako pierwszy opisał BMC twierdzi, że:
“Model biznesowy opisuje przesłanki stojące za sposobem w jaki organizacja tworzy wartość oraz zapewnia i czerpie zyski z tej wytworzonej wartości”
Wspomniany Osterwalder podnosi więc nie tylko temat zarabiania, ale też wartości wynikającej z produktu i tego, co chcemy przekazać. Daje to więc wstęp do serii pytań a’propos problemu zarabiania:
jaką wartość chcesz oferować?
jaką relację ze swoimi klientami chcesz nawiązać?
dla kogo tę wartość tworzysz (grupa docelowa)?
jakie potrzeby mojej grupy docelowej ta wartość zaspokaja?
czy ktoś inny już taką wartość tworzy?
czego potrzebuję by wartość wytworzyć i ile to kosztuje?
ile klienci są w stanie za tą wartość?
czy to w ogóle jest opłacalne?
Stworzenie BMC, a także w oparciu o niego prototypu daje nam zdecydowanie mniejsze szanse na “zawalenie” projektu, co finalnie przekłada się też na lepszą jakość produktu.
Prototypowanie jest też z założenia metodą szybszą i tańszą niż budowanie MVP w oparciu o zespół deweloperski, który nierzadko wymaga nakładów finansowych w setkach tysięcy złotych. Szybki rozwój dziedzin UX/UI, który ma związek z większym zapotrzebowaniem na projekty IT, przedefiniował podejście do tworzenia produktów i pozwolił zarówno Product Ownerom, jak i projektantom i programistom spojrzeć na to, co jest naprawdę ważne. Na biznes. Potrzeba wydajnego tworzenia produktów, sprawdzenia ich na rynku bez ponoszenia wielkich kosztów, zebrania feedbacku z rynku to dzisiaj podstawa. Stale rosnące ceny usług programistów sprzyjają rozwiązaniu zwanemu prototypowaniem i są sporą oszczędnością. Dzięki prototypowaniu możemy zweryfikować inicjalne założenia i sprawdzić model biznesowy stosunkowo szybko, a na pewno zdecydowanie szybciej niż dopiero po ukończonym developmencie wykonanym przez zespół programistów, jak to się dzieje w przypadku MVP.
Czy zdajesz sobie sprawę z problemu użytkowników? Czy on istnieje?
Zdefiniowanie problemu przed rozpoczęciem warsztatów jest z reguły zadaniem trudnym. Problemów może być wiele, dlatego zdefiniowanie jednego, czy dwóch kluczowych to podstawa udanego prototypowania. Zespół produktowy zanim przystąpi do warsztatów powinien zweryfikować swoją wiedzę na temat problemu, który powinien zostać rozwiązany. Powinien być także w stanie ocenić jakie luki w nim występują, żeby móc się z nim zmierzyć. Z taką wiedzą zespołu produktowego dużo łatwiej będzie wprowadzić zespół projektowy na właściwe tory i skrócić czas wprowadzania w projekt i problem.
Zrozum problem zanim będzie za późno
Do zrozumienia problemu, który chcemy rozwiązać musisz posiadać bieżące informacje o zachowaniach swoich użytkowników.
Bez tego ani rusz. Po głębokiej analizie danych, które masz w swoim posiadaniu, a także po weryfikacji założeń i odpowiedzi na postawione pytania powinieneś posiadać wiedzę, jakie problemy mają Twoi użytkownicy.
Wiele produktów robionych jest wyłącznie w oparciu o projektowanie i budowanie rozwiązań, bez skupienia się na istocie problemu, co uważam za nonsens. Doświadczenie użytkowników i ich problemy powinny być dla nas podstawą do realizacji każdego produktu.
W mojej ocenie nie ma możliwości zrobienia dobrego produktu bez poznania istoty problemu. Dlatego cały zespół powinien zdefiniować problem, który jest dla wszystkich zrozumiały i jasny - tak, aby w późniejszej fazie realizacji produktu wszystkie pomysły dotyczyły rozwiązania zdefiniowanego problemu. Wszystkie inne pomysły powinniśmy wrzucić do “garażu”, żeby móc z nich ewentualnie skorzystać w przyszłości.
Należy jednak podkreślić, że sytuacja kiedy ciężko znaleźć kluczowy problem może zaistnieć. Po prostu coś nie działa i nie wiadomo dlaczego, bo metryki są w naszej ocenie w porządku - warsztaty mają jednak za zadanie wyeksplorować najważniejsze punkty zapalne, zatem prędzej, czy później poradzimy sobie z taką sytuacją.
Poznanie istoty problemu - co warto robić na Miesięcznym Design Sprincie
Świadomość tego, co należy prototypować to klucz do rozwiązania problemów użytkowników, które zdefiniowaliśmy i potwierdziliśmy na warsztatach.
Z najczęściej prototypowanych rzeczy możemy wyróżnić:
Aplikacje mobilne
Aplikacje webowe
Aplikacje natywne
Serwisy internetowe
Sklepy internetowe
Zdecydowanie ważniejsze od tego na jaki nośnik będziemy prototypować jest to, co faktycznie chcemy przetestować na prototypie.
Dość często chodzi nam o przetestowanie produktu, aby potwierdzić nasze założenia i potrzeby użytkowników, w momencie, kiedy produkt nie jest w ogóle jeszcze dostępny na rynku. W tym momencie, po procesie warsztatowym określamy problemy i cele, na bazie wywiadów z użytkownikami, i realizujemy prototyp, który znowu pokazujemy użytkownikom.
Istnieje jednak jeszcze prototypowanie produktów, które już działają, aby sprawdzić co możemy usprawnić albo ulepszyć.
Na potrzeby przykładu załóżmy więc pewien scenariusz.
Na potrzeby przykładu załóżmy więc pewien scenariusz.
Mamy sklep internetowy, sprzedający buty sportowe. Z posiadanych przez nas danych wynika, że konwersja nie jest zadowalająca. Co zrobić? Jak ją polepszyć? Na potrzeby tego scenariusza wprowadzamy hipotezę. W tym przypadku najwięcej użytkowników porzuca zakupy na kroku numer X. Nie wiemy jednak co tak naprawdę jest problemem - może winne jest całe flow zakupowe, może mamy za mało informacji o produkcie, a może cena jest za wysoka, a może mamy źle nazwany button procedujący do następnego kroku?
Stawiamy więc hipotezę, że prawdopodobnie winny jest tzw. checkout, wraz z tym konkretnym krokiem. Stwierdzamy więc, że to tutaj leży problem i planujemy zmianę całego koszyka i wszystkich kroków. Przygotowujemy prototyp, który zmienia ścieżkę konwersji w koszyku i testujemy na realnych użytkownikach. Mamy kilka wersji, które pozwolą nam wybrać najlepszą i stwierdzić, gdzie leżał problem. W zasadzie, znalezienie problemu to klucz do poprawy wszelakich wskaźników.
Pamiętaj, że Twój prototyp nie jest realnym produktem, a ma tylko udawać realny produkt, dlatego czasami nie warto tracić czasu na szlifowanie każdego detalu, czy logiki - za prototypem nie muszą się kryć przecież żadne algorytmy, dane, czy prace programistyczne.
Eksploruj Miesięczny Design Sprint
Zobacz przygotowane przez nas skróty do ważnych zasobów w naszej bazie wiedzy.
🔬Tydzień 1 - Odkrywanie i przygotowanie🚀Tydzień 2 - Design Sprint🖥️ Tydzień 3 - Prototypowanie🎁Tydzień 4 - Delivery SprintZasobyLast updated
Was this helpful?