A while back on cph127 Adam Richardson of frog raised the issue of wicked problems. I’m really glad he brought it up because I’ve always felt they are central to design as a professional practice. Curiously though there isn’t much talk in design circles about them.
In “Making Use,” John Carroll offers one of the most lucid descriptions of wicked problems I‘ve seen. To oversimplify him for clarity’s sake, wicked problems are those whose end solution states are unknowable at the outset.
For example a jigsaw puzzle is not a wicked problem. The end state is printed right there on the box top. Achieving that end state is an entirely tactical matter. Rapid trail and error seems good way to learn the puzzle’s internal rules. Once the rules are learned the puzzle is easily and solved.
On the other hand, “we need a new tool to help improve our call center reps’ productivity” is a wicked problem because the end solution state, the real root problems and their causal connections are unknown at the beginning.
This suggests that to call design a problem solving endeavour (as I’m fond of doing) is actually quite inadequate. Much of human activity, after all, is problem solving. So to be meaningful, we need to get a lot more specific: professional design’s main value is in solving wicked problems.
In my mind there are three general strategies in dealing with wickedness: mitigation, improvisation, and shot gun (I’m not sure these are the best labels).
In my experience the most common product development strategy is a whole lotta shot gun (with surprisingly little shot), mixed with a heap of improvisation (with woefully inadequate talent) and just a smattering of mitigation (with the caveat that this cannot impact schedule or budget).
Richardson seems to agree with this approach to wickedness, saying “[t]he only way to really understand the problem is by devising solutions and seeing how they further knowledge about the problem.” In other words, a shotgun is your only weapon again wickedness. According to van der Heijden in Scenarios this is the product development version of a strategic planning evolutionary paradigm (p.31 in case you’re interested).
To me this isn’t quite right because neither improvisation nor shotgun are sufficiently sustainable or repeatable to form the basis of a solid product innovation method. Leading with mitigation strategies, however, followed closely by shotgun strategies and improvisation capabilities promises much more consistent returns.
Let’s walk through the logic (again, oversimplified to clarity) of this backwards.
How do we mitigate wickedness?
By developing an appropriate vision of an optimal solution end state.
How do we do that?
By clearly focusing on the actual root causes of the problems being experienced, and using them as a mirror to reflect what optimal solution end states could and should look like.
How do we do that?
By discovering the right questions to ask—clarity is easy once you’re armed with the right questions.
How do we do that?
By closely studying and modeling users and/or customers, the pain they experience, their coping activities and their varied contexts.
(After writing this I was struck by its similarity to the designer as physician diagram below. I didn’t do this intentionally… really)
Now let’s walk though it forwards. We start with a client’s painful negative experience. No one knows how to alleviate this pain; if someone did, this wouldn’t be a wicked problem, it would be a puzzle—and so you would need an engineer and not a designer.
We then begin to study the painful experience, who experiences it and how. This starts to reveal the right questions we need to ask and the right areas we need to dig into deeper. Asking the right questions in turn starts to reveal the root causes that are driving the symptomatic pains the client came to us to solve in the first place.
With a clearer picture of the root problems and their causal connections we can realistically start to envision appropriate solution end states. The wickedness isn’t gone, but we’ve mitigated it, its no longer quite to so wicked. Not only have we reduced the wickedness, but we’ve also dramatically improved the speed and effectiveness of our shotgun and improvisation strategies and tactics.
I remember an interview from years ago with a Microsoft project manager who said something very profound: “I manage both designers and engineers. Engineers want to get from six options down to one, and designers want to go from one option to six.” The project manager has to balance these two competing tendencies. Many designers want to complexify problems, as they see problems as systems of inter-related issues which have to be addressed organically rather than discreetly. To use your earlier physician metaphor, they don’t just take the “presenting problem” at its face but look for the underlying problem. These underlying problems may or may not be wicked in nature. They may be complex – where the problem is known but the solution is not, but not necessarily wicked.
When you say that we can mitigate against wicked problems “By developing an appropriate vision of an optimal solution end state,” this assumes that optimum can be defined. In Rittel’s original definition of wicked problems, there can be no absolute right or wrong, only better or worse. This is what makes them difficult – the definition of what’s right and wrong changes over time, and changes depending on the perspective of the person looking at it. This introduces ongoing uncertainty into decision making.
While it’s true that I think you have to develop solutions in order to understand a wicked problem, I would not characterize the process as necessarily being as random, inefficient and slipshod as you describe in the paragraph prior to saying that I agree with that aproach. I would caution any company against such a random approach. There are things you can do to go about this systematically and sensibly, greatly increasing your chances of reaching a meaningful understanding. (I write about some of these in follow-ups on my blog.) Doing user research is only one part (and perhaps only a small part) of what’s needed – because the complexity of the problem often extends far beyond what customers can help you with. Decisions about developing a new product should address user needs (latent or explicit), but also can introduce issues of brand stretch, partnerships, legacy production capabilities, technology R&D, alignment with other efforts at the company, etc. All of these contributed to the wickedness of the problem, and cannot be sufficiently addressed with end-user research.
Adam
I should elaborate a bit. By “optimal” I didn’t mean right or wrong. I agree the nature of wickedness resists such judgments. So yes, better or worse.
But better or worse relative to what? In my mind it is relative to the pain or problem experienced. Therefore, in a sort of J.S. Mill utilitarianism, solutions that relieve more pain can be said to be objectively better than solutions that relieve less pain.
So a rich understanding of the pain, the people who experiences it and their context should point us in a direction where we will find more better solutions than worse solutions. This then mitigates the wickedness and uncertainty a bit.
From this perspective “an appropriate vision of an optimal solution end state,” is simply one in which we relieve more pain than less pain. For instance, “Janice hates repetitive manual data entry, it wastes here time and hurts her morale.” So we assume a causal connection (which then makes it explicit and thus falsifiable) and imagine end state scenarios where Janice’s data entry either isn’t repetitive, manual or where it doesn’t exist at all.
This doesn’t mean diving into tactical details like “voice recognition would solve her problem.” Nor does it mean thinking of the absolute best solution. It means that through user research and scenarios we can avoid just fumbling in the darkness of unfounded implicit assumptions and opinions. I means we’ve got good head start on prototyping
When I say “context” I think I’m referring to all those environmental and strategic constraints (all that stuff beyond the user but that impacts the user and the project) you mention. So I don’t disagree with you. Of course in my mind and work, the user is still the center that holds all the research together and gives it actionable meaning for the designer. Indeed while the designer must reckon with all the contextual issues, I don’t think his or her primary focus should be such externalities—in other words, user research may only be one line item, but for the designer it should outweigh nearly everything else.
Thanks for the thoughtful response—made me think more about what I was getting at.
“To use your earlier physician metaphor, they don’t just take the “presenting problem†at its face but look for the underlying problem. These underlying problems may or may not be wicked in nature.”
But a good doctor always treats the patient, not the desease.
You said: “When I say “context†I think I’m referring to all those environmental and strategic constraints (all that stuff beyond the user but that impacts the user and the project) you mention. So I don’t disagree with you. Of course in my mind and work, the user is still the center that holds all the research together and gives it actionable meaning for the designer. Indeed while the designer must reckon with all the contextual issues, I don’t think his or her primary focus should be such externalities—in other words, user research may only be one line item, but for the designer it should outweigh nearly everything else.”
In an ideal world I would entirely agree, and in an ideal world the product that best meets user needs would also be the most successful in the market. In reality, factors beyond how well the product satisfies user needs have at least as much impact on whether the product is successful at making money, and that is what determines whether it will be made, can be made, and continues to be made. If none of these three factors are addressed, then the user needs don’t get satisfied anyway because the product never gets to market or flops once it’s there and is withdrawn.
I think we may have achieved violent agreement. Yeah, I’m talking in an ideal world. My actual experience has always fallen somewhere short (often very short).
It should go without saying (so why am I saying?) that it’s extremely important to focus on the ideal to resist the gravity of externalities and getting sucked into a pur supply-side mentality. This is one reason why I like the iNPD model so much–it includes in the design process disciplines better suited to managing these externalities, freeing up a bit more of the designer’s attention to focus on the user.
An alternative to the three strategies above is to experiment in a virtual wicked problem space, that is, to model these spaces. I’ve been thinking about this a bit at: http://cogblog.aptima.com/socio-technical-engineering-wicked-problem-spaces/
Hello Id Like to skedaddle it as payn you this meddlesome get on with textile actuate out b in situ !
How with propose to we try something a impecunious attacking this later ?
perturn something like this ?
http://www.fluckhell23.com