Is There A Scientific Definition Of "Design"?

Saying definitively what design is (and isn’t) seems quixotic at best, but two academics took a solid shot at it. Did they succeed?

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.

[Read the paper here.]

Add New Comment


  • Nathan

    Ralph, if circuit designers, aerospace engineers, and urban planners aren't thinking about the people who would use these "artifacts," then the likelihood of them doing a good job is very low. This is how things have been made (more often than not) up until now and why many of the engineered things in our lives don't meet our needs well.

    The reason that Boeing fuselages are oval instead of a perfect circle and the 787 windows are larger is people. The reason that urban planners are taking away stop lights and stop signs in Europe (and not in the US) is people. And, the reason why Intel puts video clips of science fiction films into their chip specification documents is people.

    If these artifacts aren't serving people, who are they serving? And, if they aren't, than it's my bet that they're serving us poorly.

  • Paul Ralph

    Nathan, I didn't mean that circuit designer's, etc. *ignore* front end issues. I meant that they conceptualize design as being about both technical performance and aesthetics, whereas software designers often talk about design as if it's just aesthetics. Of course you are correct that urban planners, etc. think about aesthetics and users.

  • Nathan

    Design has become the care given to the "front-end" experience that people have (and that we want them to have) when they encounter a product, service, event, space, or policy. It differs from engineering in that engineering is the development of the "back-end" system to deliver that experience. It differs from art in that art's purpose is for an artist to express something about the world that he or she wants to communicate. Design, instead, isn't about our view of the world that we think everyone will love (though that is how most designers USED to be taught to design). Design has become our solution to others' needs (not our own).

    Science is the discovery of how the world works (including how people behave), which is why there are so many different types of science. Design overlaps with  (and design thinking gets several of its tools from) some social sciences when it comes to understanding those we design for (customers, audiences, participants, users, etc.).

  • Paul Ralph

    Conceptualizing design as a "front-end" issue is peculiar to software developers and some engineers. Circuit designers, urban planners, aerospace engineers do not think of it this way. Not all designed artifacts have human users.

  • Eric

    "In other words, building software is not like building (or designing) bridges."

    I hate this view of the world, and the coders that believe it. 

    Engineering (and design, in another sense) is about understanding what it is you're trying to accomplish, defining the bounds of the problem, and finding a solution or set of solutions that adequately address the problem within its bounds. Software "designers", for whatever reason, have seen fit to eschew the first part of that process, and then use their lack of rigor and process to claim there is some fundamental difference in software engineering that doesn't fit the traditional engineering mold. 

    That's hogwash. 

    As a litmus, look at software engineers (note the lack of quotes there) that work on embedded systems, realtime OSes, control software (like the software that runs a spacecraft, car, nuclear plant, industrial process), FPGA firmware, or that simulates some physical process. The problems are well-specified, the solutions are clear as they emerge, and there is no shifting of the problem statement to fit the solution they come up with. Code is direct, efficient, and elegant. There are fewer problems with dead code, because it's clear what is dead code. The difference - the software, which should allegedly have all the same fundamental characteristics that these weak-ass wannabe philosophers claim make software fundamentally different, is developed with a clearly defined end goal. A bridge  should span the gap it is intended to span and support an expected load for a defined design life; similarly, the software should perform the intended task within the specified limits, and with a measurable reliability. The coder, just like the structural engineer, has a set of piece parts and tools that she must evaluate for their suitability as solutions to the problem. For the coder, those tools are languages, platforms, and pre-defined code blocks, while for the structural engineer they are materials, catalog parts, and construction methods. 

    For some reason, the same basic engineering principles work for electrons, transistors, mechanics, materials, buildings, chemicals, and every other thing we construct, regardless of material and domain. Software "designers" aren't unique flowers in the world - they're just arrogant, lazy, and willfully ignorant when they try to claim that software transcends proven process and methods. 

  • cassette_walkman

    Classic engineering thinking. That's the noun, what about the verb: design. Can we simply alter the first 3 words of their definition? Change "a specification of an object..." to "to specify an object...".

    Design is not just specifying. Far from it, it's creating.

  • Paul Ralph

    In the paper, Design (verb) is defined as "to create a design (noun)". The idea was that in some fields, like architecture, design is about creating the plan for the artifact, while in others (like pottery) design is about creating the artifact itself. The "specification" could therefore be anything from blueprints to a prototype to an exemplar artifact.

  • Larry-miller

    That definition may work in an academic environment bereft of designers.

    But just as Einstein said that viewing a thing changes the thing, that definition also changes the nature of design: 

    It says by the ways it says it that design is cold, impersonal, bloodless, mechanical, linear, dehumanized, depersonalized, stultifying, and let's not forget, abstract. I always thought design was the practice of creativity. Challenging. Dynamic. Did I say challenging! Attention-getting. Risk-taking. Iconoclastic. Maybe even commercial. And at times, satisfying as well as rewarding to the designer. T&T added "beauty and mystery," which I applaud them for.

  • Casey

    This all reminds me of the book "Zen and the Art of Motorcycle Maintenance". Some concepts cannot be defined because to define them would betray the very nature of the concept.

  • Tracy & Tom Hazzard

    Too afraid of the verb design? Where is beauty & mystery? This is why everyone thinks they can design - but they can't and shouldn't.