Reflective practice, the framing and evaluation of a design challenge by working it through, rather than just thinking it through, points out that physical action and cognition are interconnected. Successful product designs result from a series of "conversations with materials." Here, the "conversations" are interactions between the designer and the design medium - sketching on paper, shaping clay, building with foam core (...). The epistemic production of concrete prototypes provides the crucial element of surprise, unexpected realizations that the designer could not have arrived at without producing a concrete manifestation of her ideas.
(...)
Our own fieldwork with design professionals underscores the centrality of thinking through prototyping. One architect estimated the number of tangible prototypes made for a building to be between 200 and 300 in his own practice. A design director stressed the importance of generating a wide range of different tangible and virtual prototypes. Because different styles and fidelities of artifacts yield different perspectives, externalizing ideas through a variety of prototypes affords a richer understanding of a design.
— How Bodies Matter: Five Themes for Interaction Design - Scott Klemmer, et al.
It is also now widely recognised that design problems are ill-defined, ill-structured, or "wicked". They are not the same as the "puzzles" that scientists, mathematicians and other scholars set themselves. They are not problems for which all the necessary information is, or ever can be, available to the problem-solver. They are therefore not susceptible to exhaustive analysis, and there can never be a guarantee that "correct" solutions can be found for them. In this context a solution-focused strategy is clearly preferable to a problem-focused one: it will always be possible to go on analysing "the problem", but the designer's task is to produce "the solution". It is only in terms of a conjectured solution that the problem can be contained within manageable bounds. What designers tend to do, therefore, is to seek, or impose a "primary generator" which both defines the limits of the problem and suggests the nature of its possible solution. In order to cope with ill-defined problems, designers have to learn to have the self-confidence to define, redefine and change the problem-as-given in the light of the solution that emerges from their minds and hands.
— Designerly Ways Of Knowing
Problem formulation and problem solution are mutually-recursive processes.
You need to go back and forth between trying to formulate the problem and trying to solve it. A "waterfall" approach, in which you take the formulation as set in stone and just try to solve it, is rarely effective.
— How To Think Real Good ↗
Activity (...) is an interaction of the actor (e.g., a human being) with the world. The interaction, according to activity theory terminology, is described as a process relating the subject (S) and the object (O). A common way to represent activity is "S <-> O". There are two key aspects differentiating activity from other types of interaction: (a) subjects of activities have needs, which should be met through an interaction with the world, and (b) activities and their subjects mutually determine one another; or, more generally, activities are generative forces that transform both subjects and objects.
(...) both the object and the subject are over time transformed by the activity. It is apparent, for instance, that a person's math skills are a result of previous experience: they have developed through solving math problems in the past. In other words, while it is true that a person's math abilities determine how the person solves math problems, it is also true that solving math problems determine the person's math abilities.
— Activity Theory, The Encyclopedia of Human-Computer Interaction ↗
S to O, but in both directions between S and O - the "material" ("object") also impacts the "doer" ("subject")Everyone who has written interactive software has experienced the same interplay. The programmer writes some code, runs it, and sees how it behaves and feels. The results are partially expected, partially surprising, and they feed into the next cycle of design. The ability to shape and reshape software requires a capacity for rapid prototyping - for turning an unarticulated idea into a working prototype quickly enough to be able to change it, to listen to it, even to throw it out and to go on to another. In this activity, the nature of the programming language and environment can make a large difference - perhaps as large as the difference between modeling in clay and sculpting in stone.
— Bringing Design To Software - Terry Winograd
875 words last tended to on 2024-02-21 — let me know what you think