Przypadkiem trafiłem ostatnio na zestawienie dwóch konkurencyjnych teorii designu. W ramach "głębszej inwestygacji" doprowadziło mnie to do wyguglania ciekawego artykułu "Comparing Two Software Design Process Theories" (PDF) Paula Ralpha. Artykuł dotyczy wprawdzie inżynierii oprogramowania, ale opisane w nim podejścia odnoszą się do projektowania ogólnie.

• Perspektywa racjonalna ("Reason-Centric Perspective" lub “The Rational Model”, “Technical Problem Solving”) - w tym podejściu zdefiniowanie problemu poprzedza jego rozwiązanie, są to osobne czynności - myślenie poprzedza działanie. Cele i wymagania projektu zostają określone na początku, a proces projektowy jest implementacją założeń i ma doprowadzić do spełnienia z góry określonych celów w ramach znanych ograniczeń. Ewaluacja polega na porównaniu działania z planem i ocenie zgodności efektów z założeniami. Zmiana założeń powoduje cofnięcie się w procesie do początku.
• Perspektywa zorientowana na działanie ("Action-Centric Perspective" albo “Reflection-in-Action”) zakłada, że definiowanie i rozwiązywanie problemu jest ze sobą ściśle połączone i odbywa się równolegle. Design jest kreatywną improwizacją. Designer przełącza się między definiowaniem problemu, projektowaniem i ewaluacją: "when someone reflects in action, ...he does not keep means and ends separate... he does not separate thinking from doing".

O ile podejście RCP jest zwykle uważane za podręcznikowe, to badanie przeprowadzone przez Ralpha ma wskazywać, że programiści w rzeczywistości częściej pracują w ten drugi sposób (z czym wiążą się odwieczne problemy z niemożliwością dokładnego oszacowania budżetu i harmonogramu w projektach informatycznych):

Graham explains misalignment between programming education and practice – "I was taught in college that one ought to figure out a program completely on paper before even going near a computer. I found that I did not program this way.... I tended to just spew out code that was hopelessly broken, and gradually beat it into shape."

Źródło: Paul Ralph - "Comparing Two Software Design Process Theories"

Teraz, nie znam się na tym, jak powinni pracować programiści, ale z całą pewnością designerzy pracują w ten drugi sposób. Żeby zrozumieć problemy (które bywają paskudne), sprawdzić możliwe rozwiązania, poznać wymagania, sformułować pytania, trzeba zacząć prototypowanie, a feedback do projektu odkrywa nową wiedzę o problemach, celach, wymaganiach, ograniczeniach. Projekt zmienia się iteracyjnie, a to co na końcu powstaje często ma mało wspólnego z początkowym briefem, który w trakcie projektu jest wielokrotnie zmieniany. Jak mówił Josh Payton na zeszłorocznym UX Poland "you don't know what you're doing until you're actually doing it".

At least two views of design activity are consistent with the Action-Centric Perspective. Both involve three basic activities.

In the Reflection-in-Action paradigm, designers alternate between “framing,” “making moves,” and “evaluate moves.” “Framing” refers to conceptualizing the problem, i.e., defining goals and objectives. A “move” is a tentative design decision. The evaluation process may lead to further moves in the design.

In the Sensemaking-Coevolution-Implementation Framework, designers alternate between its three titular activities. Sensemaking includes both framing and evaluating moves. Implementation is the process of constructing the design object. Coevolution is “the process where the design agent simultaneously refines its mental picture of the design object based on its mental picture of the context, and vice versa.”

Źródło: http://www.figmentdesign.com/design/

Jednym z problemów jaki widzę z terminem "design thinking" (i nie tylko ja), jest to że wydaje się rozdzielać "myślenie projektowe" od "projektowania", a to tak nie działa.

Kiedy się o tym myśli, trudno też nie uznać, że wszystkie popularne procesy projektowe w rodzaju "user-centered design" są dalekim uproszczeniem sprawy i w praktyce nie wygląda to dokładnie tak samo, jak model. (Z tym wiąże się kłopot: w jaki sposób powinniśmy uczyć designu?)

(W podejście RCP wpisuje się oczywiście model waterfall, w ACP bardziej metodyki agile.)

A taki proces przedstawił swoim pracownikom Tim Brennan z Apple 🙂

At an off-site for Apple Computer’s Creative Services department, Tim Brennan began a presentation of his group’s work by showing this model. “Here’s how we work,” he said. “Somebody calls up with a project; we do some stuff; and the money follows.”

Brennan captures important aspects of the process:
- the potential for play
- its similarity to a “random walk”
- the importance of iteration
- its irreducible “black-box” nature

Źródło: Hugh Dubberly - "How Do You Design?"