Hi Eduardo,

A complex and hefty design program makes the job of the designer more difficult. No question. The designer has to consider more requirements, contextual information, and contingencies. But if the designer manages all that, the product might become groundbreaking. 

If we think about creativity in terms of problem solving, a good program will lead to a better product. If we think about creativity as personal expression or a way to come with amazing and unexpected solutions, then the program might be experienced by some designers as a restricting and constricting imposition. If designers believe that creativity is about expressing their believes (read preconceptions), ideas, or personal experience, again, they see the program as a nuisance. In a number of fields and areas, designers want to be left alone. They (we) designers know best. Don't teach us what to do. OK. I am fine with that as long as their designs are really good. ("Good" has to be defined, but here we come again to the realm of specifications and definitions.)

I always say that the (architectural) project is as good as the client is, not the architect. Architects can do much better job than they usually do if the client knows how to work with them. Usually architects are expected to know what the client needs and to prepare a design that the client will adore. This can happen only if Corbusier designs for Ozenfant. 

If clients let architects to invent the program, they will get in trouble. I know a case with a star architect when that person after getting the design commission, augmented the program (and the budget) three times only to have justification for a large mass and big spans. The paradox was that his interiors and the exterior views were clogged and restricted. The client did nothing to prevent this for fear to lose the star architect. I strongly believe that the paying clients can do much more, and also, very creative architects can fulfill complex programs. They are bright and resourceful people and they can solve the programmatic problems if they are pressed hard enough.

Best,

Lubomir

-----Original Message-----
From: PhD-Design - This list is for discussion of PhD studies and related research in Design [mailto:[log in to unmask]] On Behalf Of joao lutz
Sent: Tuesday, August 02, 2011 10:43 AM
To: [log in to unmask]
Subject: Re: Act First, Do the Research Later

systematic research can be a very creative activity and enhance joyous
productivity !
cheers.

2011/8/2 Eduardo Corte Real <[log in to unmask]>

> No sonnets today.
>
> I see no trouble with Don's article. First it is written as an opinion
> (that's good that we can share opinions), second it is obviously written for
> those that are able to call "research" to some of their activities and to
> call "design" to some of their activities other than the previous.
>
> This discussion is drifting away from what I think is the core
> issue/question of Don's article that is somewhat a design myth (and like any
> myth, has some truth in it) about "sometimes too much research kills
> creativity".
>
> Best regards,
>
> Eduardo
>
>
>
>
> On 02-08-2011 15:13, Frederick van Amstel wrote:
>
>> Don:
>>
>>  I have read your email several times and cannot quite understand
>>> which interpretation of "research" you have in mind, but it is clear to
>>> me
>>> that your meaning is somewhat different than the particular one i had in
>>> mind.
>>>
>>>  That's true. Let's use the three notions of Design Research that
>> Frankel&
>> Racine identified on this list (and the literature) as a common ground:
>> http://www.**designresearchsociety.org/**docs-procs/DRS2010/PDF/043.pdf<http://www.designresearchsociety.org/docs-procs/DRS2010/PDF/043.pdf>
>>
>> Your article was targeted on the clinical view: Research for Design.
>> Research to inform design, to inspire, to serve as an input for creative
>> ideas.
>>
>> I'm making the case that Research Through Design happens during all phases
>> of design practice, even if there is no dedicated research phase. The
>> knowledge produced by this type of research is not a set of requirements,
>> but instead an interpretation of new observations in face of previous
>> experiences. It can be made explicit on sketches or prototypes, but even
>> if
>> it's not, it's still part of the design action in the world.
>>
>>
>>