How to distinguish between wicked and tame problems
|
 |
By Dennis Nordstrom in General Published: Wednesday, 19 November 08 - 01:21 AM (GMT) Last Updated: Thursday, 20 November 08 - 12:47 AM (GMT) |
| ||
On my blog-tours for the last couple of days, I have started to see a theme emerging within the UX industry. People are talking about design as problem-solving. Design as a way of identifying problems, and as a methodology for solving these. First, let me emphasise that I do not completely agree with that point of view. I believe that some design-projects will mostly resemble the process of solving problems, but not all design entails problems (Sometimes there just are no problems to solve, only context to enrich). But, that is not the focus of this article. the focus of this article is about that part of design, that do involve problems and problem-solving.
As I see it there a different ways of defining problems and thus different ways of approaching (solving) them for the purpose of design and I wanted to highlight that here. On my blog-tour I did not see anyone mentioning "wicked problems" within design, and in this article the distinction will therefore be made between Rittel's "wicked problems" and "tame problems".
The purpose of this article is thus, to make one aware of these distinctions and thereby to make it easier for designers to identify the right sort of problem upon encounter. This will enable designers to take a right approach towards the problem, which will prove to save their time and energy in the long run.
Let's start with a simple characteristics of "wicked problems" and "tame problems". According to Horst Rittel, "wicked problems" are problems that do not let themselves easily be identified. This can be because of conflicting definitions, because of conflicts between budget, time, and effort put into design, or just because it is a problem where there are no criteria for a solution. "Tame problems" on the other hand, are problems known from mathematics or puzzle solving, where a complete solution does exist. Each of these forms of problems require different approaches, and it is for "tame problems" that I have been reading a lot of blogs. I did not see a lot of mentioning of "wicked problems", which I believe happen more frequently within design. So, in the following I will go over what I believe are valuable approaches for "wicked and tame problems".
One of the blogs I found particulary helpful when it came to problem-solving of "tame problems" is a blog written by Luciano Passuello. It stated that Einstein was quoted to have said that if he had one hour to save the earth, he would spend 55 minutes to define the problem, and 5 minutes to solving it. I found this quote to be quite inspiring.
The idea here is of course that the solution to a problem lies within the definition of it. Therefore when designers and researchers encounter "tame" problems, it is in their interest to provide a decent definition of that problem before setting out to solve it. Often the solution of the problem can be found within the definition of the problem.
Passuello provided ten great guidelines for defining the problem, and thus making "tame problem-solving" easier. The ten guidelines are listed below by titles, and more comprehensive explanations can be found here.
The ten guidelines are:
1. Rephrase the Problem
2. Expose and Challenge Assumptions
3. Chunk Up
4. Chunk Down
6. Use Effective Language Constructs
7. Make It Engaging
8. Reverse the Problem
9. Gather Facts
10. Problem-Solve Your Problem Statement
However, when it comes to solving "wicked" problems these guidelines might not prove as useful. By the very nature of Rittel's definition of "wicked problems", these are not easy definable and since the majority of problems designers would meet are "wicked problems", an appropriate approach for those problem must follow.
When it comes to "wicked problems", I propose that designers take a direct opposite approach from solving "tame problems" and dive straight into designing. Since "wicked problems" often have conflicting characteristica and therefore are difficult to define, one might as well let the design guide the process of providing a solution. Thus, the design will work wonderfully as an actor of finding better alternatives, by simply trying to find solutions and through an iterative process change the prototype until it is good enough. Obviously, criteria for "good enough" needs to have been made clear in order to make that decision. That is where Simon's concept of "satisficing" might help.
Herbert Simon came up with the concept of "satisficing", which is a strategy of meeting adequate criteria for your design. "Satisficing" is thus a concept for the designer to reach consensus and a state of satisfaction about her or his design. "Satisficing" is especially applicable to "wicked problems" since these are not about true or false solutions, but about better or worse alternatives. "Satisficing" is a way for the designer not to search the universal answer, but to become satisfied with the outcome of the design-process, and to match that outcome with set criteria.
Therefore designers and researchers need to be aware of the concepts: "wicked problems", "tame problems", and "satisficing" in order to maximise their roles as professional problem-solvers. When it comes to "tame problems" I have outlined Passuello's ten guidelines, which I find very helpful. I can certainly recommend spending the majority of one's time defining the problem, when trying to solve a "tame problem". However, with "wicked problems" the criteria are not true or false but better or worse, therefore a complete solution will never be found. One of Jeff Conklin's defining characteristics of "wicked problems" states that these can never be fully defined until a solution has been found. So, with a limited timeframe in a project, there is no reason to spend time defining the problem, since a definition cannot be found until an alternative solution has been found. Instead it makes sense to dive straight into the design, and let the design guide the designer's "satisficing" process through user-testing and stakeholder meetings.
This is why I think that when it comes to designing, one of the first steps should be to be able to categorise the problem at hand either as a "tame problem" or as a "wicked problem". By doing this, the designer or the researcher guides the process and will thus be able to maximise his or her time and effort. Therefore, one of the first steps to good problem-solving is in terms of "wicked or tame" problem, and from this categorisation the problem-solving process becomes clearer.
My hope is that this blog will help making this catagorisation of problems clearer, as well as make it easier for people to see the following problem-solving process of defining a problem, or leave the definition and jump straight into designing, clearer.
Have your say on this article:
<-- Back
