Is There A Scientific Definition Of “Design”?
10 July 2013
An article recently posted by Fast Company discusses the two researcher’s quest to find the definition of “design”. Who gets to decide that? Is having a definition truly necessary for great design? What are your thoughts?
Is There A Scientific Definition Of “Design”?
What is design? What makes it distinct from art, science, or engineering? The editors of this site decide dozens of times a day what is or isn’t “design.” But is it ultimately subjective, or can it be rigorously defined? Charles Eames offered up a string of impishly oversimplified answers to this question in 1972. Now a pair of Canadian academics have taken the opposite approach: They’ve attempted to formulate analytically a rigorous definition of “the design concept.” Should we take it seriously?
Paul Ralph was preparing his Ph.D. dissertation on “the nature of software design” when his thesis adviser, Yair Wand, suggested that “clearly defining what we meant by design was a good way to begin,” Ralph tells Co.Design. “As an undergrad in computer science I became frustrated that none of the ‘design’ courses had anything to do with designing–for example, ‘algorithm design’ was the study of existing algorithms, not the study of generating new ones,” he says. “Designers in many disciplines, especially software development, suffer from common misconceptions about the nature of their work and exploring the meaning of design can help.”
Ralph and Wand’s paper is dense reading, but that’s just because they took a serious stab at puncturing common assumptions about what the practice of design is. An initial survey of academic literature showed that “design” could involve anything from optimizing processes and identifying requirements to creating artifacts and analyzing systems. After sifting and critiquing all of this fuzzy thinking, the authors settle on the following definition:
DESIGN: (noun) a specification of an object, manifested by some agent, intended to accomplish goals, in a particular environment, using a set of primitive components, satisfying a set of requirements, subject to some constraints.
That probably sounds like contentless B.S., but each chunk of that definition was carefully chosen to include certain things and exclude others. For example, take “specification of an object”: This means that the output of “design” is not necessarily a physical thing, although it can be; it is, however, always “a detailed description of an object in terms of its structure, namely the components used and their connections.” This almost gets to the very core of “design” itself: as an entity somehow distinct from the particular designed object yet tightly coupled to it. The design of the iMac is not an iMac, nor is it merely your iMac. And yet your iMac can’t exist without it.
The other concepts of “primitive components” (the basic physical materials or abstract elements that a design is constituted from) and “environment” (a design is always situated in a specific context) are also noteworthy. But are the edges of the definition truly sharp? Does fashion design, which often only has “goals” in the aesthetic sense, qualify? What about cooking? Does a chef “design” a new dish? Is a recipe a “design,” or something else? Rigorously defining “design” starts to seem like measuring a coastline: The “true” edge always recedes, infinitely, no matter what scale you try to measure it at.
And in the end, what good is it? “Designers do not need a clear definition of design to be effective, any more than mechanics need a clear definition of an engine,” Ralph admits. “I think the definition is more likely to be used by researchers studying design.” Which isn’t a bad or useless thing, any more than academic concepts in sociology and anthropology are.
Intriguingly, though, Ralph and Wand did intend their definition to be useful “in the real world” for software designers. “Developers are often expected to estimate the cost of developing a system, but their estimates are often inaccurate,” Ralph says. “The definition [of design] is useful to developers for explaining why they cannot provide accurate estimates, namely, the environment, goals, requirements, constraints, or primitives are not clear at the time the cost estimate is needed.” In other words, building software is not like building (or designing) bridges.
Ralph and Wand fully admit that their proposed definition is not, well, definitive. Is it a useful thought experiment? I think so, but I also happen to be reading a monograph on the epistemological, ontological, and phenomenological foundations of interaction design for pleasure. If you’re more of a hardheaded practitioner of the Design Is a Job stripe (which, by the way, is also an amazing book), this paper might make you roll your eyes harder than you’ve ever rolled them before. Or maybe you’re somewhere in the middle. In any case, defining design may be fundamentally quixotic–but if anyone should be able appreciate the intrinsic value of tilting at windmills, it’s a designer.