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:
1. 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.
2. 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 (who are often regarded, subconsciously or not, by the engineers as inferior to them in intelligence and facility.)
3. 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.) (I’ve known graduates of all three of these. All three, by the way, have implicit in their names and philosophies a mercantilist, dare I say capitalist, raison d’être: the application for profit of these aspects of design; something not necessarily found in schools of fine arts, although the increasing corporatisation of universities – higher ed as mere trade school – may be encroaching there as well.) It may also bring to mind industrial design or one of its sub-categories like car styling. While these are categories of design, they fall far short of constituting and defining design as a whole.
As it relates to software development, it’s interesting to note that three of those design fields – art, fashion and interior design – tend to have a female (and/or gay) 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”, for many illustrations of this) this association with the feminine and/or gay feeds their existing prejudice against what they think is design, i.e., that it’s trivial, non-essential, not involving hard science and empirical, testable phenomena, etc., (“hard” sciences are, of course, male, on an emotional level, to many of their male practitioners) 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. That doesn’t mean that it’s only limited to a few specialized areas.
Quite the contrary – design in its most inclusive and, I would suggest, most accurate sense is simply the process of thorough consideration and planning that should be involved whenever anyone makes something for other people to use. (For my purposes henceforth, let’s call such a thing a tool, regardless of whether it is literally a tool; that is, something used to make or alter other things.)
Ah, yes! Sounds simple, even trite, doesn’t it?! But the actual process of design is an often complex and multi-disciplinary endeavour, which can involve not just a practical knowledge of the field for which the tool is being designed (and this aspect is often overemphasized, actually), but deeper areas like cognitive science, since even more important than understanding the task for which the tool is designed is understanding the users who will perform the task – which necessarily involves bridging the gap between the designer’s cognition and the user’s. In simple terms, it would seem to require putting oneself, as designer, into the shoes of the user.
But even this sympathetic stance often isn’t of much practical use, since it’s actually impossible in many, and probably most, cases for the designer to have the user’s viewpoint:
The designer has an intimate knowledge of the tool, accumulated gradually during its development, which the user, encountering it for the first time, cannot possibly possess at that moment of first encounter. As Bell Labs’ Thomas K. Landauer puts it in his book The Trouble with Computers: Usefulness, Usability and Productivity (1996), the designer cannot see the tool with “innocent eyes” (and the user cannot see it with the designer’s familiarity with it.) The designer can’t simply discard that familiarity in order to understand the user’s viewpoint:
As Landauer says, “The acquisition of a rich and intricate web of knowledge and skill is a one-way street; one can’t go backwards by an act of will.” (To illustrate this to other computer scientists, Landauer would show them a fuzzy picture, which was of a cow, which they almost always failed to identify. Then he’d show them the same picture with the cow outlined, whereupon of course they immediately saw it. Then he’d tell them, “Now, try not to see the cow”, and, of course, they couldn’t do that.) That is, no matter how sympathetic one is to the user’s situation (and the tech support acronym PICNIC – “problem in chair, not in computer” – while sometimes all too amusingly true, reflects in some small way the general lack of sympathy for users among the creators of technology), one is still not going to be able to see things from the user’s point of view. Thus, things which seem clear subjectively to the designer may be anything but to the user, and the designer has no easy way to be aware of the opacities the user encounters.
Thus, other methods must be developed in order to bridge the gap between the designer’s viewpoint and the user’s. This necessarily involves sciences of human nature – particularly of cognition – far more than it involves sciences of production, physical structure or computation.
This is where the science, if there can be said to be such at this point, of usability begins. (As Landauer’s book title implies, usefulness is a separate thing. Something can be quite useful – that is, many things potentially can be done with it – while yet being so unusable – so difficult to figure out how to use – that its usefulness is undermined. Any new user of Microsoft Word can attest to this; and the thickness of a user’s manual for any particular tool correlates to a large degree to the number of its deficiencies in usability.) There cannot be an effective discipline of design without a significant degree of attention to the science(s) of usability.
Since usability involves a phenomenological gap (to use a philosophical term) between these two kinds of subjects, designer and user, and design must involve usability to be fully effective, design is a matter for philosophers (of mind, at the very least), neuroscientists and psychologists as least as much as it is a matter for the “hard” sciences we usually associate with computational devices, industrial design & manufacture, and the rest of modern technological tooldom.
(This is still a work in progress; it dates originally from a period in which, motivated by my experiences at a Web tools start-up and later doing tech support, I was following bio-biographic trails through works on software design, architecture and design in general, on to books and articles on cog sci and linguistics, notably Lakoff and Johnson’s work, and ultimately into philosophy.)