When Is a Design Problem a Sequence of Decision Problems?
Are decision problems and design problems related? Is one part of the other? Or is the relationship different?
In a decision problem, there are, roughly speaking options and an objective, and the problem is to select the one option that best satisfies the objective. (There are other things in a decision problem, such as preferences and perceptions of uncertainty of outcomes, but those are not important below.)
In a design problem, there is an objective, but there are no options available to choose from; the problem is therefore to make one or more options available first, and then choose the one that best satisfies the objective.
(The above can be much more complicated. For example, the objective may be unclear, vague, and therefore, may change over time. I’ll return to this towards the end of this short text.)
If the cost of making more than a single option is high relative to available resources (or equivalently, if the resources invested in solving the problem should be minimized), then the design problem will be solved by starting from one option, really the only option, and iteratively improving it.
Instead of having A, B, and C to choose from, we make a D1, criticize, test it, break it, in general, subject it to feedback, and then change it into a D2, then after a second iteration into a D3, and so on, until resources are exhausted or the intended audience accepts that the problem is solved.
Observe that we cannot equate the design and decision problems, as described above: i.e., D1, D2, D3, and so on, the results of successive iterations are not options to choose from, in the same way that A, B, C are. We have A, B, and C to choose from at the same time in a decision problem, while in the design problem, we have D1 at a given time, then D2 at some later time, and so on.
Can we optimize when solving a decision problem? Certainly: if we have a set of shared properties over available options, preferences of decision-makers over values of these properties, we can rewrite the objective as a function to optimize, that is, a function which will result in a total order over options.
Can we optimize when solving a design problem? This is an interesting question, and the positive can be argued if the objective can be formulated as a function to optimize. For example, suppose that the problem is to design a thing that is described by many properties (color, size, weight, ability to perform some specific set of functions to some threshold criteria, etc.), but only two properties matter for decision-makers. Let’s call these properties P1 and P2. The first iteration of the design problem results in D1 such that when we test D1 for properties P1 and P2, it exhibits values P1 = x1 and P2 = y1. To make this tangible, let’s say P1 is color and P2 is weight, and x1 is pale green, and y1 is 100 kg. If our objective function says that we need less green and less weight, we will try to change D1 into D2 in the second iteration in such a way that we reduce its greenness and reduce its weight below 100 kg. And so on in each subsequent iteration. To the extent that in each iteration, we are considering changes which can result in different reductions in greenness and in weight, we are selecting the optimal incremental change between iterations, and so it doesn’t look odd to say that the design problem involves a sequence of decisions which are results of optimization.
But then, are there design problems which are not solved by optimization? This is also an interesting question. Suppose for example that instead of making an intentional change on D1 to produce D2, you can generate a bunch of variants of D1, which we denote D1.1, D1.2, D1.3, etc., any of which could become D2. In this case, you need a mechanism that picks one of these generated variants and says that exactly that variant D1.x is D2, and all others don’t matter. That mechanism can, but does not need to reflect optimization: if all variants are different in their greenness and weight, and we know the optimization function which minimizes, say, the product of a measure of greenness and weight, then the decision to pick, say, D1.3 and say that it is D2, will be based on D1.3 having the lowest combined greenness and weight. But, if we instead have a mechanism that picks a random variant among D1.1, D1.2, etc., then this isn’t optimization at all.
When, you might wonder, is it interesting to have a mechanism that selects randomly? Which conditions would need to dominate, to iterate that way?
The straightforward answer is this: if the relationship between properties of the thing being designed and the variable to optimize is known and well defined, then it seems a waste to randomly select from one iteration to the next. This was the case in my example: I said that the objective is to minimize the product of a measure of greenness and weight.
However, if the relationship between properties of the things generated through design and the objective to optimize is not well defined, then it is not obvious what exactly to change in order to make an improvement from one iteration to the next.
The latter case, when the objective function is not well defined, is frequent (maybe more frequent than the former case): a common example is the relationship between hard properties of a product and customer satisfaction. You can elongate a car model from one generation to the next, but do you know how exactly that contributes to the satisfaction of the people you assume constitute the addressable market for that vehicle? The very move to measuring customer loyalty the quick and dirty way using the Net Promoter Score (NPS), is a reflection of this problem. In general, relying on something like the NPS is an exercise in guessing what matters to the audience: they say they’ll promote a product, which is great, but why will they do this? That’s often the gazillion dollar question, and methods for estimating these relationships remain a recurring and likely unsolvable topic for thought and research.
The photo shows Alexander Calder’s Spider sculpture. It makes you wonder what he was optimizing for, when he was designing it.