Początki nowego projektu bywają czasem straszne. Jesteś proszony(a) o wycenę i harmonogram prac, kiedy nie wiesz, jeszcze co dokładnie chcesz (albo trzeba będzie) zrobić. Główny problem wydaje się niejasny, brakuje odpowiedzi na wiele pytań, masz przeczucie, że niektórych pytań nie jesteś w stanie jeszcze nawet sformułować, ale powinieneś(aś) znać odpowiedzi. Masz wrażenie, że temat jest zbyt skomplikowany i rozległy, żeby go zrozumieć, czujesz się przytłoczony(a) przez mniejsze problemy i wymagania. Wszystko jest poplątane: jedna rzecz ma wpływ na inną, tamta na kolejne i odwrotnie. Musisz podejmować decyzje wiedząc, że nie wiesz wszystkiego, a inne ważne decyzje, których wynik powinieneś(aś) znać już teraz zostaną podjęte dopiero dużo później.

Siedzisz w ciemności z latarką i nie wiesz, co się czai obok 🙂

Jeżeli to uczucie jest dla ciebie znajome, to dlatego, że większość problemów projektowych i kreatywnych, to tzw. „wicked problems” („zaplątane problemy”? - nie znalazłem dobrego polskiego tłumaczenia).

Definicję "wicked problems" opracowali w 1973 roku Horst Rittel i Melvin Webber. Te paskudne problemy:

• Nie mają jednego prawdziwego i fałszywych rozwiązań, tylko lepsze lub gorsze. A w dodatku każda osoba zaangażowana w projekt może mieć inne zdanie na temat tego, co będzie lepsze, a co gorsze;
• Liczba rozwiązań jest nieskończona;
• Nie da się w 100% przetestować żadnego rozwiązania;
• Nie ma jednej prawdziwej definicji problemu (można go różnie sformułować);
• Opisanie problemu determinuje jego rozwiązanie (stąd olbrzymia rola briefu projektowego!);
• Problem nie jest do końca zrozumiały, dopóki nie wygeneruje się rozwiązania (więc istnieje też zależność odwrotna, niż w poprzednim punkcie);
• Każde rozwiązanie generuje swoje problemy, każdy problem może być traktowany jako symptom innego problemu.

Wiele problemów związanych z projektowaniem, biznesowych, marketingowych, projekty IT, to "wicked problems", które wymagają kreatywnych rozwiązań.

Jak projektanci rozwiązują problemy?

Bardzo dobry opis zaproponował Ariel Guers:

Projektanci ograniczają liczbę możliwych podejść i formułują ogólne założenia od samego początku. Nie powstrzymują się z osądem i decyzjami, aby otworzyć się na nowe podejścia, jak najszybciej tworzą pierwsze (częściowe) rozwiązanie (dla częściowo zdefiniowanego problemu) i posuwają się do przodu, patrząc czego mogą się nauczyć na temat problemu poprzez kolejne iteracje.

[Designers usually consider a *very limited* set of alternatives and develop guiding principles right from the start. They don’t postpone judgment and decision making in order to open-up to new alternatives, they rapidly create a rough (partial) solution (to a partially defined problem) and move forward to see what else they can learn about the problem, through iterations.]

Ponieważ definicja problemu zależy od jego rozwiązania, trzeba zacząć pracę nad jakimś rozwiązaniem, żeby lepiej zrozumieć (i być może zredefiniować) początkowy problem. Problemy projektowe mają charakter systemowy (każda część systemu zależy od innej, a każdy system może być częścią innego systemu), więc potrzebne jest „spojrzenie z lotu ptaka", a potem posuwanie się małymi krokami w kolejnych iteracjach, żeby zrozumieć wszystkie zależności. Czasami efekt procesu jest czymś zupełnie innym, niż na początku zakładaliśmy.

Projektowanie to myślenie poprzez tworzenie. ("Designers learn by doing.") Stąd moje obiekcje związane z terminem „design thinking”, który próbuje oddzielić „myślenie projektowe” od właściwego projektowania. Tak w każdym razie wiele osób, to rozumie (patrząc np. na komentarze do tego wpisu).

Ale jeśli zajrzeć do artykułu Tima Browna z 2005 roku wygląda to trochę inaczej:

Myślenie projektowe (design thinking) jest z natury procesem prototypowania. Kiedy trafisz na obiecujący pomysł, budujesz to. Prototyp to zwykle rysunek, model albo film opisujący produkt, system lub usługę. Budujemy te modele bardzo szybko, są surowe i mało eleganckie, ale działają. Celem nie jest stworzenie aproksymacji gotowego produktu czy procesu, celem jest zebranie feedbacku, który pomoże nam w rozwiązaniu problemu. W pewnym sensie budujemy, żeby myśleć.

[Design thinking is inherently a prototyping process. Once you spot a promising idea, you build it. The prototype is typically a drawing, model, or film that describes a product, system, or service. We build these models very quickly; they're rough, ready, and not at all elegant, but they work. The goal isn't to create a close approximation of the finished product or process; the goal is to elicit feedback that helps us work through the problem we're trying to solve. In a sense, we build to think.]

Chcesz myśleć jak designer? Skończ pieprzenie o design thinking i zacznij projektować 🙂 Zaprezentuj innym swoje projekty i prototypy, tak by mogli je zobaczyć, poczuć, ocenić i rozwinąć.