Bob van Vliet

Law and Order in the Studio, Part II

If a design presentation and critique is compared to a courtroom setting, then what roles do the design, designer, and design judges play?

Perhaps the design critique is a reverse trial. The design is ‘on trial’, but as something to be accepted rather than judged. The designer is the prosecutor, with the burden of evidence to establish beyond a reasonable doubt that the design has merit, or even that it is the best possible answer to th design brief. The critic (boss, client, teacher) plays to roles of defense council, judge, and jury. While the designer tries to make their case, they look for holes, weaknesses, and alternative explanations. When the case of the prosecutor (the designer) stands up, the design is judged as ‘good’, or ‘acceptable’.

It might be fun to separate these three functions in an educational setting. The teacher can be judge (only making sure everybody follows the rules and plays fair), an external critic can be the defense lawyer (doing their best to point out weaknesses and poke holes in the designer’s work), and other students can be the jury (rendering their verdict after hearing all the evidence).

What About the Logic of Design Proposals?

Next to a description of an artefact, plans for its production, and plans for its use, the product of a design project must always be a design proposal. There is the rare case where a design “speaks for itself”, but even in that instance, what that design says amounts to an argument that proposes the design’s actualization. And in arguing for a boss, client, or teacher, to make it like this, automatically means to not make it like that, or to leave the world as it is and keep making the same thing as before, or to make nothing new at all.

In practice, the goal and measure of success of such a proposal is that it persuades. In academic circles, we should instead be interested in whether the argument is any good in terms of its logic and evidentiary weight. Also in practice, however, those on the receiving end of a design proposal will want to judge how successfully the arguments offered actually justify a belief in the value of the design under consideration, and to poke through any rhetorical flourishes and salestalk that may be involved. In fact, I would argue that engineers –as opposed to those with sales and business titles– are under a moral obligation to strive for the same: an honest presentation of the merits of a design, accurate rather than merely giving the impression of accuracy. If “trust me, I’m an engineer” is to remain a valid request, we should strive to be trustworthy.

What is the logic of design proposals? What, exactly, are the claims that are made when designers present the results of their efforts? And how are and can these be justified?

Is the result of design always a proposal? Do designs published in academic journals fit this description?

At first glance, they don’t. Their message is more “Here is what we made. It’s really good/interesting/valuable/impressive.” But isn’t this the same as saying “This is how we should make these kinds of things for these kinds of situations.”? Or, “This is how we should solve this problem, or reach this goal.”?

A Valid Form of Justification by Process

The history of a design proposal is, in fact, sometimes a relevant argument for or against it. It can say something about the uncertainties (“unknown unknowns”) around the concept.

When an idea or design concept has been put through criticism, when it has been poked, prodded, changed back and forth, there has been a process of discovery. Were there any unexpected behaviours, properties, interactions, etcetera?

When we are presented with two proposals that seem comparable in terms of predicted performance, but one has only been drawn up yesterday and the other has been the subject of development for significantly longer, even when the final level of detail is similar, the ‘younger’ idea can be legitimately opposed simply on the basis that there might very well be something wrong with it while the other one can be accepted with less risk.

Definition and Demarcation

“What is design?” seems like an increasingly silly question to me. When people were asking “What is science?” and “What is not?” the impetus seems to have been quite different. They wanted to know how to construct reliable knowledge, who we should believe and who not, in effect. And consequently, who should receive special status and privilege and who shouldn’t. We don’t seem to have these problems in design.

First of all, “design” is such a broad field, spanning people pursuing such differing goals, that it almost moves to the same category of questions as “What is love?”. I mean, it’s an interesting question to ponder and perhaps to try and discuss philosophically, but it’s not going to be of practical consequence anytime soon.

What problem would answering the question “What is design?” solve? One answer might be that having a clear and correct answer would help us in the activity of designing. But whether science ‘works’ is a logical, fundamental question; whether a design method ‘works’ is a question of efficiency. When it comes to effectiveness, we do not have a problem. People are perfectly capable of designing things.

A Project on the Logic of Design

What I might do is to first, study how designs are justified and argued for, second, to analyse this logic of design, and third, to see what implications this might have for how we publish designs, present design proposals.

Designs always come with an argument. In professional practice, you almost always say “here is our design, and here’s why you should invest resources to produce it”. In academia, you say a subtly different thing, “here is our design, here’s what makes it new and unique, here’s what it’s good and bad at, why you might want to make something similar, etcetera”. It’s much less a proposal than a set of claims in academic work.

Come to think of it, I’d be curious what the answers would be if you simply asked engineering designers at universities the question “why do you publish your work?”, “Apart from being cited and adding to your list of publications, what would you like the effect of your publications to be?”, “What function does it serve to publish designs?”

Then again, do we really publish designs? Or is it that we publish about our designs? Yes, the basic principles and construction methods are usually described in a paper, but it’s far from the design information in patent applications, let alone from open source software.

Eerstejaars tunnelvisie

We moeten onze eerstejaars het niet kwalijk nemen dat ze kritiekloos recepten toepassen, of dat ze vragen naar dat recht-toe-recht-aan recept: hoe moet dit? Dat hoort bij de eerste stap op weg naar het ontwikkelen van een nieuwe expertise. Ze zijn novices.

Wij zouden het onderwijs zo kunnen inrichten dat we ze eerst een stel vuistregels leren die misschien niet de Waarheid zijn, maar die wel zinnig zullen blijven. En ze dan nét als ze die trucs een beetje onder de knie hebben opdrachten geven waarin ze er tegenaan lopen dat er uitzonderingen op de regel bestaan.

(n.a.v. Giuseppe’s ervaring met het projectgroepje die geen lager kon vinden voor de diameter 300mm basis van hun draaiende kraan)

Beste Eerstejaars,

Ontwerpen leer je niet door erover te lezen of door te luisteren naar iemand die het uitlegt. De enige manier om het onder de knie te krijgen is door het te doen. Waarom gaan we je dan toch vanalles vertellen?

Vergelijk het met het leren van een sport of het spelen van een instrument. Dat leer je ook vooral door het te doen. Dat kun je helemaal op eigen houtje proberen, maar je gaat veel sneller vooruit wanneer je je laat coachen of trainen. En daar moet je je een beetje aan overgeven. Regelmatig laat een trainer of coach je dingen doen waarvan je pas later gaat begrijpen waarom ze precies nuttig waren.

Ook wij gaan vrij gedetailleerd vertellen hoe het moet. En net als een sportcoach of muziekdocent verwachten wij dat je de oefeningen uitvoert zoals ze opgezet zijn, ook als dat tegen je eigen ideeën ingaat over wat nuttig en belangrijk is. Maar het is niet genoeg om die stappen hersenloos uit te voeren en te denken dat dit is hoe je het doet. Wij proberen een project zo vorm te geven dat je erdoor kunt leren ontwerpen. Om het ook echt te leren is het jouw verantwoordelijkheid om niet alleen de stappen en instructies zo goed mogelijk te volgen, maar ook om kritisch te blijven opletten op wat er tijdens het uitvoeren van de opdracht allemaal gebeurt, wat het effect van al die stappen en activiteiten is.

Justification in Design: Working Backwards

When are we convinced of a design proposal? When it looks like it will work, that it will work as well as it can, and that alternative designs are not expected to perform better.

When are we convinced that alternative designs would not perform better? When we compare these alternatives in a fair way and the proposed design comes out on top. For the comparison to be fair, it is necessary that the level of risk or uncertainty in developing the design proposal further is comparable for each concept, and thus that each concept is developed to a comparable level of materialisation and detail.

A comparison with alternatives is only persuasive when we judge the alternatives to be strong alternatives, the best available. How can we be convinced of this? When a thorough exploration of the possibilities shows that out of all possible alternatives, these are the most promising ones.

Reversing this, we get the standard approach for design projects:

a broad exploration of possibilities
selection of a small number of conceptually different alternatives for parallel further development
comparison of the developed concepts and selection of the strongest option
further development of this concept into an optimized final design

This is why a ‘good’ process is important in justifying a design.

How to argue that a proposed design works?

The ultimate evidence is, of course, to show the actual device working. But often it requires the (risky) expenditure of scarce resources to physically build a designed system. This means that a designer or design team must convince the gatekeeper for those resources (a manager or project lead, for instance) that the design that currently only exists on paper is likely to actually function and perfom as intended.

In a student project, the situation is slightly different. Here, it will be the students themselves that will build their design, not uncommonly at their own expense. So why do we still ask them to convince their teacher that going ahead is the right decision? In this situation, the risk is not the financial cost of a failed prototype but the lost time and opportunity in the course. Failure during a course will lead to less learning, more effort on the part of the teachers, and at worst a need to take the course again for the student.

So how does arguing for a design ‘on paper’ work? First of all, before we can get to whether the argument is convincing, for it to be sound, it needs to be clear what is being claimed. This means that it must be clearly stated what the intended function is, why it’s valuable or desirable, what the requirements and restrictions are, and also what performance criteria should be used to judge the design.

Here, we get to three necessary claims:

that it works (what does it do?)
that it works well (what does good performance look like?)
that it’s the best you can do (are there no obvious and better alternatives?)

The first two of these seem at first glance to be relatively straightforward. Quantitative modelling, physical reasoning, and calculating expected values for the product’s features and performance seems what’s called for. But how do you argue the third point? How do you convince people that the proposed means to fulfill some function are the right, appropriate, or even the best means?

In my experience the answer given to this question is often a variation on “good, structured design process”. I agree that a ‘good’ process is the means to produce this argument, but it isn’t itself the reason. A rigorous process leads to considered alternatives, and it is comparison to alternatives that provides the persuasive force to accept this particular design as the preferable one. In fact, this is the only way, it seems to me, to argue for the appropriateness of a certain design to attain a certain goal. It is easier to produce appropriate alternatives through a structured, disciplined design approach, but how the alternatives are generated does not matter in the final argument on which design to accept.

The question of concept selection is distinct from the question of optimization (the second question of the three above). A clear argument about what performance criteria the design was optimized for, and that it is indeed optimized for these, only supports the claim that a local optimum has been achieved in the design. It cannot support the claim that other local optima (the best versions of designs that are fundamentally conceptually different) aren’t even higher.

This leads to the burden of proof for alternative concepts: as a designer or design team, you need to convince me that each of your concepts has been optimized towards its maximum performance, that you’ve reached the peak of the local optimum. Only after this has been established, can the concept support the further claim that another concept –with a higher expected value or performance– is preferable. For this you also need to establish that none of your concepts’ expected performance is above their achievable level, for example because an unsolved problem still exists whose resolution would detract from the quality of the concept.

Underlying a (small) set of concepts that are established as embodiments of local optima in performance there needs to be a further argument: that the concepts that were developed into complete (if rough, or abstract) design proposals represent the most promising conceptual possiblities. This requires some overview or mapping of all possible conceptual approaches to the design problem.

This entire edifice of design justification needs to be clearly presented, understandable, and accessible to a judge of a design proposal. They need to be able to go through each part and decide whether they are convinced of each part.

Asking Why

Design teachers continually ask their students: why? This is frustrating for the student and in the end, ineffective. Daniel Dennet’s two versions of “why?” may help us think this through.

Students interpret this question, I think, as “how come?” In any case, that’s often how they answer it. They start telling us about all the steps in their process, the changes, developments, and other design moves they made that culminated (for the time being) in this particular feature.

The teacher, I think, is interested in “what for?” What is the value or function of this feature? What is the effect? But often, there probably is no intended effect. This is just the first shape that came to mind, or the dimension that fit without causing any explicit problems.

Come to think of it, the student may very well understand that the teacher is asking “why?” in the sense of “what for?”, but when they don’t have an answer, they just start describing their “how come” origins.

And, in fact, it doesn’t really matter whether there is an intended effect to answer the teacher’s “why” question. The answer might be, no reason — yet. Because that’s why “why?” is an interesting and potentially productive question: what might or could the effect of this feature, nut, bolt, angle, or dimension be?

A well considered design is exactly that: rigorously considered. This means that for every ‘independent variable’, for every feature under the designers control, and thus everything the designer is forced to make a choice about, it has been considered what the effect is, what effects could be produced by varying this variable, whether these are positive and could be further strengthened or whether these are negative and could be minimized or compensated for somehow.