On Design Report Structures and Different Kinds of Prototype Tests

When presenting the results of a design project, including a prototype test, I tend to recommend this chapter order:

  • Concepts and Selection
  • Final Design
  • Test / Validation

This order is based on typical peer reviewed papers presenting the ‘design and validation’ of ‘a novel device’ or something. It also assumes a substantial difference between the final design and the chosen concept that is not the direct outcome of exploratory testing with a prototype. This order works well when the test is aimed at validating a specific part of (the performance of) the design. The final design, in this set-up, functions as a type of hypothesis, that is then empirically tested.

In a course that I teach where students usually dive right into prototyping after concept selection, this order doesn’t always work. And it’s confusing for them. Especially for those students who end up effectively using (early versions of) their prototype as a sketch model to discover things about their concept and to iteratively develop their design. There is also little time available in this project (and too little technical knowledge amongst these particular students) to really develop the design as a whole very much after the concept selection.

In these cases, it would probably work better to change the order:

  • Concepts and Selection
  • Prototype test
  • Final design

You might even skip the ‘final design’ section entirely in favour of a discussion of future development. The prototype test, then, becomes not so much a focused validation of one key element within a larger complex design, but more an exploration and/or proof op principle of the chosen concept, more a validation of (the choice for) a certain solution principle than of a full design.

Design decisions are a set, not a series.

Design decisions are taken in the context of the design as a wole. That whole is subject to change throughout the design process. Therefore, logically speaking, all design decisions remain up for debate and themselves subject to change throughout the design process.

This is highly impractical, of course. In practice, therefore, important decisions are ‘frozen’ at some point during a design project. In practice, the reason for some decisions then becomes something like ‘because that follows from what we decided earlier’ or ‘it would cost too much to change’.

What makes for a good set of concepts?

First of all, what is the aim?

Here, I consider concepts as a means of exploration and – as a set – as the basis for arguing why the final design embodies/is based on the concept that is does/is.

What if we take the game SET as an analogy for how your concepts should differ.

When ONE aspect varies, you have something that looks like a controlled experiment. You’re changing one variable and seeing how that impacts the design’s properties and performance. Of course, when ‘one’ aspect is different, many more aspects will also be different. The world (and thus, physical artefacts) are infinitely complex.

When MORE THAN ONE aspect is varied, you either have to do the full combinatorics or find some way in which different choices in those aspects hang together (in effect, going back to the situation where only ONE overarching aspect is varied). Or, if there are no significant interaction effects between the aspects (sub-functions, domains, components) then it’s better to decouple them and decide per aspect which is preferable.

What of the case of the get-up-chair combined with two knee orthoses? What when you have A/X, A/Y, and B/Z? Could that make sense? Yes, I think so. In this case, there is a ‘wildcard’ concept. This could be a sound strategy in cases where there seems to be an obvious best option for one or a set of aspects (in this case: a powered knee orthosis). The function of the wildcard concept, then, is to check/justify that assumption. Trying to find the wildcard by asking ‘What do my two ideas have in common?’ can be a way to discover hidden or unconscious assumptions (and thus also, to find ‘more creative’ options). The emergency Covid ventilators also fall in this category, with only one departing from ‘modern, digital control system’.

(Examples from my slide deck of concept set examples)

Cost-Benefit Considerations in Design Arguments

In architecture, it may be perfectly acceptable to present predictions that are based purely on theoretical ideas about how people will behave and feel in response to a proposed building. Human behavior is so complex, and buildings so large, that such claims can be utterly impractical to test or otherwise validate. We have little choice but to trust the architect’s expertise, or accept an argument by analogy.

An engineer presenting a design for a novel surgical device, however, is expected to present a prototype that has been tested on simulated or even actual tissues, in addition to a theoretical model that predicts and explains its behavior. The physics of metal devices have been reliably modeled, and it is perfectly feasible to produce one-off prototypes and set up empirical experiments to validate these predictions with a reasonable investment of resources.

In design disicplines, we expect or do not expect certain types of evidence based on the possiblity and cost of supplying them. Engineering arguments are subject to cost/benefit considerations, similar to the designs themselves that the arguments are about.

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.

What Designers Know Depends on What They Want to Do

Designers’ knowledge is organized around typological models. But each discipline has their own way of modelling their subject. In fact, each discipline has a set of modelling languages in which they work.

Not only the kind of modelling is different, the breadth or level of abstraction is, too. Designers’ model knowledge serves not just to understand the world, but it is a tool for creating new artefacts and systems. So the way a designer models the world (relevant precedent) depends on their goal and professional context.

Continue reading What Designers Know Depends on What They Want to Do