Desing Sprinty, czyli metoda do szybkiego projektowania i testowania nowych pomysłów spopularyzowana przez Google. Większość kojarzy czym są Design Sprinty, sporo „ekspertów” o nich odpowiada, ale... niewielu realnie stosuje i ma praktyczne doświadczenia.

Najpierw podzieliłem się własnym wstępem teoretycznym i moimi doświadczeniami z Design Sprintów. Potem miałem okazję porozmawiać o nich w podcaście Product Vision z ekspertem i praktykiem - Marcinem Chyłą (ma na swoim koncie ma już kilkanaście Design Sprintów).

Podczas podcastu oraz naszych rozmów z Marcinem pojawiło się tak dużo praktycznych pytań i wątków, że żebraliśmy je w formę 💬 dodatkowe FAQ o design sprintach:

1. Kiedy pierwszy raz wykorzystałeś Design Sprint w praktyce?

2. W jakich sytuacjach warto wykorzystać Design Sprint? Kiedy sam go wykorzystywałeś najczęściej?

3. Jak przekonywać firmę, interesariuszy do wykorzystania Design Sprintów?

4. Jaki najczęstszy błąd widzisz przy realizacji Design Sprintów?

5. Design Sprint, a Product Discovery - czy warto je łączyć?

6. 🔐 Czy powinniśmy zakładać znalezienie rozwiązania problemu w jednym Design Sprincie, czy od razu powinniśmy planować wiele iteracji?

7. 🔐 Jak przygotować zespół do Design Sprintu? Czy zespół powinien poznać rozwiązywany problem wcześniej?

8. 🔐 AI przy Design Sprintach - jak wykorzystać?

9. 🔐 Gdzie szukać więcej info o Design Sprint? Co polecasz?

ℹ️ Więcej wartościowych treści od Marcina znajdziesz na jego profilu LinkedIn oraz blogu DesignSprinter.pl

3-4 lata temu wpadła mi w ręce książka J.Knapp’a pt.: „Pięciodniowy sprint. Rozwiązywanie trudnych problemów i testowanie pomysłów”. Przeczytałem i bardzo chciałem wypróbować tę metodę.

Byłem wtedy Product Managerem. Pracowałem ze świetnym zespołem developerskim. Zaprosiłem ich do tego eksperymentu.

Dostarczaliśmy wtedy API dla pewnej usługi, ale parę razu pojawiła się sugestia stworzenia interfejsu użytkownika. Tematy UI-owe są dość wdzięcznymi tematami dla sprintów. Ale nie jedynymi.

Sprint zakończył się prototypem i testami. Aplikacja działa do dziś! Pierwszy Sprint nie był jednak idealny. Co zrobiłbym inaczej? Teraz zadbałbym o większe zróżnicowanie w zespole Sprintowym.

Kiedyś policzyłem koszt jednego ze Sprintów. Było to około 150 h. Kiedy przemnożymy to przez stawkę godzinową specjalisty IT okaże się, że Sprint nie jest tanim procesem.

Dążę do tego, że Sprint warto uruchamiać dla perspektywicznych inicjatyw, które mają potencjalnie duży IMPACT. Nowa opcja czy nowy ficzer w istniejącym już produkcie może nie być warta zainwestowanego takiego czasu.

Sprinty świetnie sprawdzają się w warunkach dużej niepewności. Dzięki zaangażowaniu wielu różnych ról pozwala holistycznie podejść do problemu czy pomysłu biznesowego. Właśnie ta mnogość ról umożliwia nam dostrzeżenie i mitygację różnych ryzyk, tych technicznych, kosztowych, użytecznościowych.

Sprinty polecam także wszystkim startupowcom - dla nich poniekąd ta metoda została przygotowana w Goole Ventures. 

Często używam argumentu, że lepiej po 4-5 dniach „zaorać” jakiś pomysł przy zaangażowaniu 6-7 osób, niż dowiedzieć się braku zasadności realizacji tego produktu po 4 czy 5 miesiącach developmentu w 2 zespołach developerskich.

Warto czasem także odwołać się do kultury naszej organizacji. Jeśli organizacja, na sztandarach niesie wartości „Eksperymentowanie”, „Szybkie uczenie się i wyciąganie wniosków” czy „Innowacyjność” to można tych fraz użyć podczas negocjacji: „Skoro to są nasze wartości, to sprinty idealnie się w nie wpisują.”

Na koniec klasyczne argumenty praktyczne - dzięki Sprintowi:

• w 4-5 dni, połączymy siły różnych ról i specjalistów, aby przygotować innowacyjne rozwiązanie problemu (ko-kreacja, współtworzenie),

• dzięki makiecie i badaniu szybko wyciągniemy wnioski;

• i oczywiście skrócimy pętlę zwrotną od użytkowników i interesariuszy - szybciej będziemy wiedzieli czy nasz pomysł ma sens.

Wskazałbym tutaj to, że największym błędem jest nietraktowanie Sprintu z należytą powagą. Sprint odniesie sukces tylko, gdy zespół będzie w 100% zaangażowany w ten proces. Oznacza to pełną dostępność w te 4 czy 5 dni. Dotyczy to także osób zaproszonych w charakterze ekspertów.

Przypomnijmy sobie co na temat discovery mówi Marty Cagan:

Wg mnie, Sprint jest idealnym narzędziem, które może w procesie product discovery wykorzystać:

• Realni klienci i ich feedback o potencjalnym produkcie lub usłudze na podstawie makiety? Checked ☑️.

• Zaadresowanie ryzyk pilności, wykonalności, użyteczności poprzez multidyscyplinarny zespół, poprzez rozmowy z ekspertami? Checked ☑️.

Więcej o swoich doświadczeniach z łączeniem Design Sprintów z Discovery i pracą Scrumową pisał Tomek:

Moje doświadczenia są takie, że zwykle planowaliśmy pojedynczą sesję Design Sprintu (jeden sprint), zgadzając się na to, że po wywiadach i analizie wyników zdecydujemy co dalej.

Musimy założyć, że wydarzy się ten mało pozytywny scenariusz. Wyniki badań mogą nam uświadomić, że źle zidentyfikowaliśmy problem do rozwiązania, lub nasz sposób rozwiązania problemu nie jest doskonały. Możemy też dostać pozytywny feedback co do idei, ale niepochlebny dotyczący prototypu.

Wyniki badań mogą nas więc zachęcić do jednego lub więcej kroków do tyłu i zaplanowanie kolejnego sprintu.

Zdecydowanie polecam wykonać przygotowania wcześniej, tak aby na właściwy Sprint przyjść już przygotowanym. Ma to szczególne znaczenie przy Sprintach prowadzonych online.

Metoda, jaką stosuje to Problem Framing. Problem Framing to krótszy warsztat dla zespołu Sprintowego, którego głównym celem jest pierwsze zawężenie wyzwania projektowego oraz wyrównanie i rozpropagowanie wiedzy w zespole.

• Na Problem Framingu rozmawiamy o Userze, kliencie czy głównym aktorze lub aktorach.

  • To dobry moment, aby wyciągnąć na światło dzienne PERSONĘ lub przypomnieć sobie wywiady, feedbacki, cytaty z for lub socjal mediów.

  • Ogólnie przygotowujemy wszystko, co pomoże nam jeszcze raz wskazać głównego użytkownika i jego cechy, cele, potrzeby. Najważniejsze warto sobie gdzieś zapisać lub zwizualizować.

• W kontekście persony rozmawiamy o problemach tej persony i okolicznościach, jakie je wyzwalają.

  • Tu warto omówić wyniki wcześniejszych badań, badania konkurencji, wcześniejsze próby rozwiązania tego lub podobnego wyzwania. Wszystko, co pozwoli nam zrozumieć CO i KIEDY „boli” naszego użytkownika.

  • Znów, te najbardziej znaczące i pasujące do naszego wyzwania projektowego wizualizujemy.

• Na koniec warto także porozmawiać o „DLACZEGO”.

  • Dlaczego warto rozwiązać te problemy z punktu widzenia klienta. Co się dla niego, niej, zmieni; co osiągnie i jak, my, jako firma, te osiągnięcia wykorzystamy lub zmonetyzujemy.

Rozumiejąc KTO, CO, KIEDY i DLACZEGO możemy przygotować „problem statementy”:

Problem Statement to precyzyjnie sformułowane stwierdzenie, które określa główny problem, nad którym zespół będzie pracować podczas sprintu. Struktura „problem statement” zazwyczaj obejmuje trzy główne składniki:

• opis sytuacji (obecny stan)

• wyzwanie (problemy, potrzeby, wyzwania naszych użytkowników)

• oraz potencjalne korzyści z rozwiązania problemu.

Reasumując, dobry Problem Framing oszczędzi nam czas pierwszego dnia Sprintu, zbuduje pierwsze zrozumienie problemu i wcześniej scali nasz zespół.

Największą trudnością może być zbyt szerokie definiowanie problemu. 

Podczas framingu odpowiadamy sobie na pytanie: kto cierpi, na co cierpi, kiedy/co ten ból wyzwala oraz po co chcemy ten problem wyleczyć. Dany problem może wystąpić w wielu kontekstach. Wielu użytkowników może doświadczać tego samego problemu. Może pojawić się nam naprawdę wiele „Problem Statementów”.

Mając na uwadze tylko 4-5 dniowy Sprint, warto pamiętać, że nie wszystkie problemy będziemy w stanie naprawić, a już na pewno nie na wszystkich skupimy się na sesji Sprintowej. Wczesne zawężenie wyzwania pomoże nam łatwiej wyznaczyć cel sprintu.

Lepiej rozwiązać jeden konkretny wąski problem, niże nie rozwiązać żadnego w o ogóle.

Mogę polecić dwa narzędzia.

Pierwsze to Perplexity do wstępnego researchu. Wpisuję cel sprintu i proszę o przykłady z innych branż niż moja. Dostaję linki, filmy, infografiki. Bardzo to pomaga w pierwszych dniach Sprintu.

Drugie narzędzie to tool Uizard.io do makietowania, ale z opcją wpisania prompta. Znów wprowadzam cel sprintu i w odpowiedzi otrzymuję propozycję interfejsu. To narzędzie używam jako inspiracji przy szkicowaniu rozwiązań; nigdy bym jednak nie zrezygnować z designera w zespole Sprintowym.

• Książka „The Sprint Book”, Jake Knapp - Najbardziej znana książka o wykorzystaniu metody Design Sprint.

• YT AJ&Smart - intro do Design Sprintów 2.0., dzień po dniu, od AJ&Smart

• Spotify Jake & Jonathan - podcast o projektowaniu produktów, prowadzony m.in. przez Jake’a Knappa. Tu polecam duży dystans 😛

• Design Sprint KIT od Google - Świetne kompendium wiedzy o design sprintach - razem z przykładami, case study, materiałami do wykorzystania

• Będzie mi tez miło jeśli odwiedzicie mój kanał na YouTube oraz mój blog Design Sprinter – w prostych słowach o Design Sprintach.