Design thinking, co to jest?

Czy programista powinien zajmować sobie głowę design’em? A co to jest ten design? Design patterns – wiadomo znamy, szanujemy. 🙂 A design thinking to co to takiego? 
 
Sam osobiście na temat natknąłem się dosyć przypadkowo. Na tyle mnie on zaciekawił, że postanowiłem pogłębić wiedzę z tego zakresu. Między innymi udało mi się wziąć udział w warsztatach prowadzonych przez Google i PFR. Chciałbym się podzielić z Wami moimi przemyśleniami. Przy okazji jest to mój coming out, czyli początek przygody z blogowaniem.

Definicja

Przeszukując Internet można natrafić na kilka definicji. Design thinking to metoda twórczego rozwiązywania problemów. Design thinking to usystematyzowany iteracyjny proces.
 
Wg Hasso-Plattnera z Institute of Design at Stanford proces ten można podzielić na pięć etapów:
  • empatia
  • zdefiniowanie problemu,
  • pomysły,
  • prototypy,
  • testy.
Na warsztatach prowadzonych przez Google został zaproponowany trochę inny podział. Mianowicie:
  • focus on the user,
  • think 10x
  • be prototype driven.
Z mojej perspektywy design thinking to połączenie w pewien ciąg rzeczy oczywistych, które są przez nas podświadomie marginalizowane w pędzie wytwarzania końcowego rozwiązania. 

A wszystko zaczyna się od pomysłu

Żyjemy w czasach Startup’ów. Jesteśmy bombardowani tysiącami pomysłów i ich realizacji. To sprawia, że w naszych głowach tych pomysłów również nie brakuje. Sam osobiście mam spisaną listę kilkunastu rzeczy, które wpadły mi do głowy i czekają na realizację. To jest super. Co jest jeszcze super? To, że będąc programistami mamy jeszcze prościej, ponieważ od pomysłu do napisania pierwszych linijek kodu jest niedaleka droga. Szybki przegląd koncepcji i można zaczynać programować. Mam super pomysł, zarwę kilka nocek i… i tutaj jest chyba miejsce na cytat. 
 
You got an idea? And you know who thinks that’s a great idea? You.. You are the problem, you are a risk to be managed. 
Ed Hesse
No właśnie, według nas nasz pomysł zawsze wydaje się świetny. Jesteśmy emocjonalnie przywiązani do swojego dziecka.  Wróćmy teraz do design thinking. W design thinking te pierwsze linijki kodu, które już napisaliśmy to właściwie druga połowa całego procesu. Przeskoczyliśmy jego najważniejsze etapy. Bo w design thinking wszystko zaczyna się od problemu. Od problemu, który nasz pomysł rozwiązuje. Idąc dalej, za tym problemem stoją ludzie, jego adresaci. Nasz pomysł jest odpowiedzią na czyjąś potrzebę. W tym problemie, w tej potrzebie musimy się zakochać

“Zakochaj się w problemie, nie w rozwiązaniu” – focus on the user

 
Inwestycja powinna być poprzedzona badaniami, analizą rynku. Nawet jeśli w realizację pomysłu inwestujemy “tylko” czas. Czy to nie jest oczywiste? Jest. A teraz zastanów się, jak często zdarzało się, że wpadłeś/wpadłaś na jakiś pomysł rozwiązania i wszystkie znaki na niebie mówiły, że to jest to jedyne rozwiązanie. Ale czy na pewno wszystkie znaki? Czy podświadomie wybrałeś/wybrałaś tylko te, które potwierdzały Twoją tezę. To tak zwany “efekt potwierdzenia (confirmation bias)“. Bardzo często opieramy się na intuicji, a nie na faktach i rzetelnych analizach. 
 
Inny przykład. Często przystępujemy do tworzenia oprogramowania na podstawie specyfikacji. Ta specyfikacja jest niczym innym jak właśnie propozycją rozwiązania, której autorem jest jeden lub kilku architektów. A co jeżeli ona została stworzona wyłącznie na podstawie ich domysłów i jest obarczona tym samym “efektem potwierdzenia”. W tym przypadku sytuacja jest jeszcze gorsza, ponieważ programiści budują sobie obraz systemu patrząc na specyfikację. Nie mają często szansy dotrzeć do źródła, które za nią stoi. 
 
Tu z pomocą przychodzi design thinking, które mówi “focus on the user“. Zatrzymaj się, spróbuj zidentyfikować dla kogo tworzysz to rozwiązanie. Stwórz personę, która będzie identyfikować odbiorcę. Nazwij ją, opisz jakie ma problemy, jakie ma potrzeby, w jakim funkcjonuje środowisku. 

Przykład

Ciekawy przykład skupienia się na człowieku prezentował Paweł Tkaczyk w podcast’e Mała Wielka Firma. Firma Kruk (windykacja) postanowiła zbadać kim są ludzie, którzy zalegają z płatnościami. Czego Ci ludzie oczekują od firmy, która zajmuje się windykacją długów? Patrząc stereotypowo można wyciągnąć wnioski, że ci dłużnicy, patologia, złodzieje i pijacy, od tej firmy chcą najpewniej uciec jak najdalej. A jednak po przeanalizowaniu ankiet i wywiadów wyłania się obraz ludzi w znacznej mierze uczciwych, wstydzących się swojej sytuacji i chcących wyrwać się ze spirali długów. Firma Kruk wydrukowała na ścianach zdjęcia i cytaty z wywiadów z tymi ludźmi, tak aby pracownicy nie opierali się na stereotypach, ale faktycznie poznali swoich klientów.

Jak poznać naszego odbiorcę?

Przede wszystkim trzeba chcieć :). Metod “researchu” jest wiele:
  • od pierwszych analiz przy biurku przed komputerem,
  • przeszukania for internetowych, grup w social-mediach, komentarzy pod blogami
  • poprzez wcielenie się w rolę klienta,
  • przeprowadzanie wywiadów, ankiet,
  • obserwację ludzi (tu najlepiej z ukrycia, ponieważ ludzie obserwowani mają tendencję do zmiany swoich zachowań).
 
Im bliżej jesteśmy człowieka tym lepiej. Wg współtwórcy Google, Larry’ego Page:
 
There is no substitute for personally watching and listening to real people.
W całym procesie ważne jest, aby opierać się na faktach, na prawdzie, a nie na naszych wyobrażeniach, czy intuicji. Prawda oszczędza pieniądze i czas.
 
Im więcej zbierzemy informacji, tym lepiej. Większa ilość zebranych danych przyspiesza kolejny proces: tworzenia pomysłów. Zespół analizując wyniki badań nie zastanawia się czy tak faktycznie jest, jeżeli dane mówią same za siebie. Ale pamiętajmy też, że tutaj nie chodzi o wygenerowanie statystyk, zestawień procentowych czy wykresów. Nie będziemy z nich robić sprawozdania dla zarządu. Zebrane dane mają uruchomić proces twórczego poszukiwania rozwiązania. W przypadku wątpliwości zawsze możemy wrócić do etapu “researchu” z nowymi konkretnymi pytaniami.
 
W całym procesie należy patrzeć szerzej, nie tylko pod kątem pierwotnego pomysłu. Być może ten szerszy kontekst już na tym etapie spowoduje rewizję pomysłu. Może pozwoli pchnąć go na inne tory. 
 
Etap “researchu” powinien zakończyć się konkretnym artefaktem. Wyniki naszych badań, teksty, zdjęcia powinny zostać przez nas przeanalizowane, pogrupowane i przedstawione w wygodnej i szybkiej do przyswojenia formie: map myśli, research wall’i
 
Po zapoznaniu się z naszym użytkownikiem i jego prawdziwymi problemami, możemy przystąpić do kolejnego etapu – generowania pomysłów.

I jeszcze raz pomysły

Pomysły najlepiej generować w grupie (choć można też samemu). Jeżeli podejdziemy do tematu grupowo, na jego początku zadbajmy o wprowadzenie wszystkich uczestników w temat. Uczestnicy powinni też być zmotywowani, czuć, że zostali wybrani do tego grona ponieważ ich pomysły są ważne!
 
Możemy wybrać różne metody generowania pomysłów ale jest kilka zasad, które bardzo nam pomogą w całym procesie.

Yes, and… Yes, but..

Próbujmy budować na pomysłach innych, nie krytykujmy ich. Nawet drobna krytyka spowoduje niepotrzbne napięcie i stratę czasu na dyskusję.  Na pierwszym etapie chodzi o wygenerowanie dużej ilości pomysłów. Nie na ich ocenie. Jeżeli pomysł kogoś innego nie przypadł nam do gustu… odpuśćmy. 
 
Jeżeli potrafimy jakiś pomysł rozwinąć, super, o to chodzi. Jeżeli ktoś rozwija nasz pomysł nie w tym kierunku, który pierwotnie sobie wyznaczyliśmy, nie krytykujmy go. Właścicielem, każdego pomysłu jest grupa, nie konkretna osoba. 

Quantity

Drogą do tego by mieć super pomysł jest posiadanie wielu pomysłów. Im więcej wygenerujemy pomysłów, tym większe prawdopodobieństwo, że znajdziemy w nim naszą perełkę lub po prostu kilka pomysłów wartych przetestowania. Kolejna oczywistość ;). Żeby generować dużo pomysłów nie traćmy czasu na ich dokładne opisywanie, wystarczą hasła lub jeszcze lepiej rysunki. Rysunek zastępuje 1000 słów. Niezrozumiałe rzeczy wyjaśnimy grupie w stosownym czasie.

10x 

Większość osób kieruje się w życiu rozsądkiem. Podejmując decyzję analizujemy nasze otoczenie: dostępne technologie, wyniki innych. Myślimy o zmianie jako o ewolucji, jako o ulepszeniu, udoskonaleniu obecnego stanu rzeczy, o czymś, co następuje niejako liniowo, krok po kroku. Przykładowo… zastanów się, jak rozwiązać problem korków w miastach? Wielu polityków na pewno ma w swoich programach taki punkt. Proponuję sobie wpisać to pytanie w Google’a i zobaczyć odpowiedzi. Postawmy na komunikację zbiorową, wdrożmy inteligentną sygnalizacje świetlną. Wiele mądrych, rozsądnych pomysłów. Ich wcielenie w życie prawdopodobnie zniweluje problem w jakimś stopniu, upłynni ruch o 1%, 2%, może o 10%, ale na pewno nie zlikwiduje korków w mieście.
 
Na to samo pytanie odpowiedział np. Elon Musk. 
 

 
Widzisz różnicę? 🙂 A może nie tunele, ale latające samochody? A może ruchomy chodnik jak u Jetsonów? A może trochę zwolnijmy i zrezygnujmy z prywatnych samochodów w mieście?
 
Na tym etapie przygody z design thinking odrzućmy na chwilę nasz rozsądek, odblokujmy odwagę i kreatywność. Próbujmy wymyślić coś, co nie jest 10% lepsze ale coś, co jest 10 razy lepsze, unikalne, prostsze. Nawet jeżeli twój pomysł wydaje Ci się totalnie irracjonalny i przez to głupi i nie wart tracenia czasu. Pozwól niech grupa o tym zadecyduje. Być może inne spojrzenie na ten pomysł spowoduje, że okaże się on wcale nie taki nierealny,  a może będzie on dla innych źródłem innych dobrych pomysłów. Jeszcze jedna kwestia związana z 10x. Chcąc zbudować coś 10 razy lepszego być może wymyślimy coś fantastycznego, ale i piekielnie trudnego. Nie bójmy się trudnych zadań.
 
John F. Kennedy powiedział:
 
We chose to go to the moon, not because it was easy … but because it was hard.

Burza mózgów

Wracając do samego procesu generowania idei, na warsztatach wykorzystaliśmy technikę burzy mózgów, a konkretnie “brainwritingu“. Cały proces wyglądał mniej więcej tak:
  • Po wprowadzeniu do problemu, każdy z grupy miał za zadanie wymyślić jak największą ilość pomysłów, kierując się wcześniej wspomnianymi zasadami. Mieliśmy na to ograniczony czas – 5 minut.
  • Pomysły spisywaliśmy na karteczkach (post-tip). Po upływie czasu każdy z nas kolejno przyklejał swoje karteczki na tablicy i krótko opisywał pomysł, jeżeli ten dla grupy był nie do końca zrozumiały. To był czas na dyskusje, ale ten czas był też ograniczony.
  • Następnie przychodziła kolejna runda generacji pomysłów, gdzie próbowaliśmy inspirować się obecną zawartością tablicy i rozwijać istniejące pomysły. Oczywiście bez krytyki. Wszystko znów w ograniczonych ramach czasowych.
  • Mając już dostateczną ilość wartościowych pomysłów następowała faza oceny… a właściwie wybrania pomysłów wartych sprawdzenia na etapie prototypowania.
 
Zalety wykorzystania techniki brainwritingu to: 
  • proces generacji pomysłów jest szybki, ponieważ każdy z członków grupy generuje je niezależnie. Jednocześnie na pierwszym etapie ograniczana jest faza dyskusji.
  • w grupie mogą znaleźć się zarówno osoby dominujące oraz osoby nieśmiałe, w tej metodzie każdy ma równe szanse na przedstawienie swoich pomysłów
  • pomysły trafiają na tablice, są następnie rozwijane w kolejnych iteracjach, dzięki czemu nie możemy ich przypisać do jednej osoby i stają się pomysłami grupy. Odcinane są od konkretnych członków grupy i niwelujemy ryzyko, że summa summarum przechodzi pomysł szefa, bo pozostali bali się go nie poprzeć 🙂
 
Burza mózgów może też przebiegać w zgoła inny sposób. Odwrotnie do brainwritingu można ją przeprowadzić opierając się na żywiołowych dyskusjach lub nawet na zasadzie teatru, przedstawiania scenek.

Zespół – zbiór mózgów

Bardzo pomocne jest dobranie odpowiedniego zespołu ludzi. Powinni to być ludzie z różnym punktem widzenia, zarówno programiści jak i ludzie mający kontakt z klientem, a może wręcz przedstawiciele klienta. Może warto zaprosić też osoby z zupełnie innej działki i zobaczyć ich punkt widzenia. 
Nie przesadzajmy z wielkością zespołu. Jeff Bezos (CEO Amazonu) stosował zasadę 2 pizz. W spotkaniu powinna brać udział taka liczba ludzi, którym wystarczą dwie pizze, by się najeść. 
 
Pamiętajmy też, że każde spotkanie, może przerodzić się w długi niekończący się tasiemiec. Szanujmy czas.  Warto przed spotkaniami ustalić granicę, czy to czasową czy to np. uzgodnić, że kończymy etap generowania pomysłów, gdy na tablicy znajduje się ich konkretna liczba. Design thinking to proces iteracyjny, do każdego z jego etapów możemy, a nawet powinniśmy wrócić nie raz.
 
Po tym etapie powinniśmy mieć co najmniej kilka pomysłów, które chcemy przetestować i które na użytek testów powinny zamykać się w konkretnych pytaniach. Może też zdarzyć się tak, że nie możemy wygenerować żadnego pomysłu, ponieważ mamy istotne braki w danych. Wtedy możemy wrócić do etapu poszukiwań lub też zadać konkretne pytanie, które można przetestować tworząc prototyp.

Prototypy i testy

A czym jest prototyp? Prototypy to kolejna oczywistość w design thinking. Przecież oczywiste jest, że przed rzuceniem całych dostępnych sił w implementację pomysłu, warto ten pomysł poddać testom, przedstawić go ludziom, zebrać opinie. Sprawdzić czy “zażre”. Niby tak.. ale może jeszcze na to za wcześnie.. Jeszcze trochę “pokodzę”, dopiszę kilka funkcjonalności i zaraz potem pokażę. Nie no, patrz jakie to brzydkie i czasem się zawiesza, nie chcę żeby ludzie się od razu zrazili. Dobre wrażenie robi się tylko raz. Takie dysputy można toczyć bardzo długo i co gorsza przeważnie toczą się one tylko wewnętrznie w naszych zespołach lub tylko w naszej głowie. 
 
źródło: rework.withgoogle.com
 
Design thinking kładzie nacisk na szybkie testowanie naszych idei. Prototyp to nawet nie MVP. Prototyp ma dać odpowiedź na pytania, które powstały po etapie burzy mózgów. Im mniej czasu i nakładów poświęcimy na zbudowanie prototypu i jego przetestowanie tym lepiej. Oczywiście, do wszystkiego trzeba podchodzić zdroworozsądkowo. Pamiętajmy cały czas o użytkowniku.
 
Co może być prototypem? Patrząc od strony aplikacji to np.:
  • szkic, rysunek
  • bardziej szczegółowy, mockup
  • reklama Google Adwords, Facebook
  • landing page
  • aplikacja
 
W książce “The 4-Hour Workweek” Tim Ferris opisuje jak do przetestowania produktu może posłużyć “fake’owy” sklep internetowy. W omawianym przykładzie w ostatnim kroku zamawiania produktu, po zebraniu danych kontaktowych klienta, pojawiał się komunikat przepraszający użytkownika, że w danej chwili wysyłka produktu nie może być zrealizowana. 
 
Warto jednak zaczynać od mniej pracochłonnych prototypów. Dobrym pomysłem jest też testowanie ich najpierw na mniejszej grupie, sprawdzenie czy prototyp faktycznie daje odpowiedź na pytanie, które za nim stoi.
 
A skąd mamy wiedzieć czy prototyp daje nam tę odpowiedź? Musimy mierzyć 🙂 Zbierać odpowiedzi, zliczać ilość kliknięć (w reklamę lub w linki na naszym landing page’u), podglądać użytkownika, mierzyć czas, mierzyć wielkość naszej “widowni”. Musimy zbierać dane, które później pozwolą nam wrócić znów do etapu researchu, czyli do etapu, w którym analizujemy fakty, a nie podpowiedzi naszej intuicji.
 
Na koniec akapitu, pozwolę sobie wrócić jeszcze do idei budowy prototypu w postaci “landing page’a“. Jest ona o tyle ciekawa, że przy okazji mierzenia ilości kliknięć, budowania heat-map, odzwierciedlających co użytkownika zainteresowało na naszej stronie, daje nam coś jeszcze. Pozwala zbudować tzw. “Minimum Viable Audience“, czyli jak to opisuje Paweł Tkaczyk na swoim blogu  “Minimalną Działającą Widownię – twój własny tłum, który będzie paliwem dla Twojej marketingowej machiny”. Ta widownia to ludzie, którzy zostawią na siebie namiar i być może staną się naszymi pierwszymi testerami, a później klientami. To ludzie, których opisaliśmy budując “personę”, na etapie badań.

Podsumowanie

Co to jest design thinking? Czy programista powinien zajmować sobie głowę design thinking? Wg mnie TAK. Ta metoda pokazuje nam programistom, że oprócz specyfikacji i wymagań projektów, w tym co robimy jest jeszcze jakiś kontekst. Zwraca nam uwagę, że warto pochylić się nad problemem, zobaczyć jak coś działa, popytać użytkowników, spróbować wytworzyć jakąś wartość wspólnie z nimi. Nie jest to złoty środek, a raczej tak jak wspomniałem zebranie kilku oczywistych procesów i połączenie ich ze sobą w jedną całość. W pewien sposób łączy się też z coraz popularniejszym podejściem Domain Driven Development, w którym to struktura naszych aplikacji powinna odzwierciedlać rzeczywistość. Aby tak było, musimy tę rzeczywistość najpierw poznać. 
 

Na koniec wielka prośba. Jeżeli wpis Ci się podobał i wyniosłeś z niego wartość, proszę daj mi o tym znać! Jeżeli jest coś co mogę poprawić, tym bardziej, proszę, napisz. Będzie mi też niezmiernie miło, jeżeli podzielisz się nim z innymi osobami, które mogą być zainteresowane tematyką designu. 
 

 

Please follow and like us:
newest oldest most voted
Notify of
trackback

Design thinking, co to jest? | Maciej Etgens

Dziękujemy za dodanie artykułu – Trackback z dotnetomaniak.pl