Jak zdiagnozować potrzeby klientów w procesie Design Thinking

Jednak każdy doświadczony badacz wie, że to nie jest takie proste – ludzie bardzo często nie potrafią powiedzieć, czego pragną. Większość nie wie nawet, co chciałaby zjeść dziś na obiad lub jaki prezent chce dostać na urodziny. O pragnienia nie warto więc pytać wprost, ponieważ oczekiwania klientów pojawiają się tylko w określonej sytuacji (np. podczas wizyty w konkretnym sklepie) i w trakcie wywiadu trudno im je przywołać. Są też mocno uwarunkowane wcześniejszymi doświadczeniami, a często są nawet nieuświadomione.

Jak zdiagnozować potrzeby twoich klientów?

W procesie Design Thinking to zadanie spoczywa na barkach zespołu projektowego, który najważniejsze potrzeby badanych określa na podstawie zebranego podczas etapu empatii materiału badawczego. Uczestnicy procesu wybierają te fragmenty wypowiedzi użytkowników, które wydały im się zaskakujące lub najbardziej interesujące i ważne z punktu widzenia całego procesu. Każdą z takich wypowiedzi warto zapisać na osobnej karteczce typu post-it, by podczas dalszych prac móc wygodnie łączyć je w grupy.

 

Grupy/kategorie powinny skupiać cytaty odnoszące się do tych samych problemów, uczuć czy motywacji użytkownika lub powinny odzwierciedlać powtarzany przez badanego schemat zachowań. Każdej kategorii warto nadać nazwę, by w razie potrzeby móc szybko odnaleźć szukane cytaty na tablicy czy ścianie. Na dalszym etapie prac zespół projektowy powinien wyłonić maksymalnie dwie najważniejsze grupy potrzeb klienta, czyli szukane insighty.

Może się zdarzyć, że uczestnicy procesu Design Thinking będą mieli problem ze zdiagnozowaniem najważniejszych potrzeb użytkowników. W przewodniku po metodzie DT, przygotowanym przez firmę IDEO, możemy przeczytać:

Prosty język w marketingu – jak pisać, by dotrzeć do każdego klienta [PORADNIK]

Insights don’t often just jump in your lap; rather they emerge from a process of synthesizing information to discover connections and patterns*.

Tylko prawidłowo zdefiniowany problem może doprowadzić do znalezienia odpowiedniego rozwiązania. Jeśli zespół ma wątpliwości dotyczące swojej diagnozy, lepiej cofnąć się do etapu empatii i dopytać użytkowników o niewyjaśnione wcześniej kwestie, niż tracić czas na dalsze etapy procesu bez 100% pewności, że zespół dobrze rozumie problem, z którym się mierzy, a wyzwanie projektowe jest dobrze zdefiniowane. Wszak Design Thinking to metoda iteracyjna i warto korzystać z możliwości powrotu do poprzedniego etapu podczas całego procesu.

Jak powinno wyglądać dobrze zdefiniowane wyzwanie projektowe?

Podczas drugiego etapu procesu DT należy zawsze pamiętać, dla kogo projektujemy, czyli o personie wyłonionej po etapie empatii. Rozwiązanie, które będzie powstawało w następnym kroku, musi zaspokajać jej potrzeby, a nie potrzeby zespołu badawczego.

Wyzwanie projektowe, które jest konsekwencją zdiagnozowanej potrzeby, nie może być ani za proste, ani za trudne. Ani zbyt szczegółowe, ani zbyt ogólne. Nie może polegać na ratowaniu całego świata, ale na rozwiązaniu konkretnego problemu wyłonionej persony. Musi być inspirujące dla zespołu projektowego i możliwe do spełnienia w czasie trwania projektu. Nie powinno też sugerować żadnego rozwiązania. Zawsze należy pamiętać, że celem klienta nie jest posiadanie parasola (rozwiązanie) tylko pozostanie suchym w deszczowy dzień (potrzeba).

Nie bez znaczenia jest też forma zapisu wyzwania, nad którym pracuje zespół. Warto skorzystać z narzędzia How might we? (Jak moglibyśmy?), które w bardzo prosty sposób pomaga przekształcić zdiagnozowaną potrzebę w zrozumiałe dla wszystkich wyzwanie projektowe. Wracając do przykładu z parasolem, wyzwanie projektowe może brzmieć następująco:

Jak moglibyśmy pomóc Ani pozostać suchą w deszczowy dzień?

Tak sformułowane wyzwanie projektowe jest proste do zapamiętania, zrozumiałe dla każdego uczestnika procesu DT i przede wszystkim na pierwszym miejscu stawia personę, nad którą pracujemy, nie pozwalając zespołowi o niej zapomnieć.

Jobs to be Done

Podczas diagnozowania potrzeb zespół projektowy może wspomóc się też metodą Jobs to be Done, która pomaga zrozumieć, co użytkownicy próbują osiągnąć, korzystając z danego produktu czy usługi i do jakich zadań “zatrudniają” nabyte przedmioty czy opłacanych specjalistów.

JTBD warto zastosować wtedy, kiedy chcemy zaproponować personie inne rozwiązanie problemu niż to, które stosuje dotychczas, szczególnie jeśli nie spełnia ono zdefiniowanej potrzeby w 100%.

A Job to be Done is the process a consumer goes through whenever she aims to transform her existing life-situation into a preferred one, but cannot because there are constraints that stop her*.

Metoda ta pozwala też bardzo dokładnie zdefiniować konkurencję bezpośrednią i pośrednią dla tworzonego rozwiązania. Więcej o Jobs to be Done można przeczytać w darmowym ebooku Alana Klementa When coffee and kale compete.

Na zakończenie warto wspomnieć, że w procesie Design Thinking etap definiowania potrzeb często przeprowadza się dwa razy. Pierwszy raz – ze zleceniodawcą całego procesu (interesariuszem), gdyż brief, z którym przychodzi, nie zawsze odzwierciedla jego realne potrzeby i czasami ukierunkowuje cały proces w niewłaściwą stronę. Podczas wstępnych rozmów warto skorzystać z narzędzia nazywanego Drabiną problemu lub z techniki 5 x dlaczego. Obie metody pozwalają pogłębić temat na tyle, by mieć pewność, że proces Design Thinking rozpoczynamy z właściwych pobudek. Drugi raz diagnozujemy potrzeby potencjalnych klientów zleceniodawcy, do których adresowany będzie produkt lub usługa, nad którą pracuje zespół.

Drabina problemu pozwala dotrzeć do sedna wyzwania poprzez zadawanie zleceniodawcy dodatkowych pytań: najpierw “po co?”, a następnie “jak?”. Pytania powinny być zadawane tak długo, aż zespół uzna, że rozumie problem, z jakim zgłosił się interesariusz. Metoda 5 razy dlaczego pozwala osiągnąć ten sam efekt, ale zadając cały czas pytanie “dlaczego?”. Obie te metody są bardzo proste do wdrożenia, nie wymagają od moderatora procesu DT żadnego wcześniejszego przygotowania. Podstawą ich sukcesu jest wzajemne zaufanie i szczerość między interesariuszem a zespołem projektowym oraz umiejętność przerwania zadawania pytań w momencie, kiedy odpowiedzi zaczynają się zapętlać lub są bardzo ogólne i nie wnoszą do procesu żadnej dodatkowej wiedzy. 

Bardzo często zdarza się też, że już na etapie diagnozowania potrzeb członkom zespołu projektowego przychodzą do głowy pomysły na rozwiązania. W takiej sytuacji warto je gdzieś zanotować, ale nie rozpoczynać dyskusji na ich temat, dopóki etap diagnozy potrzeb nie zostanie zakończony. Na tworzenie rozwiązań przyjdzie pora podczas burzy mózgów – trzeciego etapu procesu DT.