Design Thinking Process to hasło, które w ostatnim czasie zyskało ogromną popularność. Internet pęka w szwach od artykułów, definicji i grafik ilustrujących ten proces. Założę się o dobrą caffe latte, że większość osób z branży IT już o nim słyszała, a pozostali usłyszą lada moment.

Z uwagi na tę popularność, nie chcę powielać ogólnodostępnych definicji. Zamiast tego, skupię się na konkretnym studium przypadku i moich doświadczeniach z tą metodą. Chcę pokazać jej uniwersalność i dodatkowe korzyści, które nie zawsze są widoczne na pierwszy rzut oka.

• 1️⃣ Dlaczego potrzebujemy Design Thinking w pracy …

  • 1.1. Kto, kiedy, po co i jak? Czyli jak należy ten …

  • 1.2. Kiedy sięgnąć po Design Thinking?

  • 1.3. Niezbędne Narzędzia w Procesie Design Thinkin …

• 2️⃣ Case Study: Tydzień z Design Thinking w naszym …

  • 2.1. Czwartek: Empatia i Definiowanie Problemu

  • 2.2. Poniedziałek: Zanurzenie w Dane i Przełamywan …

  • 2.3. Wtorek: Krok w tył, dwa kroki do przodu

  • 2.4. Środa: Detale, półmetek i informacja zwrotna

  • 2.5. Czwartek: Czas na "Design Crita"

  • 2.6. Piątek: Finałowa prezentacja i testy

• 3️⃣ Podsumowanie i "Lessons Learned"

Kim jestem i dlaczego o tym piszę?

Nazywam się Magdalena Ptak - na co dzień mam przyjemność pracować jako UX Designer i prowadzić zespół Designerów Produktów w jednym z krakowskich fintechów (IG). Praca projektanta w tak wymagającej i delikatnej domenie biznesowej, jaką są finanse, bywa sporym wyzwaniem.

Wcześniej współpracowałam z kilkoma Krakowskimi Software House’mi, realizując projekty dla: The Coca-Cola Company HQ, Heineken, T-Mobile, Porsche Austria, Farmfoods, Tesco, Payfont (mobile IOS App), Polo Ralph Lauren, ASDA, Macys, Michael Kors, American Bankers Association

1️⃣ Dlaczego potrzebujemy Design Thinking w pracy produktowej?

W typowym modelu scrumowym zespoły produktowe, w skład których wchodzą Product Designerzy, realizują kolejne kamienie milowe z roadmapy produktu. Ta roadmapa jest często wypadkową wymagań biznesu, czasem kompromisem wypracowanym przez Product Ownera uwzględniającego perspektywę techniczną. Bądźmy jednak szczerzy – to biznes najczęściej definiuje kierunek rozwoju produktu, co jest zrozumiałe, bo produkt musi na siebie zarabiać.

Mam jednak głębokie przekonanie, że prawdziwe zaangażowanie zespołu i poczucie sensu płyną ze wspólnie wypracowanych celów. I to jest właśnie idealne miejsce na zastosowanie Design Thinking Process.

1.1. Kto, kiedy, po co i jak? Czyli jak należy ten cały Design Thinking Process poprowadzić?

Jako UX Designerzy, nasza codzienna praca naturalnie krąży wokół technik związanych z Design Thinking. Łączymy wymagania biznesu z możliwościami technologii, a przede wszystkim jesteśmy adwokatami użytkownika końcowego. Skupiamy się na definiowaniu i rozwiązywaniu problemów.

Product Designerzy i UX Designerzy wydają się predysponowani do roli facylitatora w tym procesie, ponieważ posiadają unikalny zestaw kompetencji:

• Umiejętności miękkie: empatia, aktywne słuchanie, obserwacja, świetna komunikacja.

• Zrozumienie technologii: zdolność pojmowania technicznych zawiłości.

Ten miks jest bezcenny podczas planowania i moderowania warsztatów z zespołem deweloperskim, interesariuszami i wszystkimi osobami w organizacji, których wiedza może okazać się kluczowa.

1.2. Kiedy sięgnąć po Design Thinking?

Design Thinking Process jest narzędziem, z którego warto skorzystać zawsze, bywają jednak momenty w cyklu pracy zespołu, kiedy wręcz trzeba to zrobić. Z mojego doświadczenia wynika, że taki moment nadchodzi, gdy pojawia się stagnacja w zespole, a morale jego członków spada.

Warto wówczas zebrać interesariuszy i cały zespół projektowy w jednym pokoju, stworzyć atmosferę równości i bezpieczeństwa, tak aby każdy z obecnych był w stanie swobodnie podzielić się pomysłami dotyczącymi usprawnienia produktu.

Podczas etapu generowania idei kluczowa jest jedna zasada: liczą się pomysły, a nie rola osoby, która się nimi dzieli!

Technicznie można to zorganizować w kilku krokach:

1. Stwórz "Kreatywną Ścianę Pomysłów": Każdy uczestnik zapisuje swoje pomysły na samoprzylepnych karteczkach i umieszcza je na wspólnej tablicy.

2. Moderuj i zapewnij równość: Zadaniem facylitatora jest dbanie o to, by każdy głos został usłyszany i każda karteczka znalazła się na tablicy.

3. Przedstaw i pogrupuj pomysły: Wszystkie idee są prezentowane, a autorzy mają szansę je doprecyzować. Podobne pomysły są grupowane w kategorie.

4. Zagłosuj na najlepsze idee: Każdy uczestnik otrzymuje określoną liczbę głosów (np. 3) i oddaje je na pomysły, które uważa za najbardziej wartościowe.

5. Wybierz pomysł do realizacji: Na koniec wybierana jest idea, która zyskała największe poparcie i jest realna do opracowania w ograniczonym czasie.

Po takim spotkaniu każdy powinien czuć, że jego wkład był ważny. To buduje zaangażowanie na dalszych etapach.

1.3. Niezbędne Narzędzia w Procesie Design Thinking

• Logistyka (Kalendarz, E-mail): Kluczowe jest odpowiednio wczesne zaplanowanie warsztatów i poinformowanie uczestników. Zgranie kalendarzy kilkunastu osób bywa wyzwaniem, dlatego szanujmy swój czas, ustalajmy agendy i bądźmy przygotowani.

• Miro (Wirtualna Tablica): Niezastąpione narzędzie do współpracy w czasie rzeczywistym. Idealne do planowania procesu, zbierania pomysłów i podsumowywania pracy.

• Figma (lub inne narzędzie do prototypowania): Niezbędna do wizualizacji i prezentacji proponowanych rozwiązań w formie interaktywnych makiet.

2️⃣ Case Study: Tydzień z Design Thinking w naszym Zespole

Cały proces osadziliśmy w ramach jednego, intensywnego tygodnia pracy, który poprzedziliśmy około dwutygodniowym okresem przygotowań logistycznych. Oto jak wyglądał nasz warsztatowy tydzień, dzień po dniu.

2.1. Czwartek: Empatia i Definiowanie Problemu

Wybraliśmy czwartek jako start naszego sporintu. Pierwsze spotkanie z całym zespołem produktowym i kluczowymi interesariuszami miało na celu zidentyfikowanie największych bolączek i wyzwań.

• Cel spotkania: Stworzenie bezpiecznej przestrzeni do swobodnej wymiany myśli i zdiagnozowanie problemów z perspektywy różnych ról w zespole.

• Przebieg warsztatu:

  • Burza mózgów: Każdy uczestnik zapisywał na samoprzylepnych karteczkach zarówno problemy, które dostrzega w produkcie lub procesie, jak i pomysły na nowe funkcjonalności. Celowo nie ograniczaliśmy formy, aby uzyskać jak najszerszy obraz sytuacji.

  • "Kreatywna ściana": Wszystkie karteczki trafiły na wspólną tablicę, tworząc mapę myśli całego zespołu.

  • Głosowanie: Każdy otrzymał trzy głosy, aby wskazać tematy, które uważa za najważniejsze.

• Kluczowe odkrycie: Po podliczeniu głosów wyłoniliśmy trzy najistotniejsze kwestie. Po krótkiej dyskusji wspólnie zdecydowaliśmy się skupić na jednym, konkretnym problemie, który miał największy potencjał do rozwiązania w ciągu nadchodzącego tygodnia.

• Moment "Aha!": Największą wartością tego spotkania było to, że interesariusze po raz pierwszy usłyszeli, jak bardzo frustrujące dla deweloperów jest kodowanie banerów marketingowych "ad hoc". Uświadomili sobie, że te zadania odciągają zespół od realizacji kluczowych celów z roadmapy produktu.

2.2. Poniedziałek: Zanurzenie w Dane i Przełamywanie Silosów

9:00 rano na zegarku oznacza, że mamy 5 pełnych dni, aby postarać się i „dowieźć” rozwiązanie na wyselekcjonowany problem. Otwieramy miro – i patrzymy na plan, a następnie po kolei dzwonimy do wcześniej wytypowanych osób (mając przygotowane pytania i agendę), które pomogą nam zgromadzić więcej informacji i uzupełnić luki w naszej wiedzy.

• Plan działania: Otworzyliśmy naszą tablicę w Miro, przejrzeliśmy plan i z przygotowaną listą pytań zaczęliśmy kontaktować się z ekspertami w całej organizacji.

• Przełamywanie barier: To był dzień intensywnych rozmów, które pozwoliły nam przełamać firmowe "silosy informacyjne". Skontaktowaliśmy się z:

  • Periklisem z zespołu Data Science,

  • Elizą i Caitillin z Marketing & Content,

  • Shobaną, która jest deweloperką webową.

• Wszyscy wspomniani wcześniej dzielą się z nami wiedzą i pomagają nam zrozumieć ich perspektywę, pojawiają się nowe dane i nowe pytania, na tym etapie mamy wrażenie, że, mamy więcej pytań, niż odpowiedzi.

• Efekt: Pod koniec dnia nieśmiało próbujemy zrobić pierwszy design – szkic na ścianie pokoju konferencyjnego, jest na nim wiele znaków zapytania i pustych przestrzeni, nie jesteśmy do niego bardzo przywiązani – więc jako doświadczenia UX Designerzy liczymy się z tym, że kolejnego dnia rano, po przyjściu do pracy i spojrzeniu na tą pierwszą iterację krytycznym okiem – być może stwierdzimy kolektywnie, że ją zmazujemy!

2.3. Wtorek: Krok w tył, dwa kroki do przodu

9:00 rano, 2 UXów i 1 UI Designer, otwierają miro board oraz krytycznym okiem oceniają wczorajszą pierwszą iterację rozwiązania na ścianie. Wspólnie stwierdzamy, że zbyt szybko chcieliśmy rysować rozwiązanie, a za mało jeszcze wiemy i rozumiemy.

Robimy krok w tył, konsultujemy kilka niewiadomych z deweloperami, sprawdzamy co jest możliwe do zaimplementowania ze strony technicznej – biorąc pod uwagę ograniczenia technologii i dług technologiczny. Robimy pracę UXową „od podstaw”:

• Zmiana strategii: Zdecydowaliśmy się zrobić krok w tył, aby lepiej zrozumieć fundamenty problemu.

• Działania:

  • Konsultacje techniczne: Ponownie spotkaliśmy się z deweloperami, aby dogłębnie zrozumieć ograniczenia technologiczne i istniejący dług techniczny.

  • Praca UX "od podstaw": Zaczęliśmy od narysowania szczegółowego diagramu procesu. Umieściliśmy w nim kluczowe role ("aktorów") oraz zdefiniowaliśmy interakcje i zależności czasowe między nimi. Musieliśmy najpierw rozłożyć stary proces na czynniki pierwsze, aby móc zbudować nowy.

  • Digitalizacja: Pod koniec dnia przenieśliśmy nasze odręczne szkice i diagramy do Figmy, co stanowiło solidną podstawę do dalszej pracy.

2.4. Środa: Detale, półmetek i informacja zwrotna

Środek tygodnia zaczęliśmy od spotkania z zespołem produktowym i biznesem (niemal ten sam skład, który uczestniczył w pierwszym spotkaniu, gdy wybieraliśmy problem dla naszego warsztatu z Design Thinking Process).

Chcieliśmy podzielić się informacjami, które zebraliśmy oraz przedstawić kierunek, w którym chcielibyśmy pójść proponując rozwiązanie. Miro i figma pomogły nam lepiej zwizualizować koncepty i wytłumaczyć co robiliśmy dotychczas oraz co planujemy w kolejnych krokach. Dostaliśmy informację zwrotną od wszystkich zaangażowanych, nastąpiła kolejna wymiana wiedzy, doświadczyliśmy wielu momentów „aha”, bez dwóch zdań był to wartościowy czas.

• Spotkanie z zespołem: Zorganizowaliśmy spotkanie w niemal tym samym składzie, co na początku.

  • Cel: Podzielenie się zebranymi informacjami i przedstawienie wstępnej koncepcji rozwiązania.

  • Narzędzia: Użyliśmy Miro i Figmy, aby zwizualizować nasze postępy i ułatwić zrozumienie proponowanych zmian.

  • Wynik: Otrzymaliśmy bezcenną informację zwrotną i doświadczyliśmy wielu momentów "aha", gdy różne osoby zaczęły łączyć kropki.

• Ciągła komunikacja: Poza oficjalnym spotkaniem, byliśmy w stałym, nieformalnym kontakcie z Product Ownerem, Tech Liderem i głównym interesariuszem. To pozwoliło nam na bieżąco weryfikować założenia i unikać potencjalnych błędów.

• Postępy: Dzień zakończyliśmy z drugą, znacznie bardziej szczegółową wersją diagramu oraz pierwszą wersją klikalnego prototypu w Figmie.

2.5. Czwartek: Czas na "Design Crita"

Prototyp gotowy, jest czwartek godzina 10:30 – dla nas i naszego zespołu Product Designerów to dzień, kiedy nastaje cotygodniowy czas konstruktywnej krytyki od naszych kolegów po fachu. Jest to moment, w którym uzasadniamy swoje decyzje projektowe, tłumaczymy, dlaczego wybraliśmy to, a nie inne rozwiązanie.

• Sesja konstruktywnej krytyki: "Design Crit" to nasz cotygodniowy rytuał, podczas którego prezentujemy projekty i bronimy swoich decyzji projektowych.

• Przebieg: Zespół zadawał dociekliwe pytania i rzucał wyzwanie naszym założeniom. Krytyka nie jest tu brana do siebie - jej celem jest stworzenie jak najlepszego produktu.

• Wynik: Koledzy zwrócili uwagę na kilka niedopracowanych "edge case'ów" (skrajnych przypadków użycia), którym nie poświęciliśmy wystarczającej uwagi. Mieliśmy jeszcze pół dnia, aby poprawić te sporne miejsca w prototypie przed finałową prezentacją.

2.6. Piątek: Finałowa prezentacja i testy

Koniec tygodnia to czas, aby zaprezentować wynik naszej przeszło tygodniowej, warsztatowej pracy. O ustalonym czasie i miejscu, stawili się wszyscy uczestnicy, którzy wzięli udział w pierwszym spotkaniu.

Zanim przeszliśmy do przedstawienia propozycji rozwiązania, przedstawiliśmy uczestnikom kilka danych, jakie udało nam się zebrać w trakcie procesu, które dodatkowo podkreśliły istotność wziętego na warsztat problemu.

Jedną z takich informacji było wyliczenie i zestawienie na podstawie danych historycznych dwóch metryk obrazujących, że kodowanie banerów marketingowych ad hoc, pochłonęło porównywalną liczbę roboczogodzin co stworzenie wersji MVP jednego z większych feature’ów w portalu (dashboardu dla klientów). Zestawienie tych dwóch danych, umocniło zasadność wybranego problemu oraz dało podwaliny dla argumentacji naszego rozwiązania, dlaczego warto zainwestować czas, aby stworzyć kompleksowe rozwiązanie.

• Rozpoczęcie prezentacji: 

  • Finalna prezentacja rozpoczęła się od przypomnienia problemu, czyli: „W jaki sposób serwować treści marketingowe na jednym z portali – minimalizując przy tym zaangażowanie zespołu deweloperskiego (deweloperów i testerów)”.

  • Podczas prezentacji, poinformowaliśmy zespół o naszych odkryciach, czyli dodatkowych narzędziach (CQ, Adobie Audience Manager), używanych do serwowania i segmentowania treści marketingowych w innych zespołach oraz o możliwości ich użycia w kontekście naszego produktu.

  • Omawiając prototyp, zaproponowaliśmy nowych aktorów w procesie publikacji oraz przedstawiliśmy ich workflow w czasie. Postaraliśmy się też wytypować dodatkowe osoby, których pomoc będzie niezbędna w zaimplementowaniu nowego procesu (czyli dostosowanie i wdrożenie istniejących narzędzi) oraz wykazaliśmy orientacyjne estymacje pracochłonności. Ponadto odkryliśmy, że nie da się zupełnie wyłączyć QA testera z zespołu produktowego z nowego procesu, ponieważ zanim nowe treści marketingowe zostaną opublikowane i tak cały portal musi być sprawdzony i przetestowany.

• Prezentacja rozwiązania:

  • Konstruując rozwiązanie problemu, oprócz wizualizacji i prototypu, staraliśmy się przedstawić dane, obrazujące takie metryki jak ilość osób, zaangażowanych w nowy proces + koszt zaimplementowania nowego procesu + możliwe predykcje (jaki będzie koszt gdy zostawimy stary proces, a jaki gdy wdrożymy nowy przy zainwestowaniu zasobów w tym momencie). Te wszystkie dane zostały przedstawione na ostatnim spotkaniu.

  • Jako Designerzy i facylitatorzy Design Thinking Proces postaraliśmy się „połączyć wszystkie kropki w skończonym czasie” oraz opracować możliwe do zaimplementowania rozwiązanie dla zdefiniowanego wcześniej problemu.

  • Decyzję czy i kiedy warto je wdrożyć – pozostawiliśmy Product Ownerowi i interesariuszom.

Wierzymy, że dzięki warsztatom z Design Thinking Process, zespół produktowy otrzymał solidną instrukcję jak pozbyć się problemu, biznes natomiast dowiedział się o problemie, który frustruje członków zespołu i całkiem sporo kosztuje firmę.

3️⃣ Podsumowanie i "Lessons Learned"

Czego się nauczyliśmy przeprowadzając warsztaty z Design Thinking Process?

1. Wiedza w zespole nie jest równa. Osoby techniczne często nie czują sprawczości. Design Thinking pomaga wyrównać wiedzę i oczyścić atmosferę.

2. Duże organizacje mają problem z dzieleniem się wiedzą. Dotarcie do właściwych osób bywa trudne. Rola facylitatora wymaga rozwiniętych umiejętności miękkich.

3. Design Thinking to proces definiowania rozwiązania, a nie jego wdrażania. Implementacja to osobny, wymagający projekt.

4. Facylitacja to praca na pełen etat. Prowadzenie warsztatów DT wymaga zaangażowania co najmniej dwóch osób i trudno to pogodzić z innymi obowiązkami.

5. Proces jest intensywny i nie zawsze kończy się sukcesem. Mimo to, jest niezwykle satysfakcjonujący. Pod koniec tygodnia czuliśmy się wyczerpani, ale i spełnieni.

6. Otrzymaliśmy bardzo pozytywny feedback od wszystkich zaangażowanych osób.

7. Nasze rozwiązanie do dziś czeka w kolejce na wdrożenie. Jako designerzy wciąż czekamy na ten moment, by poczuć pełne spełnienie.

Nasz Proces w Liczbach:

• Dni: 7 (+1 dzień na planowanie)

• Osób zaangażowanych: 25 (+ 17 designerów na Design Crit)

• Spotkań: 3 duże + niezliczona ilość mniejszych

• Ilość iteracji designu: 3

• Ilość użytych żółtych karteczek: 273 (fizycznych i w Miro)

P.S. 1. Nasz proces został zmodyfikowany i dostosowany do warunków organizacji, jednak trzymaliśmy się jego kluczowych założeń.

P.S. 2. Dziękuję moim Dizajnerom – Marcinowi i Adrianowi – za ciężką pracę, a Ani (PO) za pozytywne podejście do projektu.