Dear Terry

A lot of work that is handled by designers may at some time be done by
machines and software. These would be routine tasks as well as multiple
iterative testing routines that should ideally be left to machine mediated
processes if we have developed software to handle this adequately.

However there would still be tasks that would need human intervention and
creative interpretation that should be the subject of our current schools
of design thought and action.

Gunnar suggests that some of the automated tasks may not be called design
and I too think we would need alternate terminology to explain those kinds
of tasks. Design is a process that uses multiple types of skills, knowledge
and abilities all applied in a complex array of stages and contexts. So it
is not a single task nor is it limited to one iteration since many design
offering go through numerous stages and some in the real world as test beds
for scaling up at a later stage.

Yes, we do need theory to explain many of these and I am sure new
challanges will come up as we go forward.

With warm regards

M P Ranjan
from my Mac at CEPT University
17 October 2012 at 10.10 am IST

-------------------------------------------------------------
*Prof M P Ranjan*
*Design Thinker and author of blog -
www.Designforindia.com<http://design-for-india.blogspot.com/>
*
E8 Faculty Housing
National Institute of Design
Paldi
Ahmedabad 380 007 India

Tel: (res) 91 79 26610054
email: ranjanmp@g <[log in to unmask]>mail.com

<http://www.ranjanmp.in/>blog: <http://www.design-for-india.blogspot.com>
(current and with downloads)
education blog: <http://www.design-concepts-and-concerns.blogspot.com>
(archival)
education blog: http://www.visible-information-india.blogspot.com (archival)

web site: http://homepage.mac.com/ranjanmp (disabled by Apple)
<http://homepage.mac.com/ranjanmp>web domain: http://www.ranjanmp.in (disabled
by Apple)
<http://www.visible-information-india.blogspot.com/>
------------------------------------------------------------

On 17 October 2012 03:21, Terence Love <[log in to unmask]> wrote:

> Dear Ken,
> Thank you for your post.
> You proposed a view contrasting human-created vs. machine-created designs.
> Using a slightly more nuanced view on design seems to offer some additional
> benefits in making theory relating to design principles and the
> relationship
> between design principles and design research. I suggest avoiding a rigid
> dichotomy between human and machine to takes into account in a gradated
> manner the limitations of human ability in regard to skills, knowledge,
> creativity, intuition, thinking and feeling. Doing this offers a way of
> including the bounded rationality of humans raised by Simon in relation to
> his definition of design, and extending it in view of more recent
> understanding about human abilities.
> This post is in three parts. Part A suggests a more nuanced 4 part taxonomy
> of designs than the human-created vs. machine-created design approach and
> outlines differences in the roles of design principles for each. Part B
> outlines an approach to understanding design principles that focuses on
> their relationship with design research outcomes, and raises the need for a
> body of design theory linking them. Part C outlines potential reasons why
> analyses such as those described in Parts A and B are overlooked in some
> areas of design practice and design research and suggests ways forward.
> Part A - 4 part spectrum of human-created vs. machine-created designs and
> design principles
> The limitlessness of human creativity and intuition has until recently been
> a touchstone of design theory in some areas of design. More recently,
> however, it has become increasingly obvious human creativity and intuition
> are significantly limited in terms of the scope of design problems they can
> address and the complicatedness and complexity of many everyday design
> problems are beyond the ability of any individuals or groups of individuals
> to either understand or predict the outcomes. These latter abilities are
> central to competent design.
> This means there is a distinct class of problems and design solutions in
> most disciplines beyond what humans are capable of designing 'in mind' or
> by
> discussion and without using mathematical or technical methods. A more
> nuanced understanding of design must include this 'beyond human ability'
> category. It suggests to a spectrum of four categories:
> 1.      Straightforward designs and design problems of the scale in which
> human designers can identify best design solutions or designs for solutions
> that satisfy their intended purpose(s) using in mind or non-mathematical
> design approaches such as intuitive decision making, subjectively-based
> creativity, and non-determinative design methods such as brain storming,
> post-it lists, group discussions, etc.
> 2.      Designs and design problems that are undertaken by humans but which
> lie outside the biological ability for humans to identify best solutions;
> designs for solutions that fully satisfy their intended purpose(s), or
> designs for solutions that do no additional harm or result in unwanted
> outcomes. The result of these forms of design activity is always design
> failures in part or whole. I have identified a criterion for one large
> group
> of these forms of designs (the 2 Feedback Loop Axiom). Lack of awareness of
> this category of designs by designers and design researchers has been
> perhaps the most fundamental cause of design failures and adverse longer
> term consequences of designs.
> 3.      Designs and design problems that lie beyond the biological ability
> of humans individually or in groups to identify best solutions; designs for
> solutions that fully satisfy their intended purpose(s), or designs for
> solutions that do not also do harm or result in unwanted outcomes AND for
> which this limitation is overcome using mathematically-based simulations,
> models, algorithms, solution space optimisation methods etc.
> 4.      Designs and design problems in which the identification of best
> solutions; designs for solutions that fully satisfy their intended
> purpose(s), and designs for solutions that do no additional harm or result
> in unwanted outcomes (i.e. the whole of the design activity) can be fully
> automated using digital or analog machines.
> The role of 'design principles' or perhaps better phrased, 'design
> guidelines', differs in each:
> For the first category, there has already been the development of many
> design principles/guidelines. For example, in graphic design, these include
> the development of the 'colour wheel' and the sundry design
> principles/guidelines about colour combinations, the use of layout grids
> and
> the design guidelines for emulating particular 'styles' or 'cultures' of
> output. In fact, anything that is or can be explicitly taught in a graphic
> design degree could be classed as a design principle/guideline. These forms
> of design principles/guidelines often intuitively follow from the outcome
> of
> user analyses.
> For the second category, there is essentially only one type of design
> principle/guideline: to identify whether or not the design problem being
> addressed is in the class of those that lie outside the biological ability
> for humans to identify best design solutions, designs solutions to satisfy
> their intended purpose(s), or designs for solutions that do no additional
> harm or result in unwanted outcomes. The 2 Feedback Loop Axiom is one
> design
> principle of that type.
> For the third category, there is also essentially only one class of types
> of
> design principle/guideline that apply. Such design principles comprise two
> parts: A) to identify whether or not the design problem is in the class of
> those that lie outside the biological ability for humans to identify best
> solutions, designs for solutions that fully satisfy their intended
> purpose(s), or designs for solutions that do no additional harm or result
> in
> unwanted outcomes; and B) a part that guides how to address it using
> mathematically-based or simulation methods that enable the creation of
> designs that humans are biologically unable to understand 'in mind'. An
> example design principle/guideline is: A) identify design problems that are
> outside the scope of human subjective creative/intuitive design activity
> using the 2 Feedback Loop Axiom; and B) use a System Dynamic modelling
> method (or a similar mathematically-based modelling tool) in combination
> with solution selection and optimisation algorithms to identify best or
> satisfactory solutions that fulfil the intended purposes of the design and
> avoid harmful outcomes.
> For the fourth category of designs, the design principles must typically be
> developed in a theoretical environment such that the information about the
> detailed interrelationships in relevant areas of problem/design space is
> complete enough to be digitally or analogically modelled and analysed for
> satisfactory and optimal design solution characteristics. Over the last
> thirty years, with the widespread use of digital logic machines for
> simulation this has typically required the information about the detailed
> interrelationships in the problem/design space to be of a form that can be
> expressed mathematically in a form that can be digitally processed. Prior
> to
> this, and currently coming into vogue again, are the use of analog
> simulation, analysis and optimisation approaches.
> Part B - Theorising about the relationship between design principles and
> design research findings.
> The primary role of 'design principles' is to guide decision making about
> design solutions. In that sense, they are perhaps better referred to and
> understood as 'design guidelines'. This applies regardless of whether they
> are on the designer or user sides of design solutions.
> One of the tacit assumptions of undertaking design research (and educating
> designers) is information already available is of use to designers in
> making
> decisions during their activity in creating designs. The creation of design
> principles/guidelines involves reframing that existing information into a
> coherent and justifiable statement to guide to the decision making of
> designers in specific situations. In other words, the role of design
> principles/guidelines is to define aspects of designs. In essence, one
> could
> infer the primary role of design research is to identify findings from
> which
> design principles/guidelines can be derived.
> In the most trivial cases, the relationship between the evidence from
> design
> research and design guidelines is by simple association. For example:
> Research finding: 'girls between the ages of 4 and 10 like pink'.
> Design guideline: 'Use pink for packaging products for girls aged 4 to 10'.
> Many of the simpler design principles/guidelines taught to undergraduate
> visual designers have this direct associative relationship between research
> finding and the derived design principle/guideline.
> Over the last 5 decades, design researchers and designers have, however,
> been researching more complex design-related situations and attempting to
> develop design principles from the findings of that research.
> This presents a challenge in identifying how design research findings can
> be
> used in design practice. The core of this problem is deriving a coherent
> body of theoretical approaches for creating design principles/guidelines
> from design research findings. This is a new body of theory:
> .       Theoretical findings from design research (existing bodies of
> theory)
> .       Theories about how to convert findings of design research into
> design principles (new body of theory)
> .       Theoretical representations of design principles (existing bodies
> of
> theory)
> Identifying the theoretical basis for deriving design principles from
> design
> research findings is difficult but not intrinsically impossible. The same
> sort of problem is found in most disciplines in which professionals make
> decisions involving social and technical issues. Many of these disciplines
> have addressed this issue well by developing theoretical approaches that
> identify exactly how the principles that guide professional decisions are
> derived from research findings. Many areas of design have not yet done
> this.
> This is worth emphasising. For many areas of design, the theoretical
> foundations of for deriving design principles from design research findings
> have not yet been developed. It is not intrinsically impossible. It simply
> hasn't yet been done.
> One significance of this lack of justified relationship between design
> principles/guidelines and design research findings is it is potentially at
> the heart of why design practitioners in some areas of design have ignored
> design research.
> The lack of theoretical foundation for deriving design
> principles/guidelines
> from design research findings has three additional adverse effects:
> .       It reduces designers' claims to be professionals and reduces their
> status compared to other professionals.
> .       It results in design principles/guidelines that are unjustified or
> under justified and perhaps invalid.
> .       It results in a lack of guidance for new trajectories of design
> research
> Part C - Potential reasons for lack of theoretical foundations for design
> principles/guidelines.
> Disciplines that have justified theoretical approaches for deriving design
> or professional decision making principles and guidelines from research
> findings typically represent knowledge and research findings formally -
> usually in a form that can be manipulated mathematically.
> Complicating the situation is a widespread assumptions made by those who do
> not use formal theorisation such as in mathematics or philosophy is that
> non-mathematical and mathematical design approaches are equivalent but
> exclusively different alternatives born of different cultures. This is
> found
> in the simplistic idea that one can be a scientist OR an artist and that
> either is as good as, or covers the same territory as, the other. The
> reality is that the formalisation (e.g. by mathematical methods) ADDS to
> the
> normal human design skills. The use of formal methods of analysis and
> representation increases and adds to and extends human design ability and
> range of action and understanding in design research and practices,
> particularly in addressing complex design situations.
> The ways humans can increase their scope of understanding and ability to
> predict design outcomes via mathematical, scientific and other formal
> methods is obvious to those designers trained in those approaches. This
> understanding of the power of these formal methods appears, however, to be
> opaque to those without mathematical and scientific training. For those
> trained in both classical humanities approaches and mathematical and
> scientific approaches, the considerable extension that the mathematical
> approaches offer is obvious.
> The above points to four potential implications:
> .       The development of design as a profession is limited by the current
> lack of a body of theory for converting design research findings into
> verifiable and explicit design principles/guidelines
> .       A more nuanced understanding of the spectrum of human-created to
> machine-created designs offers increased understanding, particularly in
> areas in which the biological limitations of human creativity and intuition
> result in compromised or faulty design outcomes.
> .       The lack of appreciation in some design fields of the benefits of
> mathematically-based design approaches seems due to lack of education in
> mathematical and scientific understanding in designers and design
> researchers.
> .       Increased mathematical and scientific education alongside classical
> design education is likely to be of benefit in improving design outcomes
> and
> design theory for the future.
> Best wishes,
> Terence
> ==
> Dr Terence Love
> Director,
> Love Design and Research
> [log in to unmask]
> +61 (0)434 975 848
> ==
>
>
> -----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 Ken
> Friedman
> Sent: Sunday, 14 October 2012 7:56 PM
> To: Dr Terence Love
> Subject: Re: Design principles from design research findings?
>
> Dear Terry, Luke, and Elizabeth,
>
> Thanks for your thoughts. I started to write a few quick notes. After
> examining this problem from several angles, my quick note turned into
> several pages. Please forgive the length - the issues here are deeper than
> they may seem to be at first glance. The problem starts with the fact that
> Terry rephrased the Cooler Solutions advertisement. In doing so, he
> reframed
> the problem at the heart of his query. First, therefore, I return to
> Terry's
> original post, comparing his query to the text of the Cooler Solutions
> advertisement.
>
> Terry requested something larger and more general than the advertisement
> does. The ad seeksindividuals "versed in all phases of design research:
> from
> proposal strategy, research design, conducting research, development of
> insights and translating them into design principles."
>
> Terry's note changes the ad to "expertise in 'converting research findings
> into design principles'." Then Terry asks, "Does anyone have any formal
> methods for doing this in ways that explicitly define specific aspects of a
> design?"
>
> This is more general and grander in ambition than translating insights from
> research into designprinciples. This is often possible. In contrast, a
> general system of formalmethods that translate research findings into
> explicitly defined specifications for artifacts or processes is rarely
> possible. This is because the challenge of any design problem is embedded
> in
> the specifics of the problem at hand.
>
> To ask for formal methods that permit "converting research findings into
> design principles . that explicitly define specific aspects of a design"
> raises the problem of induction.
>
> There are several aspects to this. Some research findings are general
> enough
> to permit deductive inference. For example, we cannot design anything that
> violates the laws of physics. Relatively few problems that involve design
> research require investigating fundamental physical principles, but the
> fundamental principles embedded innatural law inevitably influence systems
> that are governed by natural law. While these laws do not constitute
> questions for design research, therefore, research findings in physics,
> chemistry, medicine, biology, and other fields necessarily form the
> background knowledge to design research and design. This principle allows
> us
> to use bio-mimicry, nanotechnology, strong materials, and other advanced
> technologies in design research and design.
>
> Induction permits us to move forward to the next step in a problem. But the
> problem of induction is that it is contingent and not probative. C. S.
> Peirce (1992: 186-199) considered this in his work on deduction, induction,
> and hypothesis. John Vickers (2010) wrote an excellent online article on
> the
> problem of induction in theStanford Encyclopedia of Philosophy.
>
> --
>
> For the Vickers article, go to URL:
>
> http://plato.stanford.edu/entries/induction-problem/#ConNotInd
>
> --
>
> The problems of induction are linked to the virtues of induction, and to
> the
> design process. Peirce argues that induction involves implicative
> inference.
> It builds on and adds to what we experience and what we know. Nevertheless,
> nearly every practical design problem of the kind that a professional firm
> must solve emerges from the specifics of a case - a case brought to the
> firm
> by clients. If an easily available general solution were to exist, the
> client would notnormally bring the problem to a consulting firm. Some
> firms,
> of course, develop specific and wide-ranging expertise in certain kinds of
> problems, and consulting firms that do so can often use earlier work to
> solve new cases, reducing their costs while enhancing their profits. For
> many problems, however, this doesn't work, and that's what makes research
> necessary. Translating specific research findings through some formal
> method
> into general solutions that also function in a specific case is rarely
> possible. As Peirce (1992: 194) writes, "classifications [solutions] in all
> cases perfectly satisfactory hardly exist."
>
> Here is where the iterative nature of the design process makes a
> difference,
> both in understanding the problem and in developing a solution. As Vickers
> (2010: np) notes, "The great advantage of induction is not that it can be
> justified or validated, as can deduction, but that it can, with care and
> some luck, correct itself, as other methods do not." This corrective
> process
> takes place in iterative testing against reality or in iterative trials of
> solutions.
>
> In this sense, there is a difference between methods and formal methods.
> There is a rich body of methods that develop insights from research that
> can
> then be translated into design principles for application in specific
> cases.
> This is rather different to "formal methods for . explicitly defin[ing]
> specific aspects of a design." In this sense, the term formal suggests
> algorithms that we can apply in the mathematical or logical sense of the
> term. The Oxford English Dictionary defines this as: "Done or made with the
> forms recognized as ensuring validity; explicit and definite, as opposed to
> what is matter of tacit understanding." This is a version of
> rule-generated,
> formal description. I may be reading too much into Terry's note, but this
> is
> the kind of algorithmic formalism that would permit computers or machines
> to
> design. This is one reason I argue that computers cannot design, and it is
> also related to another aspect of my view on this - that machines cannot
> interactive or engage in any meaningful sense with thehuman beings that
> come
> to design firms with problems requiring solutions.
>
> I agree with Elizabeth that we have a rich array of useful ways to move
> from
> insights and general rules to specific choices. She notes, for example,
> "brainstorming, selection matrices, concept testing with potential users,
> etc." These are useful and proven methods, but they are not formal. We
> cannot reduce them to algorithms. They require human engagement, expertise,
> mastery, and craft. In this sense, I'd suggest that the answer to Terry's
> question is no, there are no formal methods. I'm not disputing the robust
> quality or usefulness of many available methods - I simply say that these
> do
> not constitute formal methods capable of comprehensive, analytical
> description for explicitly defining specific aspects of a design solution -
> neither in the case of designed artifacts, nor in the case of designed
> processes. There are artifacts or processes that embody rules that function
> within their programmed limits toexplicitly define aspects of the solutions
> they are programmed to yield, but there are no formal methods prescribing
> how to design these artifacts or processes.
>
> The art and craft of research - and the art of translating developing
> insights from research that we translate into design principles - are bound
> by the problems inherent in Karl Weick's (1979: 35-42) useful metaphor
> research clock. The clock has two hands and three positions: 12 o'clock, 4
> o'clock, and 8 o'clock. These three positions represent the general, the
> accurate, and the simple. Weick argues that we can achieve two of these
> qualities in any one project, but not all three.
>
> We can be general and accurate but not simple. We can be accurate and
> simple
> but not general. Or we can be general and simple but not accurate. In each
> case, wefill two criteria by accepting the fact that we must sacrifice one
> of the three criteria: generality, accuracy, or simplicity.
>
> Solving design problems usually requires accuracy and simplicity. Because
> problems are specific, solving design problems does not usually does not
> require generality. It simply requires that we do not violate any general
> laws that govern the range of solutions we create - for example, a hidden
> internal perpetual motion generator might be a wonderful solution to a
> specific client problem, but the laws of physics make such a generator
> impossible.
>
> The nature of principles is essentially heuristic. The advertisement did
> not
> request expertise in general algorithmic translation of research findings
> into explicit rules-driven design specifications. It asked for individuals
> skilled at using research to generate "insights . translating them into
> design principles," an appropriate set of principals to reasonably govern
> any specific solution.
>
> Beckman and Barry (2007) draw a useful link between several literatures -
> design, innovation, and learning. I found their approach very helpful. For
> the published version of a keynote speech I delivered at the IDATER
> conference (Friedman 2000), I added an appendix describing some of the
> innovation literature and attempting to build links, but my approach was
> more abstract and general, examining the issues rather than describing the
> process. Beckman and Barry (2007) describe the process.
>
> --
>
> For the online version of the keynote, go to URL:
>
> http://hdl.handle.net/2134/1360
>
> --
>
> Terry's follow-on question to Elizabeth asks one question and implies a
> second. He asks specifically "exactly how individual design principles
> (imperatives) are identified as being the best to link to the specifics of
> 'an understanding of customer or user needs'? How are they formally derived
> from needs? I'm wondering how the selection process is done formally via
> brainstorming and selection matrices, etc."
>
> The answer to the question is simple: there is no exact way to identify
> individual design principles that link an understanding of customer or user
> needs to a formally derived solution. Design requires an iterative
> selection
> process embedded in the specifics of a problem situation. There are classes
> and sub-classes of problems that yield to formal selection and solution. It
> should nevertheless be clear that a process such as brainstorming is not a
> formal process.
>
> Processes such as brainstorming and other heuristic approaches have a
> "form"
> or a "method" in the sense that we can describe them. They are not formal
> in
> the sense they that the form is invariant, rigorous, or necessarily valid
> in
> the sense of a formal logic. They are not methodic in the sense that they
> entail valid prescriptive steps that yield valid, equivalent solutions
> across any range of problems to which we apply them.
>
> In this sense, there are many kinds of design methods, and many seem to
> function better than brainstorming. The literature demonstrates problems
> with brainstorming as amethod - but, then, any design method of
> problem-solving method entails problems as well as potential virtues. What
> I'm saying here is that this is true of any heuristic or expert and skilled
> professional method for solvingproblems.
>
> The second question is implicit: how do skilled designers solve problems?
> Books such Nigel Cross's (2011) Design Thinking. Understanding How
> Designers
> Think and Work examine the realities of how designers use design principles
> and an understanding of customer or user needs to a develop solutions.
> These
> solutions are not formally derived but iteratively developed.
>
> While there may be a better word to choose than "imperatives," Beckman and
> Barry (2007: 41-42; see also Fig. 3, p. 30) describe the process nicely:
> "Imperatives may be derived from understanding what is missing for the
> users
> of the prospectiveinnovation. Imperatives may simply be a set of selected
> needs or may embody a set of rules, sometimes called design principles,
> which must be kept in creating the innovation. Imperatives are extracted
> from the insights and models created in the framing stage of the innovation
> process so that they are very clearly linked to an understanding of
> customer
> or user needs." They draw on one of Chuck Owens's models to identify
> imperatives as guiding principles located in the realm of ideas.
>
> This series of questions gets back to an earlier thread on the question of
> whether computers or other machines can design. That is the question: can
> computers of other machines engage in the professional practice of design
> rather than simply serving as tools or adjuncts to a human designer. The
> earlier thread drifted away into a question on what is labeled "flat
> ontology." I have been reading my way through some of this literature
> (f.ex., Bogost 2012), and reviewing some of the literature on Actor Network
> Theory. Some of the argumentation is sophisticated and ingenious, but I
> don't yet believe that machines can design. This is not the subject of my
> note today, and I am going to wait until I've thought these issues through
> to explain why I maintain the position that machines cannot design in the
> sense that humans can design.
>
> The reason I raise the issue here is simple. If we could develop a valid,
> formal method for converting research findings into design principles that
> explicitly define specific aspects of solutions to design problems, it is
> possible that we could program machines with the ability to design as human
> beings do.
>
> Terry has elsewhere argued that computers can indeed practice design. If
> Cooler Solutions had written the position description as Terry rephrased
> it,
> they could probably get by with a junior designer and a senior-level
> computer rather than a senior-level applied social scientist.
>
> But Cooler Solutions needs someone with experience and skill in the
> developing insights and translating them into design principles. Insight
> remains a human domain, at least at this time.
>
> There is no valid formal language that translates human insights into
> design
> principles. If there were, we would require a second formal language to
> apply general design principles to specific problems in a way that
> generates
> explicitly defined,useful solutions if these formal languages were to
> support professional design practice in a rigorous, consistent way. At this
> time, there no formal languages demonstrate these properties.
>
> This, of course, applies to all design processes - both the professional
> practice of design and the practice of research. One of the crucial
> challenges of research is the application of judgment to problems (see,
> f.ex., McGrath, Martin, and Kulka1982). While this is evidence in design
> and
> other applied social sciences, it is even true of physics and of
> mathematics. The history of mathematics demonstrates three thousand years
> of
> judgment calls and intuitive leaps (see, f.ex., Hersh 1999) that gave rise
> to the deductively valid and rigorous systems we see in the formal
> languages
> of mathematics.
>
> In such rigorous, consistent systems as physics and mathematics, machines
> can only solve well-defined, formally stated problems. The reason we need
> physicists and mathematicians rather than with machines for the major
> problems that remain in physics and math is that defining problems requires
> insight.
>
> Formal languages are not applicable to a discipline where problems are
> always embedded in a human context. Formal languages and rigorous formal
> methods can be used to solve subsidiary problems and problem sets, but the
> key aspects of most design problems require judgment and insight.
>
> This is why Cooler Solutions is hiring a human being with experience and
> skill in developing insights and translating them into design principles to
> guide the specifics of designing solutions for clients that come to Cooler
> with problems embedded in the human and physical world.
>
> Best regards,
>
> Ken
>
> Professor Ken Friedman, PhD, DSc (hc), FDRS | University Distinguished
> Professor | Swinburne University of Technology | Melbourne, Australia |
> [log in to unmask] | Phone +61 3 9214 6102 |
> http://www.swinburne.edu.au/design
>
> --
>
> References
>
> Beckman, Sara L., and Michael Barry. 2007. Innovation as a Learning
> Process:
> Embedding DesignThinking. California Management Review. Vol. 50, No. 1, pp.
> 25-56.
>
> Bogost, Ian. 2012. Alien Phenomenology or What It's Like to Be a Thing.
> Minneapolis: University Of Minnesota Press.
>
> Cross, Nigel. 2011. Design Thinking. Understanding How Designers Think and
> Work. London: Berg.
>
> Friedman, Ken. 2000. "Creating Design Knowledge: From Research into
> Practice." In IDATER 2000: International Conference on Design and
> Technology
> Educational Research and Development. P. H. Roberts and E. W. L. Norman,
> eds. Loughborough, UK: Department of Design and Technology, Loughborough
> University, 5-32. Also available in the original version at URL:
> http://hdl.handle.net/2134/1360
>
> Hersh, Reuben. 1999. What Is Mathematics, Really? Oxford: Oxford University
> Press.
>
> McGrath, Joseph, Joanne Martin, and Richard A Kulka. 1982. Judgment Calls
> in
> Research. (Studying Organizations. Innovations in Methodology 2). Thousand
> Oaks, California: Sage Publications.
>
> Peirce, C. S. 1992. The Essential Peirce. Selected Philosophical Writings.
> Vol. I (1867-1893). Edited by Nathan Houser and Christian Kloesel.
> Bloomington: Indiana University Press.
>
> Vickers, John. 2010. "The Problem of Induction." Stanford Encyclopedia of
> Philosophy. URL:
> http://plato.stanford.edu/entries/induction-problem/#ConNotInd<
> http://plato.
> stanford.edu/entries/induction-problem/%23ConNotInd>
>
> Weick, Karl. 1979. Social Psychology of Organizing. 2nd edition. Boston:
> Addison-Wesley.
>
>
>
>
> -----------------------------------------------------------------
> PhD-Design mailing list  <[log in to unmask]> Discussion of PhD
> studies and related research in Design Subscribe or Unsubscribe at
> https://www.jiscmail.ac.uk/phd-design
> -----------------------------------------------------------------
>
>
> -----------------------------------------------------------------
> PhD-Design mailing list  <[log in to unmask]>
> Discussion of PhD studies and related research in Design
> Subscribe or Unsubscribe at https://www.jiscmail.ac.uk/phd-design
> -----------------------------------------------------------------
>



--


-----------------------------------------------------------------
PhD-Design mailing list  <[log in to unmask]>
Discussion of PhD studies and related research in Design
Subscribe or Unsubscribe at https://www.jiscmail.ac.uk/phd-design
-----------------------------------------------------------------