1

Design Thinking in IT Development? Tilmann Lindberg and Christoph Meinel

Hasso-Plattner-Institut an der Universität Potsdam PO-Box 900460, 14440 Potsdam, Germany

tilmann.lindberg@hpi.uni-potsdam.de, meinel@hpi.uni-potsdam.de

March 8, 2010

While information technology (IT) is regarded as one of the main current and future drivers of social and societal developments, the term IT design is mainly associated with purely technical issues, which is related to the predominant role of engineering expertise in IT development. However, whereas the engineers’ technical background bases fundamentally on a strong tradition in scientific-analytic thinking, many challenges of IT development require also expertise in design thinking, dealing with more ambiguous human-related aspects of a design problem. In this paper, we outline the differences between design thinking and the prevalent thinking in IT development, and discuss whether design thinking can solve essential problems IT development presently is faced with.

“Most outsiders see design as an applied art, as having to do with aesthetics, unlike a solid profession unto itself, with technical knowledge, skills, and responsibilities to rely on. Insiders to design, by contrast, talk of innovative ideas, coordinating the concerns of many disciplines, being advocates for users, and trying to balance social, political, cultural, and ecological considerations.”

Klaus Krippendorff (2006, 47) Introduction While the development of the IT industry is characterized through strong dynamics and rapid technological progress, users of software, hardware and networks nevertheless have difficulties in handling the complexity inherent to IT systems. We see this related to the patterns of problem solving predominant in IT development, which draw upon scientific-analytic thinking and emphasize rather the technical aspect of IT design than the social facets that are nevertheless decisive for the acceptance and adaptability of IT products. Design thinking, which is a problem solving approach that has been tried and tested with socially ambiguous problem settings, could not make an entrance to the IT industry apart from specialized disciplines such as interaction or user experience design. In

ISSN 2190-1562

Electronic Colloquium on Design Thinking Research, Report No. 1 (2010)

2

this paper, we ask for the reasons behind that and discuss essential benefits and difficulties of applying design thinking to IT development. Characteristics of Design in the IT-Industry Within the IT industry – comparable to any other industry dealing with technical products and services – the technical perspective plays a central role in problem solving and solution development. This seems to be necessary as the development process itself asks for highly trained IT-professionals who are able to deal with complex technical issues, such as programming languages or software and hardware architecture. Competencies in engineering-centered areas are generally not only a condition for participating in the IT development process, but also in the developing process of the actual design of the software product itself. Getting a comprehensive understanding of what the product – i.e. the IT-system – will look like, what solutions will work or not, and how the conditions of interaction between user and software can be shaped, generally presupposes the ability to communicate those questions in abstract and technical terms (cf. Eden et al 2006). This is due to the situation that there are inherent difficulties to model an IT-system in a generally understandable form – existing models are of pure mathematical nature – to enable non-specialists to communicate with IT-developers about functional or architectural questions. Every decision about the design of an IT-system unavoidably manifests at the level of architecture or code and, thus, cannot be solved without expert knowledge. Consequently, the educational background of hardware and software engineers has strong influence on mind-set building and decision-making and, as a result, IT development has the tendency to take place within an “exclusive” expert’s world. In past and present times, these circumstances lead to the fact that technically and analytically trained IT engineers take on the designer’s role as well, although they have not been professionally trained in that field. The word “software design” is, in fact, one of the few design terms that are almost exclusively associated with technical issues. Pursuing a dominant technical perspective in IT development however comes with its own set of problems. One basic problem, for instance, is that functionalities and user interfaces, albeit technically perfect, may shape up as incomprehensible or inappropriate from the user’s point of view. Other features considered as meaningful and essential from a user’s perspective may not be addressed. This problem, which is in these days e.g. approached by the research field of human-computer-interaction, can cause serious drawbacks: inefficiency and loss of effectiveness for the user, rejection of the product, and a loss of innovation prospects for the producer. Furthermore, those times in which the IT market grew mainly

3

driven by technology push dynamics became a thing of the past. From home entertainment to web 2.0 applications and ubiquitous computing, IT products deeply depend on social life dynamics, which are primarily not the concern of engineering but of design. Since IT solutions became more and more part of people’s everyday life, not only the demands on usefulness and usability have been growing continuously, but IT engineers must also learn to develop for highly competitive consumer markets, in which successful innovations are rather defined by the users point of view than by technical perfection. An isolated technical perspective thus leads to an innovation trap: while spending much effort in the development of technically novel or reasonable solutions, the clients do not really see the solution’s distinctive value.

Overall, the challenges that IT development is faced with exceed the established focus of an engineering expert’s world and ask for the integration of further perspectives on problem understanding and solution finding in IT development. This problem actually is the focal point of the present debate of applying design thinking to IT. While the thinking of IT engineers is mainly influenced by the rationalist approach as taught in mathematics and informatics – subsequent to the logic of having a given problem and deducing the right solution in accordance with rational rules of logic, design thinking, by contrast, teaches to treat problems more openly, with the purpose of embracing the blurred space of social ambiguity through which a successful design process should pass as well. Applying design thinking to IT development thus pursues the vision of setting up a complementary thinking style, which extends the problem solving abilities of IT development teams with the purpose of making their outcomes more user friendly and innovative. To understand what the origins of design thinking are and how they differ from modes of thinking in IT engineering, it may be useful to have a closer look on the nature of design problems.

The Wicked Nature of Design Problems Considering problems designers characteristically deal with, it seems obvious that they are very close to everyday life. What does a backache reducing office chair look like? What form should a computer interface have to be accessible for elderly people? What do we have to do to avoid injuries through battery acid in developing countries? The motivation to find answers to those questions is not to discover new technical possibilities (even if design professionals clearly takes advantage of both). Rather, it is the need to create ideas and find solutions (products, services, systems), which are both viable and novel for certain groups of users. By

4

that, design intends to offer a concrete solution to a complex problem that is socially ambiguous and hence neither easy nor certain to comprehend. Design problems thus – using a term by Horst Rittel (1972) – are close to wicked problems, blurred in character and not definitely definable (Bu-chanan 1995; Rowe 1987). People in design have intensively tackled the issue how to deal with such kinds of problems successfully, and have de-veloped an ambivalent relationship to the modes of thinking taught in the curricula of the established sciences. Primarily, solving wicked problems is neither in the focus of the inductive/deductive scheme pursued in em-pirical science that follows an epistemological logic to achieve knowledge about scientific truth (Dewey 1997), nor of the rationalist thinking ap-proach of mathematics, informatics and engineering. Rather, scientific problem solving follows a careful approach of analyzing and synthesizing – emphasizing the analytic investigation of a problem setting by decom-posing all its components or its determining factors as well as the use of this knowledge to deduce a design concept rationally. Rittel argues that scientific problem solving approaches would be inherently misleading as structuring a wicked problem in advance cannot be done without adding in constraints that however narrow down the range of possible solutions prior to the actual problem solving process. Constraints are for him “decisions of resignation" (Rittel 1972, 393), that tame a problem instead of tackling it, and limit both creative freedom and the prospect of finding concepts that adequately address the problem’s social complexity. Rittel’s position entails a design paradigm that basically relies on the assumption that de-sign problems are largely made up of exogenous perspectives that finally decide about the solution’s viability: the user’s, the client’s, the engineer’s, the manufacturer’s, the law-maker’s, etc. Thus dealing with the complexity of a design problem is rather a notion of negotiation between different and probably conflicting perspectives than deriving solutions rationally from a defined problem setting. In this paradigm, design is regarded as a “reflec-tive conversation with the situation” (Schön 1983), an activity of grasping multiple knowledge and multiple perspectives for inspiration and the knowledge’s creative transformation into new concepts (Cross 2007a; Dorst 2006; Krippendorff 2006; 2007). The corresponding problem solv-ing patterns are less clear-cut than those in the tradition of scientific prob-lem solving, building rather upon intuitive and heuristic reasoning than analytical and rational approaches. They have been discussed and re-searched with the term design thinking.

Characteristics of Design Thinking Research on as well as the application of design thinking has become prevalent over the last three decades, rooting in case study research by

5

Lawson (2006) and Cross (2007b) on how outstanding designers approach problems and develop solution concepts. It has evolved to a broad discourse on the exploration and analysis of cognitive strategies that carry the generation, synthesis and creative transformation of divergent know-ledge within design processes (Nagai & Noguchi 2003; Owen 2006; Papantonopoulos 2004). Moreover, those strategies have been reinterpreted as normative guidelines for design projects and creative prob-lem solving in general, thus they have been steadily moving beyond designers’ professional domains (Beckman & Barry 2007; Brown 2008; Drews 2009; Dunne & Martin 2006; Lindberg et al 2009; Martin 2009; Plattner 2009). To understand how design thinking strategies work, we suggest working with two fundamental pairs of terms: the problem and solution space on the one hand, and diverging and converging thinking on the other hand. Both distinctions help to differentiate design thinking from a positivist paradigm and thus from purely analytical approaches.

A concept of the problem space was first introduced by Newell et al (1967). As representatives of a scientific perspective, they locate the representation of possible solutions in the problem space itself without regarding a separate solution space, according to the logic once a problem is comprehensively stated, the optimal solution can be rationally derived. Design thinking however follows a dualistic approach that regards both the problem and the solution space as to be explored, whereas it is neither possible to fully understand the problem, nor to deduce rationally an “optimal” solution as for instance a typical engineering approach would imply (Dorst 2006; Lawson 2006). The exploration of the problem space aims at constructing subjective representations of the diverse perspectives that make up the space. Those representations however are not – according to scientific standards – “representative”; they rather serve as inspiration for an opening exploration of the solution space by working out ideas in parallel that match with the designer’s perception of the problem space. By turning ideas into tangible prototypes, communication about these ideas with the stakeholders is enabled, so that the designer’s perception of the problem space can be reviewed and renewed, and, as a result, a perceptive change of the solution space ensues as well. This is what Cross calls the “co-evolution of problem and solution” (Cross 2007b) in design thinking.

The distinction between diverging and converging thinking however shows how design thinking approaches the exploration of both spaces. Divergent thinking means dealing with a problem by discovering a broad range of its aspects – for instance the divergent perspectives constituting a design problem or the divergent possibilities that make up the solution space. Convergent thinking, conversely, brings together those divergent

6

aspects to comprehensive frameworks and concepts, for instance by synthesizing user observations to clear-cut point of views or by prioritizing ideas and elaborating design concepts (Buxton 2007; Guilford 1967; Rhea 2003). The scientific complement is inductive and deductive thinking: the representative condensation of partial and disordered observations to an abstract understanding of a situation (induction) and respectively the use of these statements to derive explanations or prognosis for a certain problem setting (deduction) (Dewey 1997). However, divergence is in both cases a starting point for scientific thinking and not a goal, it is always fundamentally convergent in character. It relies on both the possibility of taming a wicked situation by comprehensive analysis and the accuracy of rationally deduced utterances. Design thinking, conversely, aspires divergence instead of representativeness in order to develop a broad and yet concrete understanding about a situation, and it does not expect more (or less) from convergence as to summarize a certain state of knowledge or to capture and develop a certain idea or concept.

Fig. I Relations between Problem and Solution Space in Design Thinking

In consequence, design thinking is interplay between diverging exploration of problem and solution space and converging processes of synthesizing and selecting. Contrary to modes of thinking predominant in science, the knowledge processed in design thinking has to be neither representative nor entirely rationalized, rather it serves to obtain an exemplary but multi-perspective understanding in order to deal creatively with the ambiguity of design problems. All together, this interplay can be put down to three basic characteristics (see also Fig. I):

7

• Exploring the problem space: When exploring a problem space, design thinking acquires an intuitive, not fully verbalized, understanding, mainly by observing exemplary use cases or scenarios, as opposed to formulating general hypotheses or theories regarding the problem; and synthesize this knowledge to point of views.

• Exploring the solution space: When exploring the solution space, design thinking asks for a great number of alternative ideas in parallel and elaborates them with sketching and prototyping techniques. In this manner, ideas are being consciously transformed into tangible representatives.

• Iterative alignment of both spaces: These representatives of ideas and concepts facilitate communication not only in the design team, but with users, clients and experts as well. Thus, design thinking helps to keep in touch with the problem-relevant environment and can use this information for refining and revising the chosen solution path(s).

Discussion: Design Thinking in IT Development The basic problem which design thinking addresses is that there is not only no specialist alone knowing all that there is to know for a good design, but there is also no team of specialists that could bring in all the required knowledge. As this knowledge is spread over manifold stakeholders, and as designers can never be sure where to learn first and when to know enough, design thinking engenders an associative network of knowledge for creative ideating and a system of checks and balances to ensure that the conclusive solution will be both novel and viable for the social system that the design problem addresses. In contrast, the curricula of IT engineering basically teach scientific approaches to problem solving, which rely on the principle of specialists processing external information about a problem by means of internalized expert knowledge to clear-cut solutions. We regard both approaches of problem solving as significant to IT development. IT development is solving design problems with technical means, so that the perspectives “what design is viable” as well as “how to build up a functioning IT system” have to be intensively negotiated. This negotiation yet is hindered by difficulties to communicate between experts and non-experts throughout the development process. Non-experts are able to value software codes and hardware architecture in the form of tangible representations, such as initial concept drawings, prototypes and testable product versions. In particular the use of prototyping techniques facilitates

8

communication with non-experts during the development process, but is in IT development restricted. Functional prototypes are by and large only small extracts from the final product allowing feedback on certain functions but not on the “unbroken” user experience. And in particular in software development, mock-up prototypes are difficult to generate due to the complexity of dynamic user experiences. As a consequence, the communication of IT experts with their stakeholders is uncomplicated at the beginning when talking about general concepts and at the end of a development process when a testable product version is available. Throughout the process, however, IT developers are likely to be limited to interchange within their own community of experts.

A main consequence of this communication problem is that problem definition and solution development in IT engineering traditionally follow scientific problem solving approaches. Complex design problems tend to be systematically decomposed into sub-problems and then translated into technical specifications, so that specialists can tackle a problem for a distinct time period from a purely technical perspective. Yardsticks for the problem solving process are based on initially stated set target and not – as in design thinking – on revising and refining with stakeholder perspectives. Design problems, no matter how ambiguous they are, get initially structured, allowing diverse specialists to work on those set of problems they are trained for without questioning the overall problem definition.

Standard IT development approaches such as the waterfall model pursue this kind of logic very fundamentally. They are built upon linear process planning as known from milestone-based project management, and seek to build up knowledge about problem and solution very systematically, so that each step can build upon the outcome of the preceding ones (Davis et al 1988; Royce 1970). Knowledge processing is rather formalized via an in-depth documentation as a core completion criteria of each stage, not only with the purpose of recording knowledge for future maintenance and code changes, but also to advance knowledge in an explicit condition to the subsequent phases. Feedback loops that could support ongoing learning about the problem space are not excluded. Its effect, however, is very low due to rigid demands for documentation that slow down the feedback communication between the process phases. Cross-functional collabora-tion is organized following a strict principle of labor division, as there are mainly mono-disciplinary teams responsible for a certain set of problems. Diverse specialists therefore work on different problems with different mindsets. The user perspective is considered only at the edges of the process: either by means of analyzing user or market demands and translating them into specifications before the actual development process

9

starts, or by evaluating and testing the almost finished product by user feedbacks towards the end of the process.

In consequence, approaches like the waterfall model rely on administrating different internal and external perspectives; they negotiate them however only poorly. Further developments of the waterfall model pursue a more detailed view on software implementation in order to guarantee a better match between the initial specifications and the final system (V-model, see e.g. Sheffield 2005), or they integrate specific iteration phases that help to evaluate the progress continually throughout the process (Spiral model, see e.g. Boehm 1988). Yet, those concepts try to overcome the problems of the waterfall model by making the processes more complex and thus more difficult to handle. Rather they react to shortcomings in the design process with even more emphasis on administration than on negotiation. In contrast with agile development (in particular Scrum and Extreme Programming), a development approach emerged in which the problem definition is not a preceding step, but a parallel process to the actual development in order to sustain learning about the project and adaptability to unexpected events (Beck 2003; Pichler 2008). Instead of rigid milestone-based process roadmaps that the team has to follow, the process is driven by a set of obligatory rules and roles in which the team can act flexibly. Opposing to the waterfall logic, Agile has a strong focus on team collaboration and communication, for example by way of pair programming or all-embracing one-team approaches in which all disciplines involved in the development process (architects, developers, tester, documentation experts) pool their resources all the way through. Still, the central aspect of Agile is to break up the communication problem by keeping constantly in touch with users and other non-expert stakeholders. To do so, Agile depends on manifold intermediate solutions that serve to generate user feedbacks and become gradually improved in iterative development cycles. In the beginning, prototypes in agile development are small workable programs with a limited range of functionality, which become little by little developed until the final product is completed. In this fashion, IT developers address the wickedness of a design problem better, since they restrict themselves only to those activities that lead to testable program versions in short periods of time. This, however, causes an inbuilt tendency of agile development to avoid both divergent thinking and radical innovation. Every decision about an initial prototype limits down the range of possible later prototypes because they build upon each other. Agile is flexible towards decisions for incremental future improvements, but not to change a complete development path in retrospect. Thus, also the decision paths in agile are essentially convergent – the whole aspect of exploring problem and

10

solution space is limited down to the trial and error approach of iterative prototyping. This is why the focal goal of design thinking to put divergent options on the table will hardly be achieved.

The dilemma of a dominant engineering perspective in IT development has also been tackled by introducing new design specialists to IT development, such as user-interface, interaction, user-centered, or user experience designers. In general, those specialists are assumed to take on the role of the “user’s advocate” within the development team (Buxton 2007; Mandel 1997; Vredenburg et al 2002). The precise role of those specialists yet varies. For instance, in case of the user-interface design the role is clearly limited to what the software and hardware front-end actually should look and feel like. The role of user-centered design however is about both translating observable user needs into the software design and validating the software design through observable user feedbacks – as a kind of “coverage for user-friendliness” for the development team. Moreover, user experience design that tries to create the whole experience a product conveys is much more wide-ranging because it embraces the whole software design process from initial planning to rollout. By including those specialists in the development process, development teams get extended by members professionally trained in design thinking. Still, as they are new professional disciplines added to the established team setting, the question how deeply they influence the development process depends on which level they are integrated. For instance, tasks for user interface designers can be clearly stated and processed individually in the overall framework of the waterfall model. However, when user experience designers are expected to be fair to their own demands, they are reliant on stronger collaboration between IT designers and IT engineers and should also get and take one of the leading roles in the whole process.

Conclusion In retrospect, we can draw the conclusion that problem solving approaches in design as well as engineering complement each other in principle. Whereas design thinking allows dealing with the ambiguity of design problems as wicked problems, the thinking of IT engineers is mainly influenced by scientific-systematic approaches that support the effective technical realization. The inherent difficulties to communicate between experts and non-experts during the IT development process make the complementary use of both approaches complicated and lead to a dominance of analytic-systematic approaches to problem and solution finding. Resulting shortcoming of the design quality have been tackled for instance by agile development approaches that allow a continuous iteration with user feedback based on prototyping, while however accepting the

11

limitations of a fundamentally incremental development approach. Also, new IT design professions specialized on the user perspective become integrated into IT development, undertaking the role of an “user’s advocate”. Their effectiveness however depends on how influential on the overall process they are. Yet, despite agile approaches and new IT design professions, the differen-ces that make complementary use of design thinking and the thinking of IT engineers difficult are not overcome. They manifest for instance in the conflicting purposes of prototypes. Design thinking prototypes have the main purpose of supporting learning about the underlying product concept. This means that they can be very experimental and consist of any material that allows achieving information about the ideas behind the concept (and not so much about its technical specifications). Consequently they have to get handed over to the development phase and must still be translated into technical specifications and task definitions. In contrast, software proto-types are generally made of the same material as the final product, and are – in the case of Agile – continuously iterated into the final product. Hence, they focus less on learning about the general product idea but on finding a smooth way towards a final solution without running into the wrong direc-tion for too long. This is related to another difference, namely that the thinking of IT engineering is according to their scientific background deeply convergent.

In consequence, using both ways of problem solving complementary in IT development asks for more creative answers than just replacing one with the other. As design thinking helps to deal with wicked situations and IT engineers deal with structured ones, both approaches should be employed depending on what sort of problems one deals with. In particular in a team context, design thinking can take the role of a meta-disciplinary rational, which allows a team across the disciplines to develop a mutual under-standing of problem and solution, as it broadens disciplinary reasoning and helps for example engineers to forget about the patterns for a moment that they have internalized in their academic training – until a problem has been defined precisely enough so that professional rationales and expert knowledge may suitably be applied. This however would afford also a meta-education in the sense that one is able to look both horizontally on problems: going broad, looking for options, and being able to review the viable role of specialists within the development process; as well as vertically: bringing in the own disciplinary knowledge, solving aspects of the design problem which can be tackled through one’s own expertise.

12

References Beck, K.; Andres, C.: Extreme Programming Explained – Embrace Change. Amsterdam: Addison-Wesley Longman, 2004

Beckmann, S. L.; Barry, M.: Innovation as a Learning Process – Embedded Design Thinking. Californian Management Review 50(1) 25-56, Fall 2007

Brown, T.: Design Thinking. Harvard Business Review 84-92, June 2008

Boehm, B.W.: A Spiral Model of Software Development and Enhancement. IEEE Com-puter 21(5) 61-72, May 1988

Buchanan, R.: Wicked Problems in Design Thinking. In: Margolin, V.; Buchanan, R. (eds.): The Idea of Design. Cambridge (Mass.) and London: The MIT Press, 1995

Buxton, W.: Sketching User Experiences – Getting the Design Right and the Right Design. San Francisco: Morgan Kaufmann, 2007

Chalmers, A.F.: What is this thing called Science? Maidenhead and New York: Mcgraw-Hill, 1999

Cross, N.: From a Design Science to a Design Discipline: Understanding Desinerly Ways of Knowing and Thinking. In: Michel, R. (ed.): Design Research Now. Basel: Birkhäuser, 2007a

Cross, N.: Designerly Ways of Knowing. Basel: Birkhäuser, 2007b

Davis, A.M.; Bersoff, E.H.; Comer, E.R.: A Strategy for Comparing Alternative Software Development Life Cycle Models. IEEE Transactions On Software Engineering 14(10) 1453-1461, October 1988

Dewey, J.: How We Think. Mineola: Dover, 1997

Dorst, K.: Design Problems and Design Paradoxes. Design Issues 22(3) 4-17, Summer 2006

Drews, C.: Unleashing the Full Potential of Design Thinking as a Business Model. Design Management Review 20(3) 38-44, Summer 2009

Dunne, D.; Martin, R.: Design Thinking and How It Will Change Management Educa-tion: An Interview and Discussion. Academy of Management Learning & Education 5(4) 512-523, 2006

Eden, A.H.; Hirshfeld, Y.; Kazman, R.: Abstraction classes in software design. IEE Proc.-Softw. 153(4) 163-182, 2006

Guilford, J.P.: The Nature of Human Intelligence. Maidenhead and New York: Mcgraw-Hill, 1967

Krippendorff, K.: The Semantic Turn – a New Foundation for Design. Boca Raton: Routledge, 2006

Krippendorff, K.: Design Research, an Oxymoron?. Michel, R. (ed.): Design Research Now. Basel: Birkhäuser 67-80, 2007

Lawson, B.: How Designers Think. Oxford: Architectural Press, 2006

Lindberg,T.; Noweski, C.; Meinel, C.: Design Thinking: Zur Entwicklung eines explorativen Forschungsansatzes zu einem überprofessionellen Modell. Neuwerk, Zeitschrift für Designwissenschaft 1 Vol. 47-54, 2009

13

Mandel, T.: Elements of User Interface Design. Hoboken etc: John Wiley & Sons, 1997

Martin, R.: The Design of Business. Boston: Mcgraw-Hill, 2009

Nagai, Y.; Noguchi, I.: An experimental study on the design thinking process started from difficult keywords: modelling the thinking process of creative design. Journal of Engi-neering Design 14(4) 429-437, 2003

Newell, A; Shaw, J.C.; Simon, H.A.: The Process of Creative Thinking. In: Gruber, H.; Terrel, G.; Wertheimer, M. (eds): Contemporary Approaches to Creative Thinking. New York 63-119, 1967

Owen, C.: Design Thinking - Notes On Its Nature And Use. Design Research Quartlerly, 1:2 Dezember 16-27, 2006

Papantonopoulos, S: How system designers think: a study of design thinking in human factors engineering. Ergonomics 47(14) 1528-1548, 2004

Pichler, R.: Scrum – Agiles Projektmanagement erfolgreich einsetzen. Heidelberg: dpunkt.verlag, 2008

Plattner, H.; Meinel, C.; Weinberg, U.: Design Thinking. Munich: mi-wirtschaftsbuch, 2009

Sheffield, J.: Systematic knowledge and the V-model. International Journal of Business Information Systems 1(1/2) 83-101, 2005

Rhea, D.: Bringing Clarity in the Fuzzy Front End. In: Laurel, B. (ed): Design Research – Methods and Perspectives. Cambridge (Mass) 145-154, 2003

Rittel, H.W. J.: On the Planning Crisis - Systems Analysis of the First and Second Gen-eration. Bedrifsökonomen No. 8 390-396, 1972

Rowe, P.G.: Design Thinking. Cambridge (Mass.) and London: The MIT Press, 1987

Royce, W.: Managing the Development of Large Software Systems. Proc. of IEEE WESCON 26 328-338, 1970

Schön, D.A.: The Reflective Practitioner – How Professionals Think in Action. New York: Perseus Books, 1983

Vredenburg, K.; Isensee, S.; Righi, C.: User-Centered Design – An Integrated Approach. Upper Saddle River: Prentice Hall, 2002

ECDTR ISSN 2190-1562

http://ecdtr.hpi-web.de