The problem of identifying design with problem solving

Many designers of all disciplines, some of them renowned names, keep in their speech the statement “design is problem solving” with the good intention of giving design a supposedly lost image of functionality and rigor.

I understand the use of “… is problem solving” as a metaphor, as an attempt to distance design from the ornamental and whimsical. I can also understand it as an attempt to elucidate what we can contribute to a project, not only to decorate the cake, but also dedicating our efforts to noble causes, wich could be as important as “problem solving”. The statement resembles a softer version of the typical “improving people´s lives”.
This simplification might be useful in some situations, as the definition of problem can be roughly applied to almost anything. However, I believe this definition is lacking precision, wich leds me to reflect about it.

This expression is repeated as a slogan here and there, but very rarely the concepts of problem and solution are fully explained. At best, the term is accompanied by an explanation of its intended meaning: design detached from art, fully functional or everything has a purpose. That’s fine, it’s just explaining what design is, but there is a mismatch between expression and explanation.

If a client or stakeholder is as inexperienced to not understand that design is not the same as styling, alluding to “it´s problem-solving” without further explanation may only increase confusion.

It seems that this speech implies an inferiority complex, a mediocre solution to an alleged problem as old and tiresome as design itself: being seeing as stylists.

Leaving styling behind

Some designers, maybe as a reaction, seem to want to transcend the aesthetic design aspect, even avoiding bringing it to the table. Among them we could include some who produce beautiful work. To speak about beauty has become uncomfortable. It could become a time-consuming argument and deflect attention from core design tasks.
I admit that sometimes I have avoided this issue when dealing with a customer.

Others place design work focused purely on function, efficiency and measurable results at a higher level. White background and blue links on digital products, flat aluminium sheets and visible screws in physical products. A seasoned designer would know that sometimes it doesn´t make sense to spend resources on a delightful look and feel, would deliver valuable products with a naked design approach, very appropriate in some cases, but not all.
It is also true taht sometimes I’ve felt very proud having met client´s expectations with this kind of design.

Maybe we are taking the idea that “beauty is the result of right” to the extreme (a Japanese proverb quoted by Bruno Munari in “How do objects are born”). It could be interpreted that when everything makes sense and works, it is automatically beautiful.

Obviously, to solve problems and achieve beauty are not incompatible activities, so, why is problem solving not the best way to explain our work?

First, we should know what we are calling a problem: a perceived gap between what we have and what we want, a situation we want to change.

Common local problems

When working on the design of a product, what I usually consider problems are issues or barriers to overcome so the product will reach its goals, rather than the client’s briefing. It´s the mentioned distance between the state we have and the state we want, where the state we want is the design brought to reality and working perfectly. They could be named as local problems in contrast to the global problem stated in the briefing.

Those local problems are something to overcome, but not enough to complete a great job, they are at the base of the pyramid. I’m talking about a non obvious joint between parts, a shape which increases manufacturing cost, slow queries to a database, too much information on one screen, a brand without enough contrasts on a particular background.

They are well-defined problems, if we find one solution, it can be enough. In this case, designers and engineers can use a process of analysis and subsequent synthesis.

The approach of dealing with such problems is engineerish, assuming that the problem can be well defined, broke down to address each cause and a solution that can be true or false can be built.

With this approach I don’t want to undervalue or detach engineering and design, quite the contrary, but just highlight differences between both approaches and how they complement each other.

Engineering vs. design (Design paradigms. Peter Ljungstrand)

Engineering approach

• Define problem
• Look for best solution
• Assumes problem can be well-define
• Divide-and-conquer
• Based on analytical and mathematical skills
• Solution is true or false

Design approach

• Wicked problems
• Try to understand the situation
• Explore possibilities to better understand the problem
• Iterative work
• Sketching
• Solution is good or bad, better or worse

In many cases, this kind of problems are based on a contradiction and accept an algorithmic and heuristic solving strategy (principles, rules and strategies).

A well known method in engineering, TRIZ, is based on solving technical contradictions (partially or completely). TRIZ is the Russian acronym for Theory of Inventive Problem Solving, developed by the inventor, engineer, scientist and writer Genrich Altschuller. Of course, he was deported to Siberia. Altschuller studied over 400,000 patents and concluded that most of them are based on 40 principles of invention. He developed a methodology to “replicate the creative process of inventors”.

I´ve tried to apply this method sometimes, designing physical products, when stuck with a technical problem. The first issue was to clearly define the contradiction, which isn´t usually easy. The second issue was to isolate the contradiction, to avoid that if a characteristic is modified, others would get worse.

The next step after trying to do something systematic (as TRIZ) is to automate it. In 1959 Herbert A. Simon, J. C. Shaw and Allen Newell created a software called General Problem Solver (GPS) with the aim of achieving a universal system to solve problems. Not bad.

Specificities of design problems

To ask a designer to solve a problem we should set it: “This is the problem to be solved”. It is still common to set fixed requirements to get a specific goal, but freezing conditions does not freeze the problem on which they are based. The requirements are only a model (among many) of the problem.

In design it is usual to run into non-completely defined problems, even some that are not articulated yet. A product that creates frustration when used, makes a problem visible, it may or may not be well defined, but sometimes what the designer has to look for are opportunities from still unexpressed needs. Indeed, these cases are those where a designer puts her skills really into play.

It could be said that to reveal problems is characteristic of design: to redefine problems and work with so-called wicked problems (those difficult or impossible to solve since they present incomplete, contradictory and/or changing requirements that are generally difficult to recognize).

It’s a field where the problem is defined as it’s solved (idea of coevolution of problem and solution).

It’s often not easy to represent the differences between the current state and the future desired state. The desired state may not have been specified yet or presented in a incomplete or provisional way. It’s also possible to have trouble comparing these states because of differences in the form and level of representation between what we have and what we want. We cannot presuppose that there is something like a set design problem at any point in the design process. (Kees Dorst, 2006, Design Problems and Design Paradoxes)

Solutions generated along the process are not unique and do not imply the problem ends. They’re good or bad, better or worse, not true or false. The end is rather a point of sufficiently satisfactory balance.

Simon and Papanek considered design mainly a problem-solving activity, even so:

“Design is a Satisfying Activity. Making decisions without complete information by accepting good enough solutions rather than optimising and calculating the optimum one, is a distinctive characteristic of design.” (Herbert A. Simon, The Sciences of the Artificial)

“Because design as a problem-solving activity can never, by definition, yield one right answer: it will always produce an infinite number of answers, some “righter” and some “wronger.” The “rightness” of any design solution will depend on the meaning and which we invest the arrangement.” Victor Papanek

How a designer solves problems

In The Sciences of the Artificial, Herbert A. Simon lays out design as a problem solving activity, but in which much of the effort is devoted to structure these problems and only a part to solve them.

This is a traditional conception of systematic problem decomposition, where design is considered nothing special compared to other problem-solving activities. (Willemien Visser, 2007, Designing as Construction of Representations) Thus, there is an analysis stage first, followed by a synthesis stage in which the solution is built. The problem is considered as something given to the designer.

However, empirical studies have shown that designers don´t break down the problem systematically and that the same problem can be decomposed in different ways depending on the designer’s experience. (Willemien Visser, 2007, Designing as Construction of Representations) Moreover, the effort to structure the problem takes place throughout the design process, not just at the beginning. Problem and solution evolve simultaneously, the design problem is solved to understand it.

It seems that the characteristic way a designer solves problems is not much like what is commonly understood as problem solving.

What problem does a designer solve when working on a wristwatch, a chair or new car model?

It seems that there are many solutions to the core problems (to know what time it is, sitting, mobility). Perhaps the problem is how to find a place in a competitive market, be desirable for the consumer, differentiating or return the prestige to a brand. in any case, problems for clients of design services, not for users.

Design involves problem solving, in the same way that it implies its construction or redefinition from the partial information available.

As Armand Hatchuel argued, design includes problem solving, but it cannot be reduced to problem solving. To reduce design to problem solving is bound to miss important aspects of the design activity.

Designing is rather to find a balance between all constraints and information generated during the design process.