What is Design?

What is Design?
A number of folks more erudite than I have approached this question from various angles, particularly as it applies to computers and software. From reading their books and articles as well as reflecting on my own experiences, I've come up with my own shorthand of what it is, and what it is not:

Let's start with what it isn't.

It isn't something that deals just with surfaces, with making things "look pretty" for the customers; it isn't slapping on a coat of paint, so to speak

It isn't something one adds on at the end of a product development cycle, to make something the engineers who constructed it think is already complete into something more appealing to the customers (often regarded, subconsciously or not, by the engineers as inferior to them in intelligence and facility); if one leaves user-concerned design until after construction, as Visual Basic creator Alan Cooper puts it in his book on software design (The Inmates are Running the Asylum), "...it's like a cement truck operator telling the carpenters they can build all the forms they want as soon as he is done pouring the concrete."

For many people, the word "design" itself brings to mind places like The Rhode Island School of Design (an art school), Parsons School of Design (fashion and interior design) or Harvard's Graduate School of Design (an architecture school).
It may also bring to mind industrial design or one of its sub-categories like car styling.
While these are sub-categories, they do not represent the full scope of the term. As it relates to software development, it's interesting to note that two of those design fields - art and fashion - tend to have a female connotation for many people. Since software development is a heavily male field, with more than a whiff of misogyny therein - see my e-pal Paulina Borsook's various writings on Silicon Valley culture, especially her book Cyberselfish" - this association with the feminine feeds their existing prejudice against any sort of design outside of code design, i.e. that it's trivial, non-essential, not involving hard science and empirical, testable phenomena, etc., and is an annoyance to be resisted.
In any case, "design" tends to be limited in its connotation for many people to some random selection of fields of application, depending on their particular random exposure to whichever areas of design, and to have fairly narrow associations, as well as sometimes negative ones.
That doesn't mean that it actually is only limited to a few specialized areas, or that interface design is a hopelessly subjective, "soft" area of interest as opposed to quantifiable, logical "hard" disciplines such as software code design, or as Cooper more accurately calls it, design for "implementation" or "function" (designing for optimal performance of the computer) as distinguished from "interaction design" (designing for optimal usefulness and usability by the humans who will use the software tool.) As he also says, "Many programmers believe themselves to be talented designers. In fact, this is often true, but there is a tremendous difference between designing for function and designing for humans."
So, rather than being something limited to a few specialties, and only qualifying as a "hard" discipline in certain subsets of those, design in its most inclusive and, I would suggest, most accurate sense is basically the process of thorough consideration and planning that should be involved whenever anyone makes something for other people to use; and, whatever the product being created might be, there are objective, empirical, "hard" methodologies that can be applied to its usability by human beings, to the creation of a successful "interaction" or "user experience", and not just to its internal construction. (And so, this gets us into what "design" is.)
The actual process of design is almost always a complex and multi-disciplinary endeavor, which can involve not just a practical knowledge of the field for which the tool is being designed (and this aspect is often overemphasized at the expense of other, at least equally crucial ones, actually, such as having a specific, archetypal client and his or her goals - goals, not tasks - in mind from the start of the process), but deeper areas like cognitive science and visual symbolism. (Re the latter: I once wrote a glowing review of the information-rich visual interface that the genius French programmer/musician/artist Eric Wenger created for his music app MetaSynth, stressing that he understands how humans are primarily visual creatures: the visual cortex is far larger than any of the other sensory processing areas of our brains. FYI, the copy of my review found at the link above was apparently lifted from its original [and still current] location at U & I Software.)(Eric was a neighbor of mine when I lived in San Francisco. He chain-smokes unfiltered Camels, so I'd always come back from his house smelling like I'd spent the day in a French cafe. A small price to pay for hanging out with a genius.)
The multi-disciplinary nature of software design precludes the possibility of the successful overall design being done by a single human being, as the mindsets behind the complementary skillsets required are mutually exclusive to a great degree.
In addition, even when a programmer understands the methods of interface design, and can switch mindsets from what Cooper calls the "literal-deterministic-sequential way that silicon behaves" to the "irrational-unpredictable-emotional world of humans", there still remains the problem of one's intimate familiarity with one's own product, accumulated in the process of constructing it, which cannot be reversed and so skews one's estimation of its usability. Thomas K. Landauer of Bell Labs' Cognitive Science research facility, in his book The Trouble with Computers: Usefulness, Usability and Productivity, relates how he used to illustrate this point to various engineers: He'd show them a blurry picture of something (it happened to be a cow), ask them what it was (it was nearly impossible to tell), then show them the same picture with outlines drawn around the cow, at which point they immediately recognized it. Then he'd switch back to the original fuzzy picture and tell them "now, try not to see the cow." As he put it, "one cannot go backwards by an act of will." (Even the interface work of rare polymath geniuses like Wenger and my namesake Kai [Krause], who, like Eric, is a programmer, musician and artist in equal measure, is still in some need of the essential objectivity and perspective of an independent interface design team.)
(Work in progress - more to come)
All content herein copyright © 1995-2002 by Kai Matthews, except where I've explicitly noted items as others' work.
This page was last generated on Friday, 26 July, 2002 01:13:18 PM (US Eastern Time), and was
and