Frame 1

Making D: Principles of Design and Finding Designer Intuition

As we finish our first quarter at AC4D, we continue to ask fundamental questions: What is a design? What makes design unique from other domains? Can a computer design? What’s a design problem?

What is design?

I started this program with a semi-cogent definition of what design is and why I wanted to be a designer: I wanted to make things. I wanted to help people. 

Right now, I’m at the peak of the complexity curve. I’ve gathered so much new information, and haven’t had enough time to internalize it and simplify it. With more information than ever, I’m also more confused than ever. 

So this section as we discussed design thinking, process, and what it means to be a designer — I kept coming back to intuition. Sure, I can absorb information; tell you the difference between an ill-structured problem and a well-structured problem, regurgitate the 10 principles of wicked problems, or teach you a creative exercise using random words. But when presented with a truly wicked problem, can I trust my intuition to know where to start? Can I find my voice as a designer to feel comfortable experimenting with creative problems?

Codifying Design

To help me illustrate this internal tension, I started thinking about the idea of programming these learnings to create a robot design assistant. If you can program something, then you must truly understand it, right?

In 1973, Harold Cohen created AARON, a computer program designed to produce art autonomously.

Cohen trained AARON to create drawings through iterative design progress — evaluating the output and then modifying the program to reflect his own aesthetic. AARON cannot learn on its own, it needs input from Cohen. AARON has received a lot of attention as a feat of engineering and artistic effort — but Cohen is cautious to say AARON is creative. 

It is Cohen who codes his process — he provides the rules. AARON is also incredibly prolific, sometimes making 50 images in an evening. But is it Cohen who chooses from this massive collection of work. He curates the experience. It’s the act of deciding what to teach AARON and curating his paintings that is truly the creative process. 

Blog_Frame 3

So even if I could codify all principles of design and internalize them perfectly, when do I apply them? What’s the problem I’m trying to solve?  

Distilling Principles of Design

In my comic, my character seeks to do just that — with the help of our lastest seven authors aka The Design Council. I start by trying to identify distinct design abilities. Pacione, Cross, and deBono have all identified key skills of a designer. 

Blog_Frame4

Pacione says design skills can not only be codified, but they can also be taught. Cross insists that a designer must be able to:

  • “Produce novel, unexpected solutions
  • Tolerate uncertainty, working with incomplete information
  • Apply imagination and constructive forethought to practical problems
  • Use drawings and other modeling media as means of problem-solving”

And deBono feels that serious creativity can be taught — through concepts as simple as his 6-thinking hat system.

While deBono and Pacione’s perspectives are encouraging for making a design robot, Cross forces my character to start to ask questions. How can a program work in uncertainty? Likewise, when do I, as a designer, know when to tolerate uncertainty or when should I dig further?

Despite this setback, my character moves forward with what I know. D, the robot design assistant, can now draw and share deBono’s creative prompts.

Design Frameworks

Then I move onto Wyatt and Buchanan. While Wyatt has a seemingly simple process for design thinking: Inspiration, Ideation, and Implementation; each process is incredibly nuanced. Buchanan starts to confuse me even further. He says that design can be applied to any area in the human experience. 

If that’s true, then what is a design problem? How can I teach my design assistant (or myself) where to focus?

Again, I move forward with the tangible and my robot can now test prototypes and regurgitate the 3 I’s: Inspiration, Ideation, and Implementation. 

Problem Finding

My character is starting to understand design abilities and frameworks but is stuck on this idea of problem finding. I talk to Simon and Rittel in hopes of gaining clarity. 

Simon has identified the differences between well-structured problems and ill-structured problems. What a great place to start! But unfortunately for my robot — almost all problems are ill-structured. 

Rittel pushes this confusion further, saying:

“In the absence of an overriding social theory or an overriding social ethic, there is no gainsaying which group is right and which should have its ends served.” – Rittel & Webber

Blog_Frame 15

So not only are problems complex and difficult to find, they are everywhere, and there is no unified social order for which problems to prioritize. 

Designer Intuition

Ultimately, my robot ends up spewing out quotes from deBono, Cross, and constantly asking “Why.” While these are all valid contributions to being a designer, it’s vital to know when to apply these tools. You must develop your designerly intuition. 

So just as AARON creates artwork for Cohen, it’s up to Cohen to determine what to teach AARON, and ultimately, which pieces are truly creative. 

I could create a design robot based on the fundamentals of these readings, but it is only through the act of designing that I can start to develop my own voice and intuition.

See the full comic here.