design arguments

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.

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.

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.

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.

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.