Lubomir,

You don't see a theory-level similarity between engineering designing 
(as it is practised, NOT reported in the lit) and other kinds of 
designing (like Teena's wine label design)?

I do.  Granted, I am casting my own biases on things - which may or may 
not be best - but I do see something there.

I have, in the past, been asked by other designers how I teach design, 
for e.g., and told them, and they're surprised to hear it was in line 
with how they taught design.

"You must be a font designer, like me," they say.

"Uh, no; I'm an engineer."  I reply.

I see tasks - not necessarily always in the same order - appear 
consistently when I see non-engineers designing things.  These include 
'understanding the problem,' (oops, the P word again), 'conceiving 
alternatives', 'selecting alternatives', 'fleshing out / making manifest'.

I also see many methods or techniques like what we call 'root cause 
analysis', FMEA, morphological charts, pairwise comparison, etc - and 
especially analogical reasoning (which is I think the same as your 
precedent strategy, Lubomir) - being used to one degree or another, more 
or less formally, with or without knowing it.

Almost every architect and urban planner I've witnessed 'on the job' 
does some kind of what engineers call 'system design' even though the 
architects & urban planners usually don't *know* they're doing it.

And I'm sure I'm unknowingly using techniques or methods from other 
non-engineering fields.

All this suggests to me that there's a deeper similarity, one-up from 
practise - i.e. at the theory level - than is generally considered.

Cheers.
Fil

Lubomir S. Popov wrote:
> Hello everyone,
> 
> It is getting interesting. The original thread that Terry started could 
> have lead us to discuss our differences. Instead, we started discussing 
> the nature of design problems an demonstrated our differences.
> 
> I have no problem with the notion of problem. Usually, "engineering" 
> designers are pretty much at ease with it and actually love it. On the 
> other side are the artists, they hate it. Actually they do 
> problematization, but in a different way. Fill explained it beautifully. 
> Artists are in a different situation compared to engineers and can 
> afford a broad and soft approach. Compared to the Arts, Engineering is 
> already in an advanced stage of explicating its own methodology. (I will 
> reconsider this if you object.) There is a tendency to explicate the 
> process and the method in every profession. Luckily for the humankind, 
> the Arts resist this tendency and continue to operate with the broad 
> net. However, if we go back in history and compare, we might see that 
> compared to previous epochs, nowadays even artists start explicating 
> their process and method and becoming more reflective over the steps in 
> the process.
> 
> I can understand Teena if she is a book illustrator. Very often defining 
> the problem might lead to a poor illustration. The reason is that the 
> problem might not be defined properly or adequately at that time, or the 
> artist simply cannot go step-by-stem from the problem to the solution. 
> There are other ways to sniff and fetch. I teach my students how to 
> conceptualize and start with a design concept. However, after the first 
> half of the project time passes away without a good design, I encourage 
> students to change the strategy -- just find an exiting precedent and 
> make something innovative. The precedent carries in its genotype the 
> problem and the solution. That is the logic of the precedent approach.
> 
> I personally work on the phase of problem definition in design and love 
> my business. It makes the process and the outcome more predictable. In 
> the design areas where the functional requirements are paramount, 
> starting with an initial definition of the problem helps a lot, saves 
> time and effort, and in the long run, brings better functional performance.
> 
> We are all designers, but we are also very different designers. I mean 
> our substantive areas are different. Each substantive area has its own 
> peculiarities in ontological and methodological aspect. (Forgive me for 
> using these concepts here.) That makes the design process and method of 
> a civil engineer very different form the process and method of the 
> architect, and I bet, very different from the process of an illustrator.
> 
> Our common ground cannot be found at practice level. It cannot be found 
> even at theoretical level. Our common ground is at philosophical level. 
> If we want to talk one language, we need to discuss these issues at a 
> very abstract level. We can say that there are general principles of 
> design that apply to all design fields. But these general principles are 
> so abstract that they never appear in their scholastic format in design 
> practice and even at the theoretical levels of different design 
> disciplines. These principles crystallize in their full beauty only when 
> we talk at philosophical level about the planning and design approach 
> (Gerals Nadler, 1981).
> 
> To be honest, at the beginning I was curious what is Terry doing when he 
> asked that question about our disciplinary design affiliations. Now I 
> might be interested more than him. Knowing each other background, it 
> will be easier to figure out what the other colleague thinks and says, 
> why that colleague thinks that way, and why he or she objects a 
> particular concept.
> 
> Kind regards,
> 
> Lubomir
> 
> Lubomir Popov, Ph.D.
> Associate Professor
> School of Family and Consumer Sciences
> 309 Johnston Hall
> Bowling Green, OH 43403-0059
> phone: (419) 372-7935

-- 
Filippo A. Salustri, Ph.D., P.Eng.
Department of Mechanical and Industrial Engineering
Ryerson University
350 Victoria St, Toronto, ON, M5B 2K3, Canada
Tel: 416/979-5000 ext 7749
Fax: 416/979-5265
Email: [log in to unmask]
http://deseng.ryerson.ca/~fil/