Motto: “A problem well put is half solved.” (John Dewey, The Pattern of Inquiry)

Type: A pattern of dynamics between Design Situations and Design Outcomes

Definition: A design situation is viewed as a clearly defined and static problem (i.e., a problem that can be clearly stated and where it is known what form the solution should have). A design outcome is seen as a solution for this problem. Design is viewed as a problem-solving activity.

Topics: problem-solving, the puzzle trap, education, well-scoped design sub-tasks, test-driven development

Desirable: In education, as well as in a limited number of practical cases for well-scoped design sub-tasks.

Undesirable: In most real-world situations, because few design problems are fully understood before the start of design activity.


The puzzle solving patterns views design as a problem-solving activity, an activity that leads to a solution for a precisely defined existing problem.

This pattern is of limited use in design practice because very few of design problems are fully understood before a design activity starts (see Section Co-Evolution of Problem-Solution). Lawson even called such view on design “the puzzle trap” (Lawson 2005, page 221). Norman (2010) similarly explained that interactions design is sometimes naively viewed as a problem-solving activity. In such naïve view, interaction designers are capturing and understanding the hidden unmet needs of potential users/customers. The intention of designers is then to design an outcome that fulfills those requirements. Norman noted that this view, however, does not reflect the everyday practice of interaction designers.

The puzzle solving pattern has its value in a limited number of practical cases. A designer can approach some of the design sub-tasks as problem-solving activities. Design of computing algorithms, for example, can be viewed as an occurrence of the puzzle solving pattern. Here, the goal is to find an efficient algorithmic solution for a precisely defined computing problem1. In software design, test-driven development (TDD) promotes an approach to designing and programming of software systems through series of mini problem-solving activities. In a TDD approach, a developer should write every line of new code in response to a test the developer writes just before coding (Melnik & Jeffries 2007). Creating such tests may be seen as an attempt to define a problem (problem setting). And writing new code may be seen as an attempt to find and implement a solution that is good enough to pass the test.

Teachers can also use the puzzle solving pattern in education, where problems can be artificially clearly defined so that students can focus on developing a particular design technique. For example, it is a common practice to teach computer programming through exercises where students need to design an algorithm for an explicitly defined problem (such as calculating the number of days between two dates). Similarly, Bill Buxton (2007) promoted an approach to interaction design education based on copying the classics, drawing a parallel with the traditional art education. In traditional art education, drawing antiquities (a clearly defined problem), is often used to lay the foundation for building up the student’s skills. In such exercises, students are not overwhelmed by trying to deal with issues such as thinking about an appropriate subject or composition (problem setting). Instead, they can focus on learning how to master the pencil, a prerequisite to high art.

The puzzle solving pattern may be present within the co-evolution of problem-solution pattern, as a way to find answers to specific well-scoped questions.

Questions to Ask Yourself

  • In your design activities, do you have lots of well-defined design sub-tasks, such as algorithm implementation?
  • Do you use a problem-solving approach for skills development in education and training?
  • Have you ever attempted to solve a problem only to realize that the problem is not well defined?
  • Have you ever successfully “solved” the wrong problem?
  • Have you ever created an unnecessarily complicated solution because you had not well understood the problem?

Cover Art

A jigsaw puzzle. Solving problems, such as puzzles, is often seen as an anti-pattern in design but may have the value in education. Credit: MeHe / pixabay.


  1. Design of algorithms, however, is only a small part of the software design, and designing whole systems requires a different approach. Butler Lampson nicely described this issue in his article on system design Lampson (1984). Lampson argued that designing a computer system is very different from developing an algorithm because the requirements are less precisely defined, more complex, and more subject to change. The measure of success is much less clear. And the designer usually finds himself in “a sea of possibilities,” where it is not clear how one choice will limit his freedom to take other decisions or affect the size and performance of the entire system.