In last week’s article ‘Improvisation Principles and Techniques for Design’, Gerber (2007), highlights five areas in which “improvisation applies to design work”. I asked learners to pick one and discuss how it might already apply to their own design process and why. I decided to tally the range of responses to see if there was one general area that resonated most with the cohort at this time. As you can see below “Learning through error” seemed to dominate the discussion.
While learning through error was mentioned as important in over 20 of the responses, it’s likely more accurate to show one representation of how some of the five processes intersect.
But let’s zone in on learning through error—understand its underlying engine—and in doing so I will bring up one of the primary activities that learners at the MDM Program engage in: Problem-solving. Click here for a previous post on problem-solving and heuristics.
On a meta-level, learners solve design problems through trial and error. Said differently, the best way to learn how to solve problems is to make mistakes solving them. This is nothing new in many fields and is an essential part that the gaming industry relies on in designing compelling games. Trial and error is an essential part of scientific research and Thorndike (early 1900’s) was one of the first behaviourists to demonstrate how to manage this process using…..cats in puzzle boxes. (likely not the one shown below).
(A note to my students…you are not a cat solving puzzles being experimented upon in the improv class…I think…)
Many excellent writings on the learning that occurs when we solve problems include those by educator and education scholar David Jonassen who defined and wrote about ill-structured problems, as well as the more recent re-surfacing of the expression ‘wicked’ problems—a term coined over 30 years ago by urban planner and designer Horst Rittel. (for a good read)
“One of the biggest problems learners have is understanding the steps they need to take in solving ill-structured problems. These are the kinds of problems that are not easy to identify, that are multi-layered—that cannot be solved until attempts at solving them are balanced by equal attempts to fail at solving them. Yet, there are steps that have been observed by many a problem-solver, including:
- Defining/Identifying the problem
- Generating possible solutions to the problem
- Evaluating alternative solutions
- Implementing the most viable solution
- Monitoring the implementation of that solution
- Repeating the process (Jonassen, 1997)”
(excerpt from a previous post)
So what’s this all have to do with improvisation? Well… How do you solve design problems? What heuristics or rules of thumb do you apply to solve those problems? Answering these will eventually take you here…
As a problem-solver myself on many a design (sound) and a witness to collaborators, learners and colleagues solving problems, I’m intrigued by the improvisational way in which problems are solved—more those problems that are ill-structured than those problems where the same formula is applied in their solution (is this even possible?). In the digital pipelined projects I have facilitated and mentored at the MDM Program, there is no one solution to a problem that a client comes to us with, nor one problem solving process that we have templated. How to solve problems is not an easy area to teach, but I love the challenge.
The process of solving problems is itself iterative. We try and fail, learn through that failure, and in doing so get closer to a solution. Many times we fail because team members first attempt to identify the problem and this is historically where things can start to go wrong. Getting to the root of the problem is often not possible because as discussed, at times the problem is emergent.
Other times teams fail to solve a problem because they have not nurtured a collaborative environment that honours each person’s process and contributions. So what is the root of the problem then….a design problem or a collaborative one? In a way, learning to solve problems together then perfectly exercises our ability to learn through making mistakes.
The solution to solving ill-structured or wicked problems is in itself an emergent and unknown process then that requires attention on the problem itself and how the team manages the solving of that problem. Each needs to be defined every single time. In approaching the solution to an ill-structured problem a common question becomes not ‘What is THE solution to the problem?’ but more like ‘What is A solution to the problem that we can all align with?’. Here’s a tool I will teach soon to get to the solution of a problem.
In my course, Bafia’s Projects 1 course and our Projects courses in subsequent semesters, learners simultaneously identify what the problem is (because it may shift), while they go through a process of researching previous or ‘close to’ solutions that others may have attempted prior, and projecting who the product might be for, looking at context, technology, trends, time constraints, etc…. The end result of the efforts is that learners propose a possible solution (or several).
But it’s hard to simply communicate a solution with words and this is why we prototype. Prototypes are an essential part of the process towards solving ill-structured problems because they act as a representation of the final product that clients can respond to. And these responses inform the next phase of the pipeline. Is the client satisifed enough with a working paper prototype (or several), that the team can now attempt to automate some of the features of within a digital environment? Is the team going back to the drawing board (literally) to co-create another 3 prototypes? What happens after the client responds to the digital prototype?
But let me get back on track. I began this writing in an attempt to show that learning through making errors is a key concern for the current cohort of learners and have shown that solving design problems provokes learning through error-making.
In making errors or to use the term we all dread in most settings, through failure, we exercise an essential part of the learning process that needs to be assessed in a completely different way. In a design problem-solving process there is no ‘right’ answer. And while one my learners mentioned that making mistakes has been ‘schooled’ out of them, since standardized exams tend to test knowledge retention, solving problems through making errors demands a different approach. You can’t memorize how to solve a problem because all problems are unique, especially ill-structured ones—they emerge from the unknown and force you to draw upon a combination of heuristics that may not be fully formed or defined. Add to this the collaborative challenge of solving problems with others and mistakes will happen. There is no ‘right’ process.
What this does imply, is that my assessment rubric must evaluate not so much “Did the learner solve the problem?” and “Did they solve the problem correctly?”, but more formatively as “How did the learner contribute to the process of solving problems iteratively with others?” and “How did this change over time?”
In this way, I remain integral to the problem-solving process itself. I can better evaluate a learner’s approach to solving design problems so that I can provide each with enough feedback that they may come out of the course with a more expansive toolbox, more ‘rules’ of thumb to support them in their next design problem. In other words in my course, do make mistakes and many of them…then reflect on that process. In doing so learners may not only reinvent their approach towards solving problems, but also their approach to learning.