Designing is not problem solving

Lots of people will agree with the statement "Designing is a kind of problem-solving."  But I disagree, especially in light of how we typically think of problems in everyday life.  Problems are human constructs - nature has no problems.  Psychologists may have a more sophisticated way of thinking about problem-solving, but, in my experience, most designers and the average "man on the street" are not up to their level.  In any case, my interest is in how designers treat problem-solving in their everyday activities.  In this post, I'll explain why I think that designing should definitely not be thought of as problem-solving.

Having watched design practitioners, instructors, and researchers for many years now, I've noticed that most of them think of problem-solving as a key element of designing.  However, as I have seen it practised, typical problem-solving is not a good representation of designing.  Two of my graduate students and I have worked out three characteristics of problem-solving in practise that highlight how different it is from designing.  These are what I think of as three myths of problem-solving.

Myth #1: Solutions end problems

We're raised to think that problems end when we solve them.  The homework we got in grade school consisted of questions to answer and problems to solve.  When the questions were answered and the problems were solved, the homework was over.  The problems no longer exist when we had the answers.  Undergraduate university education does little (at least in engineering) to change that mentality.  Once employed, we solve problems our Bosses give us.  Once we've satisfied Them, the problem-solving job is over and we move on to some other problem.  Consultants solve the problems of others and their contracts end when the problems are solved - implying that the problem is gone.  In our personal life, we have problems in our relationships, that once solved are gone forever, even if the solution is to end the relationship. If you have a problem with your car, you take it to the shop, they fix it, and the problem is gone.

I write this to emphasize that, in common usage, problems end once we solve them.

If designing is a kind of problem-solving, then we should expect design problems to vanish once an appropriate design is completed.  And from the practical point of view of individual practitioners in the daily activities, this can make sense: we design something for a client, then that job is over and we move to designing something else for someone else.

But does that really make sense?  What is a problem anyways?  It's nothing inherent in the universe - nature, after all, has no problems.  We invent problems; they're mental constructs that stand for something else.  A problem is the difference between what we want and what we've got.  We want to live comfortably, but our salary is too low; we want fuel efficient cars, but the cars we have aren't that efficient; we need the roots of an equation, but all we have is the equation; we want to look good, but we think we're too fat; we want to use software to increase our productivity, but bugs in the software that's available to us slow us down; we want all children to live relatively normal, healthy lives, but malaria and other diseases keep killing them.

A problem is, then, a conflict between opposing forces (at least) one of which is rooted in our wants.  This is what I wrote about in a previous post - the various forces that impact on how design is driven to occur.  So if a problem is an imbalance, then solving the problem means attaining balance.  But rather like reaching enlightenment, reaching balance is not easy - in fact, I would argue, we've never done it yet and quite possibly never will.  This is for three reasons.

First, our understanding of an imbalance is never perfect.  Our perceptions are by definition flawed, so no matter how hard we might try, we'll never truly understand a given imbalance (problem); it is therefore highly unlikely that any re-balancing (problem-solving) will permanently eliminate the imbalance entirely.

Second, our efforts to balance a situation bring about unintended changes in other forces that are influencing things, which will result in an unpredictable and new imbalance.  For instance, the automobile was introduced into one situation as a "solution" for certain problems.  While those problems are gone, the solution itself has created several new and serious problems.  Since the new problems are a direct result of an effort to re-balance a past problem, can we not say that the problem never really went away, but rather just changed into something else?  Indeed, isn't this an indication that the real problem was not addressed by the automobile at all, and that all it really did was treat a relatively superficial symptom?

Third, our wants keep changing in response to the situation.  This means that our efforts to balance a situation change the forces that we ourselves exert on the situation and to which our "solution" was a directed.  That change in our own wants changes the balance-point - introducing new imbalances.

Basically, we've got an open-loop feedback system here.  Not only do arbitrary and random effects change the forces affecting the degree of balance of a situation, but everything we do ourselves to improve balance changes the very forces we're trying to balance.  And "problems" never really end.

None of this sounds like the simple, static, open-and-shut cases of problem-solving of which lay folks (including designers) think, in my experience.

Myth #2: Problems stand still

It's a common misconception, based on the common practise of "freezing" requirements, that a problem becomes static once it has been specified.  If the problem is allowed to change, then the designers couldn't keep up with it.  Thus, in current practice and for practical reasons, requirements are typically frozen to give the designers a fixed target, as it were.

However, freezing the requirements doesn't freeze the problem on which they are based, because requirements are just a model of a design problem, and all models are by definition imperfect.  Indeed, a significant amount of "project management" in many large-scale design tasks (e.g. buildings, urban planning, commercial or military aircraft) arises directly from managing changes to requirements after they are supposed to be frozen, but that have become “stale” due to unforeseen external forces.  The requirements are just a snapshot of the problem at one point in time.  But since designers generally only work from the requirements, it is understandable that many of us have come to conflate the requirements with the problem they model.

Furthermore, since requirements are only imperfect models of design problems, they might contain errors that can only be corrected after the requirements are frozen.

If requirements remain frozen, the designers risk developing a wrong solution for what the problem will have become. This dilemma has been recognized, at least implicitly, by the drive toward shorter lead-times; the shorter the lead-time, the less likely the requirements are to have become stale.  However, as the rate of technological, social, political, and economic change continues to increase, it will become ever harder to develop designs fast enough. The fundamental matter here is not that design problems change, but that we treat them as if they were fixed.

Design problems are solved by generation several alternative solutions, then choosing the “best” alternative. The term “best” is a relative term, but is usually treated as an absolute.  That is, in problem-solving, there is a tacit assumption that it is possible to unequivocally identify the most appropriate solution.  In fact, “best” should be defined with respect to: the design alternatives known to the agents (a function of bounded rationality); the accuracy and completeness of the requirements (which should be allowed to change over time); the accuracy and completeness of the expected future context when the design solution will be implemented; and lots of other factors.  However, problem-solving as it is commonly practiced ignores effects one might anticipate in the future, usually because they cannot be quantified to the same degree as the requirements, which are essentially historical in nature. Without a willingness to consider the future effects of design solutions, and to build requirements that account for those effects to the best of our ability, the consequences of our design interventions cannot be controlled or mitigated at all. Yet, the conventional problem-solving framework provides no mechanisms for this.

Myth #3: Problems can be solved algorithmically

Many things that we call "problems" involve situations in which we can work out a solution algorithmically or heuristically. For instance, finding the roots of a quadratic equation is a typical “problem” that is “solved” by students. The prevalence of this algorithmic view of problem-solving implies that design problem-solving is similar, but this is not true: there are no mechanistic procedures where one need only "turn the crank" to produce the correct design.  Designs emerge through human interaction, over time, and via reflection and communication about the context. Preliminary design implementations and prototypes are very often used to elicit information from users and other stakeholders that further clarify the specifics of why the “as-is” situation is undesirable, and how a new design should address that situation. This reinforces the idea of coevolution of problem and solution, where the act of solving a design problem illuminates the problem itself.  Indeed, I would argue that designing is what you do when algorithms and heuristics fail - i.e. with so-called wicked problems. In any case, design appears to be non-algorithmic and non-heuristic, which places it at odds with the conventional notion of problem-solving.

QED

So there it is.  I've covered three specific problems with thinking about designing as problem-solving.  That is, when most people, including most designers, think about problem-solving in practise, they think of something that isn't compatible with designing.  Whether we are being naive about problem-solving is irrelevant.  We have these two concepts - which we call problem-solving and designing - and they just don't fit together.  So we need to stop thinking about designing as some kind of problem-solving.

I think that designing should be thought of as balancing, not problem solving.  I'll explain what I mean in future posts.