Podobno przetrwają najzwinniejsi. Co zatem możemy zrobić, żeby nadążyć za tempem, w którym zmieniają się dzisiaj potrzeby i oczekiwania użytkowników?
Design sprint, czyli czego nauczył nas Jake Knapp
Ci z nas, którzy mieli okazję spróbować kilkudniowego procesu projektowego wymyślonego w Google, wiedzą, jak wiele dobrej, kreatywnej energii uwalnia się w krótkim czasie.
Metodyka zakłada włączenie w projekt przedstawicieli wielu departamentów, którzy choć na co dzień nie współpracują ze sobą, to zebrani razem mają komplet wiedzy pozwalający tworzyć rozwiązania o wysokim prawdopodobieństwie sukcesu na rynku.
Warsztaty pozwalają doprecyzować często bardzo ogólną koncepcję, z którą podchodzimy do sprintu. Dzięki temu rodzi się nie tylko lepsze, wspólne zrozumienie idei, ale można też określić cele długoterminowe i zagrożenia dla projektu, a sam proces zaczyna przybierać konkretny kształt. Małym nakładem sił i środków potwierdzamy słuszność hipotezy rynkowej bądź podważamy ją i dowiadujemy się o konieczności modyfikacji. Clou sprintu to właśnie szybka walidacja hipotezy, z którą otwieramy warsztat — bez konieczności oczekiwania na wydanie działającej aplikacji.
„Uwielbiam design sprinty — prowadzenie początkowych badań, budowanie wspólnego zrozumienia użytkowników, korzystanie z kreatywności i testowanie z użyciem prototypów. To zresztą najciekawsza część opisu ofert pracy w naszym RBL_Lab w Alior. Design sprint pozwala oszczędzać pieniądze — odrzucamy pomysły, które mają poważne wady, lub wprowadzamy do nich szybkie zmiany w ograniczonym zakresie. Ev Rogers (ten sam, który ukuł termin „Early Adopters”) wymienił 5 warunków, jakie decydują o tym, czy nowe rozwiązanie zostanie przyjęte. Design sprint pozwala zoptymalizować koncept na początkowym etapie, ale nie udziela odpowiedzi na pytanie, czy rozwiązanie przyjmie się w dłuższym okresie. Dobrym przykładem tego, jak łatwo nabrać się na efekt pierwszego wrażenia, są w bankowości narzędzia Personal Management — klienci uwielbiają je wypróbowywać, ale wypróbowywanie to co innego niż codzienne, nawykowe korzystanie. To istotny powód, dla którego warto testować gotowe rozwiązania, np. wydając działającą aplikację w formie MVP. Jednym z pomysłów, jak to efektywnie robić, jest współpraca ze startupami doświadczonymi w korzystaniu z design sprintów. Sporym wyzwaniem jest tutaj posiadanie przyzwolenia od organizacji na to, żeby anulować projekt, jeżeli rozwiązanie nie zostanie trwale przyjęte przez użytkowników” — mówi Paweł Stężycki, Leading Innovation & UX w Alior Bank.
Przyspieszanie developmentu… bez developmentu, czyli wartość prototypów hi-fidelity
Naturalnym wyborem po przejściu design sprintu jest zbudowanie dokładniejszego modelu aplikacji, który pozwala zobrazować oczekiwania co do sposobu jej działania zespołowi deweloperskiemu.
Dzięki temu inżynierowie oprócz opisów słownych w postaci historyjek użytkowników (uzyskanych z użyciem spopularyzowanej przez Jeffa Pattona techniki User Story Mappingu) dysponują klikalną wersją interfejsu użytkownika.
Składa się na nią zestaw szczegółowych, klikalnych makiet pozwalających przejść ścieżkę użytkownika uzupełniony o propozycje layoutów graficznych. Dopełnieniem jest wizualny style guide pozwalający przyjąć spójną konwencję formatowania kontrolek aplikacji, takich jak ikony, przyciski, linki tekstowe, formatowanie contentu.
Zbudowanie prototypu przynosi korzyści takie jak wizualizacja pomysłu, optymalizacja czasu i kosztów budowy aplikacji. Podnosi także motywację zespołu deweloperskiego, który lepiej rozumie, jak powinna zachowywać się aplikacja, żeby spełnić oczekiwania biznesu.
„Dzięki opracowanemu prototypowi od samego początku wiedzieliśmy, w jaki sposób kolejne funkcjonalności wkomponują się w całość produktu. Zminimalizowaliśmy przez to ryzyko strat wynikających z konieczności wielokrotnego przerabiania tych samych elementów. Nowe pomysły w projekcie udaje się nam teraz łatwo włączyć w przemyślaną wcześniej architekturę informacji” — mówi Paweł Marek, Product Owner w Transcash.eu.
Oprócz tego prototypy pozwalają na szybkie zderzenie pomysłów kreatywnych z możliwością ich technologicznej realizacji i skonfrontowanie wykonalności w określonym czasie i budżecie.
To wszystko bez napisania jednej linijki kodu.
Pułapki podążania „happy path”, czyli kiedy myśleć o przypadkach brzegowych
Prototypy pozwalają na szybkie zrozumienie, jak będzie działać oprogramowanie. Ma to szczególne znaczenie nie tylko wtedy, gdy planujemy wydanie całkowicie nowej aplikacji.
„Kiedy prezentujemy gotowe prototypy UXowe dla nowych funkcjonalności, biznes szybko potrafi ocenić, czy to jest to, czego potrzebują. Patrzymy przy tym na prototypy przez pryzmat przypadków użycia wspierających konkretny business case. Prototypy pozwalają zrozumieć zespołowi deweloperskiemu poziom złożoności tego, co ma być wykonane. Dzięki temu możliwa jest dokładniejsza estymata wykonania funkcjonalności, którą zwizualizowano na prototypie. W ten sposób możemy całościowo łatwiej oszacować wartość wprowadzenia nowej funkcjonalności do aplikacji” — mówi Gaweł Boguta, CTO iTaxi.pl.
Zgodnie z zasadą Pareto zwizualizowanie części scenariuszy — priorytetowych 20% — decyduje o 80% poprawnego zrozumienia działania produktu przez użytkownika prototypu.
Dlatego rzadko kiedy prototyp pokrywa wszystkie ścieżki i scenariusze użycia — byłoby to bardzo czasochłonne, a w prototypowaniu chodzi o to, aby przynieść minimalnym wysiłkiem wysoką wartość dla danego projektu.
Prototyp nie stanowi zatem kompletnej dokumentacji obsługującej tzw. przypadki brzegowe — czyli sytuacje, które zdarzają się stosunkowo rzadko, ale na które musi być odporne dobre oprogramowanie. Uwzględnianie przypadków brzegowych najłatwiej uzupełniać podczas wytwarzania oprogramowania. Staje się to prostsze, gdy w zespole jest projektant UX, z którym deweloperzy mogą na bieżąco wypracowywać sposoby obsługi przypadków brzegowych w miarę ich ujawniania. Dzięki temu utrzymujemy spójność modelu interakcji.
Na koniec 5 zasad, które ułatwiają prototypowanie
1. Zaproś do warsztatów z papierowego prototypowania różnych interesariuszy. Chociaż reprezentanci biznesu oraz deweloperzy zwykle nie są profesjonalnymi projektantami interakcji, mogą wnieść do projektu bardzo ciekawe pomysły, które warto będzie przetworzyć na dalszym etapie.
2. Zanim zabierzesz się za prototypowanie ekranów, zaczynaj od person i diagramów przepływu. Upewnij się, że wiesz, kto będzie użytkownikiem aplikacji i jakie są jej/jego cele. Koniecznie zwizualizuj w formie najprostszych nawet diagramów przepływu, jak krok po kroku będzie wyglądała ścieżka użytkownika.
3. Zacznij od szybkiego prototypowania — mogą to być nawet szkice na serwetce. Im mniej dokładne narzędzie, tym lepiej. Marker i biała tablica lub ołówek i kartka papieru to doskonałe narzędzia. Na tym etapie chodzi bowiem o szybkie szkicowanie, wyrzucenie pomysłów z głowy
4. Poproś każdego uczestnika warsztatów, podczas których prototypujecie, o naszkicowanie kilku wersji prototypu. Dzięki temu korzystając z odwrotności efektu IKEA, omawiając rezultaty prac, będziecie mniej wrażliwi na krytykę poszczególnych propozycji. W efekcie końcowym zamiast bronić swoich wersji, przejmiecie z wielu z nich dobre rozwiązania, aby stworzyć wsad do finalnego konceptu.
5. Przejdź do środowiska do prototypowania elektronicznego — takiego jak UXPin — dopiero wtedy, gdy przetestujesz zrozumiałość papierowych prototypów. Możesz do tego użyć testów korytarzowych, które pozwalają szybko sprawdzić, czy użytkownicy rozumieją model interakcji.
