The theme of the book now becomes clearer. Design is the conscious modification of the human environment. As with all selfconscious change, there will be benefits—both projected and fortuitous—and deficiencies—both expected and unanticipated. In the modern world, change is unavoidable; thus, if we are to enter into a new era of design, we should seek methods and tools that maximize the benefits as they minimize the deficiencies. Of course, in the real world of systems there will be neither maxima nor minima. Here we can only measure qualitatively, not quantitatively. Consequently, we must rely on collective judgments and accept that any reference points will become obscured by the dynamics of change. Thus, few of our problems will be amenable to a static, rational solution; most will be soft, open, wicked, and, of course, context and domain specific. This final chapter of Part II explores design in-the-world with particular emphasis on how it affects, and is affected by, the stakeholders. I use the title “Participatory Design” to distinguish this orientation from the historical approach to product development—what I have called “technological design.” In technological design, we assume that an object is to be created and, moreover, that the essential description of that object exists in a specification. The design and fabrication activities, therefore, are directed to realizing the specification. How well the specified object fits into the real world is secondary to the design process; the primary criterion for success is the fidelity of the finished product with respect to its specification. we have seen from the previous chapter, however, that this abstract model of technological design seldom exists in practice. Even in architecture, where a building must conform to its drawings, we find excellence associated with flexibility and accommodation. Thus, in reality, technological and participatory design are complementary projections of a single process. Although I will emphasize computer-based information systems in this chapter, I open the discussion with an examination of a typical hardware-oriented system.
Using Reference Domain Ontologies to Define the Real-World Semantics of Domain-Specific Languages