The problem of identifying design with problem solving
By: Alberto Zamarrón
Tags: Problem Solving, Interaction Design, Design

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