June 04, 2004

Toothpicks, logos and definition of design

I just finished reading John Heskett's Toothpicks & Logos: Design in Everyday Life. It's an interesting counterpart to Bill Stumpf's The Ice Palace That Melted Away: How Good Design Enhances Our Lives and Virginia Posterel's The Substance of Style (which I discuss here). All three books create a case for the importance of design.

Stumpf, one of the designers of the Aeron, writes an intimate personal description--almost an autobiography--of how design has shaped his world and why he thinks it's a crucial part of civil life, though his reasons are primarily personal. In that respect, it's an insider's book for insiders. Postrel, an outsider, states that design is important because people find it important and that it should not be ignored for that reason. Hers is an outsider's book for outsiders. Heskett takes the middle track between the two. He's an insider to the field, but his book is for people outside it. It's positioned as an explanation of why design makes a difference not in terms of how it fits into a vision of proper living, but how its effects are felt throughout society.

Starting with an acknowledgment that a definition is hard to pin down and nebulous:

As a word it is common enough, but it is full of incongruities, has innumerable manifestation, and lacks boundaries that give clarity and definition. As a practice, design generates vast quantities of material, much of it ephemeral, only a small proportion of which has enduring quality.

He then goes on to present a history of design, and attempts to define the practice by examining the typical places where design is found: objects, communication, environments and identities. He then uses each of these headings to examine more subtle aspects of design. So, for example, when talking about objects, he describes the different kinds of industrial design practices (individual versus group, internal versus external, etc.).

An interesting point he makes early on is that design is more of a work practice than a set of defined tools:

Most practical disciplines, such as architecture and engineering, have a body of basic knowledge and theory about what the practice is and does that can serve as a platform, a starting point, for any student or interested layman. The absence of a similar basis in design is one of the greatest problems it faces.

This really reminds me of the talk Bonnie John gave at IBM's NPUC conference last year. In the talk she discussed that HCI--which is clearly becoming a design discipline, or the two are merging--is pretty low on the Capability Maturity Model scale:

LevelFocusKey Process Areas
. Acquisition Innovation Management
. Continuous Process Improvement
. Quantitative Acquisition Management
. Quantitative Process Management
. Training Program
. Acquisition Risk Management
. Contract Performance Management
. Project Performance Management
. User Requirements
. Process Definition and Maintenance
. Transition to Support
. Evaluation
. Contract Tracking and Oversight
. Project Management
. Requirements Development and Mgt
. Solicitation
. Software Acquisition Planning
Competent people and heroics

(table borrowed from here)

John's comment was that HCI needed to be more like other engineering disciplines, that there's a lack of rigor, consistency and standardization in the field. This also seems to be bothering Heskett, at least in terms of how it makes it harder to legitimize the field. Frankly, I think that the field isn't ready for it. Before design can become engineered, the basic building blocks need to stabilize. With much of the engineered world, the one that John and Heskett want design to be like, history allowed a relatively limited number materials (wood, stone, brick, iron) to dominate for long enough that the basic properties could be explored and processes defined in fairly predictable ways. If you consider modern materials (for my purposes here, consider information to be a material), their properties are barely explored from an engineering standpoint compared to the old ones. At the Metropolis design conference in New York there was a lecturer talking about carbon fiber. Carbon fiber seems to be an old "new material" but the lecturer was complaining that designers still don't know how to use it correctly.

So maybe design isn't a discipline at all, and all of the attempts to pin it down are doomed to fail. Maybe design is a stage in the evolution of our understanding of a material and how to manipulate it on the way to engineering from art and pure science?

OK, that's pretty far out, I admit, but I think there's some truth to it, since at least one aspect of design--the use of materials--is clearly on a continuum between pure science and engineering (again, I'm treating information--and humans reactions to it--as a kind of material, though I realize it's not exactly like, say, paint).

However, as we know, design isn't just a functional discipline. It's an amalgam of function and form. Don Norman recently discovered this for himself and wrote a good book about it, though it's been there all along. The problem this amalgamated state introduces is that people, unlike materials, don't behave in linear ways. People are driven by power laws and habituation (at some point I'll write about these two books, which although quite different almost certainly describe related phenomena that are at the core of human behavior). In other words, we have a really hard time comprehending more than a handful of things, and we get bored, which is not how materials behave. So when Heskett criticizes Starck's ridiculous juicer, it rings strangely angry:

To have this item of fashionable taste adorn a kitchen, however, costs some twenty times that of a simple and infinitely more efficient squeezer--in fact, the term 'squeezer' should perhaps be more appropriately applied to profit leverage, rather than functionality for users.

OK, whatever. Clearly people are buying it for some reason that's unrelated to how well it makes juice that they could be buying in a carton, anyway. As Postrel argues, the success of design is ultimately dependent on human perceptions and its definition needs to have that at its core.

That said, much of Heskett's book is a very good description of how design actually happens, and he's not afraid to editorialize about problems he sees, such as this comment on the cult of design stars:

The emphasis on individuality is therefore problematic--rather than actually designing, many successful designer 'personalities' function more as creative managers.

He finishes the book with two chapters, one entitled "Systems" and one "Contexts," in which he tries to pull back and explain what it all means. "Systems" describes how designs don't, and shouldn't, function in a vacuum, but it ends with a curious note of resignation for design's ability to change the world:

If we can understand the nature of systems in terms of how changes in one part have consequences throughout the whole, and how that whole can effect [sic] other overlapping systems, there is the possibility at least of reducing some of the more obvious harmful effects. Design could be part of the solution, if appropriate strategies and methodologies were mandated by clients, publics, and governments to address the problems in a fundamental manner. Sadly, one must doubt the ability of economic systems, based on a conviction that the common good is defined by an amalgam of decisions based on individual self-interest, to address these implications of the human capacity to transform our environment. Design, in this sense, is part of the problem.

I disagree. Design is neutral, it can neither harm nor help by itself. It is the grease that makes tools work better and to be more satisfying. But both artificial hearts and guns have lubricants, and designing a better lubricant is neither better nor worse for the world. To think that the practice should have a morality is asking too much of it. In the end, we can only hope that all of the design of the world and all of the organizations supporting it (as he describes so well in the "Contexts" chapter) will make more of people's products and lives better than it will make them worse.

Posted by mikek at June 4, 2004 06:05 PM | TrackBack

Karl Nelson (see trackbacks) correctly points out that my link is to the Software Acquisition Capability Maturity Model, rather than more general Capability Maturity Model. I was pointing to the page where I got the table, so now I've fixed the links. Thanks, Karl!

Posted by: Mike at June 8, 2004 11:51 AM
Post a comment

Remember personal info?