Zespół w MediFlow dostał jasne wymaganie od zarządu: „pacjenci porzucają rejestrację online, bo formularz jest za długi - skróćcie go". Logiczne. Zabrali się do cięcia pól. Zanim jednak zaczęli, jedna analityczka uparła się, żeby najpierw porozmawiać z pacjentami, którzy faktycznie porzucili zapisy. Pięć rozmów później okazało się coś zaskakującego: ludzie nie rezygnowali z powodu długości formularza. Rezygnowali, bo nie ufali, że ich dane medyczne są bezpieczne, i bo nie widzieli, czy zapis się w ogóle powiódł. Skrócenie formularza nie naprawiłoby niczego. Naprawiło to dodanie informacji o bezpieczeństwie danych i wyraźnego potwierdzenia rezerwacji.
To jest sedno design thinking: zanim zaczniesz rozwiązywać problem, upewnij się, że rozwiązujesz właściwy problem. Ta metodyka, znana z projektowania produktów, oferuje analitykowi coś bezcennego - strukturę, która chroni przed budowaniem precyzyjnego rozwiązania na błędnie postawionym pytaniu. W tym artykule przeprowadzę Cię przez pięć etapów design thinking i pokażę, jak każdy z nich wpleść w codzienną pracę z wymaganiami, na przykładzie rejestracji online MediFlow.
Najdroższe projekty to nie te, które źle zbudowano. To te, które zbudowano świetnie - tylko nie to, czego ludzie potrzebowali. Design thinking jest po to, by tego uniknąć.
Czym jest design thinking i dlaczego analityk powinien go znać
Design thinking to iteracyjne podejście do rozwiązywania problemów, które w centrum stawia człowieka - użytkownika, jego potrzeby i jego rzeczywiste zachowania. Składa się z pięciu etapów: empatia, definiowanie problemu, generowanie pomysłów (ideacja), prototypowanie i testowanie. To nie sztywny algorytm, tylko elastyczny framework - etapy się przeplatają, wraca się do poprzednich, iteruje.
Dla analityka design thinking to nie konkurencja dla klasycznej analizy wymagań, lecz jej dopełnienie. Tradycyjna analiza często zaczyna się od pytania „jakie są wymagania?". Design thinking cofa się o krok i pyta „jaki problem naprawdę rozwiązujemy i czyj?". Ta zmiana perspektywy - z rozwiązania na problem, z systemu na człowieka - chroni przed całą klasą kosztownych pomyłek, jak ta ze wstępu.
Pięć etapów design thinking w pracy analityka
Etap 1: Empatia - zrozum, zanim zaczniesz rozwiązywać
Pierwszy i najczęściej pomijany etap. Empatia to głębokie zrozumienie potrzeb, motywacji i frustracji użytkownika - nie z dokumentów, lecz z bezpośredniego kontaktu. To różnica między „zakładamy, że pacjenci chcą krótszego formularza" a „rozmawialiśmy z pacjentami i wiemy, czego naprawdę chcą".
Narzędzia empatii dla analityka:
- Wywiady pogłębione. Pytania otwarte, nie zamknięte. Zamiast „czy formularz jest za długi?" pytaj „opowiedz mi o ostatnim razie, gdy próbowałeś zapisać się online - co się działo?". Pozwól ludziom mówić, słuchaj frustracji.
- Obserwacja. Patrz, jak ludzie faktycznie korzystają z systemu, a nie jak mówią, że korzystają. Często rozjeżdża się to dramatycznie.
- Persony. Reprezentacje typowych użytkowników oparte na zebranych danych. Dla MediFlow: „Zabiegana mama" (chce zapisać dziecko w 2 minuty z telefonu), „Senior" (boi się, że coś klikie nie tak), „Pacjent przewlekły" (rezerwuje regularnie, ceni szybkość). Każda ma inne potrzeby.
- Mapa empatii. Co użytkownik mówi, myśli, robi i czuje - narzędzie porządkujące obserwacje. Jej naturalnym rozwinięciem jest customer journey map, czyli rozpisanie całej ścieżki użytkownika krok po kroku.
To na tym etapie analityczka z MediFlow odkryła, że problemem jest zaufanie, nie długość formularza. Pięć rozmów uratowało projekt przed naprawą nieistniejącej usterki.
Etap 2: Definiowanie problemu - postaw właściwe pytanie
Na podstawie empatii definiujesz prawdziwy problem. To najważniejszy moment, bo źle zdefiniowany problem prowadzi do świetnego rozwiązania nie tej sprawy. Dobry problem jest sformułowany z perspektywy użytkownika i jest na tyle wąski, by dało się go rozwiązać.
Źle: „Formularz rejestracji jest za długi". Dobrze: „Pacjenci porzucają rejestrację, bo nie ufają, że ich dane medyczne są bezpieczne, i nie mają pewności, czy rezerwacja się powiodła". Druga wersja od razu sugeruje kierunek rozwiązania - i jest prawdziwa, bo wynika z rozmów, nie z założeń.
Pomocna technika to 5 Why - drążenie przyczyny pytaniem „dlaczego" aż do sedna:
- Dlaczego pacjenci nie kończą zapisu? Bo porzucają formularz.
- Dlaczego go porzucają? Bo wahają się przy podawaniu danych medycznych.
- Dlaczego się wahają? Bo nie wiedzą, czy dane są bezpieczne.
- Dlaczego nie wiedzą? Bo nigdzie tego nie komunikujemy.
- Dlaczego nie komunikujemy? Bo nikt o tym nie pomyślał, zakładając, że problem to długość.
Dobrym formatem zapisu problemu jest też „How Might We" - „Jak moglibyśmy sprawić, by pacjent czuł, że jego dane są bezpieczne, i miał pewność udanej rezerwacji?". Takie sformułowanie otwiera na pomysły zamiast je zamykać.
Etap 3: Ideacja - generuj pomysły bez oceniania
Mając właściwy problem, generujesz jak najwięcej rozwiązań. Zasada nadrzędna: na tym etapie liczy się ilość, nie jakość, i nie oceniamy pomysłów (krytyka zabija kreatywność). Dziwaczny pomysł często prowadzi do dobrego.
Techniki ideacji:
- Burza mózgów - zespołowo, z zasadą „buduj na cudzych pomysłach, nie krytykuj".
- Crazy 8's - 8 pomysłów w 8 minut, presja czasu wymusza kreatywność.
- SCAMPER - lista bodźców (Substitute, Combine, Adapt, Modify, Put to other use, Eliminate, Reverse) do generowania wariantów.
- Mind mapping - rozwijanie pomysłów wokół centralnego problemu.
Dla problemu zaufania w MediFlow burza mózgów daje dziesiątki pomysłów: certyfikat bezpieczeństwa przy polu z danymi, ikona kłódki, informacja „dane szyfrowane", wyraźny ekran potwierdzenia, e-mail i SMS z potwierdzeniem, pasek postępu pokazujący, ile jeszcze kroków, opinie innych pacjentów, kontakt do recepcji „na wszelki wypadek".
Etap 4: Prototypowanie - zbuduj coś, co da się dotknąć
Zamiast wdrażać wszystkie pomysły, budujesz tanie prototypy wybranych. Prototyp to uproszczona wersja rozwiązania - szkic, makieta, klikalny mockup - wystarczająco konkretna, by ją przetestować, i wystarczająco tania, by ją wyrzucić. Celem nie jest perfekcja, lecz szybkie sprawdzenie, czy pomysł ma sens.
Zespół MediFlow tworzy w Figmie kilka wariantów ekranu rezerwacji: jeden z certyfikatem bezpieczeństwa tuż przy danych, drugi z paskiem postępu i mocnym ekranem potwierdzenia, trzeci z opiniami pacjentów. Trzy prototypy, kilka godzin pracy, zero kodu produkcyjnego.
Etap 5: Testowanie - skonfrontuj z rzeczywistością
Pokazujesz prototypy prawdziwym użytkownikom i obserwujesz, zbierasz feedback, iterujesz. To nie etap „odhaczenia", tylko nauki - porażka prototypu jest tania i cenna, bo uczy, zanim zbudujesz na poważnie.
W teście z pacjentami MediFlow okazuje się, że największe zaufanie buduje certyfikat bezpieczeństwa umieszczony bezpośrednio obok przycisku „Zarezerwuj" oraz wyraźny ekran potwierdzenia z numerem wizyty. Pasek postępu pomaga mniej, niż zakładano, a opinie pacjentów w tym kontekście rozpraszają. Te obserwacje wracają do wymagań - i dopiero teraz, po pięciu etapach, zespół buduje rozwiązanie, które faktycznie naprawia problem ze wstępu.
Podwójny diament - myślenie rozbieżne i zbieżne
Jest jeden wzorzec, który spina wszystkie pięć etapów w spójną całość: podwójny diament (Double Diamond). Pokazuje on, że dobre rozwiązywanie problemu to rytmiczne przeplatanie dwóch trybów myślenia - rozbieżnego (otwieramy się, generujemy, badamy szeroko) i zbieżnego (zawężamy, decydujemy, wybieramy).
Pierwszy diament dotyczy problemu, drugi rozwiązania:
- Diament 1 - właściwy problem. Najpierw rozbieżnie badasz przestrzeń problemu (empatia: zbierasz jak najwięcej obserwacji i potrzeb), potem zbieżnie go zawężasz (definiowanie: jedna, ostra definicja problemu).
- Diament 2 - właściwe rozwiązanie. Najpierw rozbieżnie generujesz mnóstwo pomysłów (ideacja), potem zbieżnie wybierasz i weryfikujesz (prototyp i test).
Ten obraz tłumaczy najczęstszy błąd zespołów: zwijają się za wcześnie. Słyszą problem („formularz za długi"), od razu skaczą do jednego rozwiązania („skróćmy go") i pomijają oba etapy rozbieżne. Pomijają badanie problemu (nie rozmawiają z pacjentami) i badanie rozwiązań (nie generują alternatyw). Efekt to historia ze wstępu - precyzyjna odpowiedź na źle postawione pytanie. Podwójny diament przypomina: zanim zawęzisz, najpierw się otwórz - dwa razy.
Jak prowadzić design thinking w praktyce
Teoria pięciu etapów to jedno, prowadzenie warsztatu to drugie. Kilka rzeczy, które decydują o tym, czy design thinking faktycznie zadziała, czy zostanie tylko hasłem na slajdzie.
Design sprint - skondensowana wersja
Jeśli nie masz tygodni na pełny proces, sięgnij po design sprint - pięciodniowy format spopularyzowany przez Google Ventures, który przeprowadza zespół przez najważniejsze etapy w jednym tygodniu: poniedziałek to mapowanie problemu, wtorek to szkice rozwiązań, środa to decyzja, czwartek to budowa prototypu, piątek to testy z użytkownikami. Dla analityka to potężne narzędzie, gdy projekt utknął albo gdy trzeba szybko zweryfikować ryzykowny pomysł, zanim pochłonie budżet.
Rola analityka jako facylitatora
W warsztatach design thinking analityk często wciela się w facylitatora - osobę, która prowadzi proces, ale nie narzuca treści. To wymaga konkretnych umiejętności: zadawania otwartych pytań, pilnowania, by nikt nie dominował, powstrzymywania przedwczesnej krytyki podczas ideacji i sprowadzania dyskusji z powrotem do potrzeb użytkownika, gdy zespół zaczyna projektować „pod siebie". Dobra facylitacja to często różnica między warsztatem, który generuje przełom, a takim, który kończy się niczym.
Praktyczne zasady, które warto egzekwować
- Oddziel generowanie od oceny. W fazie pomysłów żadnej krytyki - nawet „ale to drogie". Ocena ma swoją osobną fazę.
- Wracaj do użytkownika. Gdy dyskusja schodzi na „co nam wygodniej zbudować", przypomnij: „a czego potrzebuje pacjent?".
- Pokazuj, nie opowiadaj. Zamiast dyskutować o pomyśle godzinę, zrób w 20 minut prosty prototyp i pokaż go.
- Testuj na właściwych ludziach. Feedback od zespołu projektowego nie zastąpi feedbacku od prawdziwego pacjenta - zespół jest „skażony" wiedzą o produkcie.
Design thinking a klasyczna analiza wymagań
| Klasyczna analiza | Design thinking | |
|---|---|---|
| Punkt startu | „Jakie są wymagania?" | „Jaki problem i czyj naprawdę rozwiązujemy?" |
| Źródło wiedzy | Interesariusze, dokumenty | Bezpośredni kontakt z użytkownikiem |
| Podejście | Często liniowe | Iteracyjne, z powrotami |
| Stosunek do pomysłów | Wcześnie oceniane i wybierane | Najpierw ilość, ocena później |
| Najmocniejsze, gdy | Problem jest dobrze znany | Problem jest niejasny lub źle postawiony |
To nie jest wybór „albo-albo". Najlepsi analitycy używają design thinking, by dobrze zrozumieć i zdefiniować problem, a klasycznych technik analizy, by precyzyjnie opisać rozwiązanie. Design thinking nie zastępuje specyfikacji wymagań - sprawia, że specyfikacja opisuje właściwą rzecz.
Najczęstsze błędy przy stosowaniu design thinking
- Pomijanie empatii. Skok prosto do pomysłów bez rozmów z użytkownikami. To dokładnie błąd, którego uniknęła analityczka z MediFlow - i najczęstszy grzech zespołów „robiących design thinking" tylko z nazwy.
- Definiowanie problemu jako rozwiązania. „Problem: brak przycisku X" to nie problem, to ukryte rozwiązanie. Prawdziwy problem opisuje potrzebę użytkownika, nie brakującą funkcję.
- Ocenianie pomysłów podczas ideacji. „To się nie uda" zabija burzę mózgów w pierwszej minucie. Krytyka ma swój czas - później, nie teraz.
- Prototyp zbyt dopracowany. Im ładniejszy prototyp, tym trudniej go wyrzucić i tym mniej szczery feedback (ludzie nie chcą krytykować czegoś, co wygląda na gotowe). Im wcześniejszy etap, tym surowszy prototyp.
- Testowanie dla potwierdzenia, nie dla nauki. Jeśli wchodzisz w test, by usłyszeć „świetne!", usłyszysz to - i niczego się nie nauczysz. Test ma wyłapać problemy, nie pogłaskać ego.
- Traktowanie etapów jak sztywnej listy. Design thinking jest iteracyjny. Czasem z testów wracasz do empatii, bo odkryłeś, że problem był inny. To nie porażka, to istota metody.
FAQ - design thinking w analizie biznesowej
Czy design thinking zastępuje analizę wymagań?
Nie - dopełnia ją. Design thinking pomaga zrozumieć i poprawnie zdefiniować problem oraz potrzeby użytkownika. Klasyczne techniki analizy służą do precyzyjnego opisania rozwiązania (specyfikacja, user stories, kryteria akceptacji). Najlepsze efekty daje połączenie obu.
Ile czasu zajmuje przejście przez pięć etapów?
Od kilku dni do kilku tygodni, zależnie od skali. Istnieje też skondensowana wersja - design sprint - która przeprowadza przez najważniejsze etapy w pięć dni. Nie musisz robić wielkiego projektu badawczego; nawet pięć wywiadów (jak w MediFlow) potrafi zmienić kierunek całego przedsięwzięcia.
Który etap jest najważniejszy?
Empatia i definiowanie problemu - bo to one decydują, czy w ogóle rozwiązujesz właściwą sprawę. Najlepszy prototyp i najszczerszy test nic nie dadzą, jeśli problem był źle postawiony. To również etapy najczęściej pomijane pod presją czasu.
Czy design thinking sprawdza się tylko przy projektach z interfejsem?
Nie. Choć przykłady często dotyczą UI, podejście działa dla dowolnego problemu, w którym liczą się potrzeby ludzi - procesów wewnętrznych, usług, organizacji pracy. Wszędzie tam, gdzie ryzykujesz zbudowanie świetnego rozwiązania niewłaściwego problemu, design thinking ma zastosowanie.
Podsumowanie
Design thinking daje analitykowi to, czego najbardziej brakuje pod presją terminów: dyscyplinę, by najpierw zrozumieć problem, a dopiero potem go rozwiązywać. Pięć etapów - empatia, definiowanie, ideacja, prototyp, test - to nie biurokracja, lecz zabezpieczenie przed najdroższą pomyłką w projektach: zbudowaniem czegoś perfekcyjnego, czego nikt nie potrzebował. Czasem wystarczy pięć rozmów z prawdziwymi użytkownikami, by zawrócić projekt z fałszywej ścieżki - jak w MediFlow, gdzie „skróćcie formularz" okazało się odpowiedzią na niewłaściwe pytanie.
Design thinking zazębia się z innymi kompetencjami analityka - z prototypowaniem (etap 4 i 5), z technikami elicytacji wymagań (empatia to elicytacja w czystej postaci) i z wywiadami z interesariuszami. Chcesz przećwiczyć design thinking na realnych projektach analitycznych? Zajrzyj do szkoleń Analify.