For the past few weeks in our theory class, we have been talking about the process of problem-solving and human-computer thought in solving problems. These particular readings have been of interest to me, especially because I have always been interested in the way humans solve problems or interact with them in the form of games.
From all four of the readings, I have been picking up small threads of things that are similar amongst them in an effort to tie them together as a whole. The overarching idea that I have been entertaining while reading these is about the process of insight, or problem-solving, which is:
Problem-solving is the product of a rigorous process of identifying problems individually, thinking about them systematically, incorporating feedback, and educating others.
What does that mean? It means that in order to solve a problem, we must go through various stepping stones in order to get to a final solution to the problem. This includes thinking about problems on an individual scale (i.e. I don’t have food in my fridge) and on a systematic scale (i.e. How many other Americans can also say this? To what extent?) as well as studying your own thought processes on the problem and how you can affect this problem.
These were the two axes of my graph—whether the authors thought of problems on a case-by-case basis as opposed to an overall systematic basis, or whether they focused on either the thought processes involved in solving a problem versus the way that your solutions affect the problem.
So, what does this mean as far as the problem-solving process is concerned? What it mean for designers to have insights?
The thing that stands out for me is the process in which we achieve insights. Many people will write off insights as “well, that person is creative, I couldn’t have that insight,” or “insights happen magically,” not taking into account that there is indeed a mental process that people go through to achieve insights.
In the above graph, I tie each of the author’s viewpoints to a different process in the problem-solving process. Simon talks about identifying problems in an individual space—that is, applying constraints to a problem to better define it or solve it. Laird’s viewpoint is about the way that humans go through testing certain mechanics until they evolve into an overall strategy, which is the way that designers synthesize. We have tools for problem solving, but overall, it is up to us to formulate a strategy for solving problems. Tversky and Kahneman are concerned with human bias, and I interpret this as feedback. Getting feedback from your ideas or artifacts is a great way of deciding whether or not your own bias is getting in the way of a great design.
The fourth step in the process is educating and communicating to others your ideas. While this may seem to some an optional part of the process, I think that it is absolutely necessary to communicate your solution, either in a formal way (such as this blog post), or simply explaining orally a problem to someone. By teaching others you a) expand their problem-solving skill set and b) cement your own process in your mind.
The steps in the problem-solving loop is something that needs repeating because I hear constantly people chalking up others ideas to them being geniuses or talented. While it does take intellect to understand these steps, and not everyone achieves the same result, these steps are not “magic,” and are repeatable.
Overall, I think this is the way that we tackle problems here at AC4D—in fact, the curriculum is structured in this loop for us to identify problems, synthesize, gain feedback, and then ultimately communicate it to the world.No Comments »