On Overusing Wicked Problems

When people casually toss around the term “wicked problem,” they’re not always talking about something insurmountable - just something messy and convoluted. I am guilty of doing this, too. In one of my (many) PhD drafts (you can read the final document here), I was trying to frame the problem of enhancement technologies as a wicked problem. I wasn’t completely crazy, as there is a rich history of design and wicked problems (see as an intro to the subject matter the excellent paper by Buchanan in 1992 and the more recent work by the consistently excellent Ben Sweeting). My supervisor¹ quickly steered me away from that idea, as he noted that wicked problems are pretty well established in the academic literature and have ten well-defined characteristics.

But let me backtrack for a second. We can broadly classify problems as tame or wicked. In our everyday parlance, a “tame” problem is like a spreadsheet (or a neat computation problem requiring an efficient algorithm): clear-cut, neatly boxed in, and with a best-practice solution you can copy-paste at best or infer at worst from yesterday. Wicked problems, on the other hand, have no definitive outline or natural break point, and any “solution” you come up with isn’t a magic bullet - it’s just an incremental (or marginal) improvement.

Now, don’t get me wrong. The phrase “wicked problem” has a legitimate pedigree in (amongst others) planning and design research. But there are ten traits originally set out to mark what makes a problem truly wicked. Here’s a quick rundown (trying to shy away from the academic lingo - but here is the OG paper if you’d like to read the real deal):

• No Definitive Formulation: Wicked problems aren’t ever really nailed down. One day, it’s one thing; the next day, who knows, but definitely different.
• No Stopping Rule: Unlike a tidy to-do list on the ever-present post-it, there’s never a moment when you can declare, “Done!” The work just goes on, endlessly becoming².
• Solutions Are Not True or False, But Better or Worse: There’s no neat binary here. You can’t say a solution is right; you can only say it’s less wrong than the alternatives. In other words, you can only aim for the best solution for the time being with the tools you have at your disposal.
• No Immediate or Ultimate Test: You can’t quickly run a diagnostics test on a wicked problem - the ripples caused by addressing a wicked problem take time to manifest, and usually, there are unintended consequences.
• Every Solution is a One-Shot Operation: There’s no sandbox mode here. Every fix has irreversible side effects, so you better be sure before sending it.
• No Enumerable Set of Potential Solutions: There’s no checklist of options you can pull out of a hat. The possibilities are vast, messy, and often hidden.
• Every Wicked Problem is Essentially Unique: Forget about one-size-fits-all; each wicked problem is its own beast, with a mix of context, people, and history that defies easy replication.
• Every Wicked Problem is a Symptom of Another Problem: These issues aren’t isolated bugs - they’re often the glitch in a much bigger, broken system.
• Multiple Explanations for the Discrepancy: Different people see different causes for the same mess, which only muddies the waters further.
• The Planner Has No Right to Be Wrong: In wicked problems, there’s no “oops, my bad” option - mistakes can (and often do) have far-reaching consequences.

In my academic and professional experience, I often see folks conflating “messy” with “wicked”. Sure, many challenges are messy, but a problem is wicked only when it meets all ten defining conditions. I’m not suggesting anyone is disingenuous, but I argue that casually using the “wicked” label on every complicated issue does a disservice to our practice. When we overuse the term, we risk muddying our analysis and misdirecting our efforts - or often excusing choices on “oh well, it’s a wicked problem, so I couldn’t really know the implications of my design/strategy/policy decision”.

Here’s where it gets interesting. Recent critiques (Turnbull and Hoppe, 2018, among others) have pointed out that slapping the label “wicked” on every complicated problem does more harm than good. It’s like calling every error in your code a “bug” without ever debugging - over time, the word loses its punch. Instead of treating problems as either fully wicked or entirely tame, we should see them on a spectrum.

Some issues are wicked in a couple of ways, but not in every respect. They might be complex, sure, but maybe they’re not entirely unfixable. The trick³ is to identify which aspects of a problem are truly unruly - whether it’s uncertainty, conflicting stakeholder interests, or irreversible consequences - and then tailor your approach accordingly. Instead of thinking, “This is a wicked problem, so let’s pray and spray solutions”, we need to ask, “What part of this mess can we improve, even if just a little?”

This isn’t just academic navel-gazing. By peeling back the layers and pinpointing where the real nastiness lies, we free ourselves from the all-or-nothing mindset that so often paralyses action. In doing so, we not only gain clarity about what we’re dealing with but also carve out a path toward pragmatic interventions that, cumulatively, can shift the balance. Acknowledging the spectrum of wickedness isn’t about copping out. It’s a rallying cry for a more honest practice.

My own PhD practice hugely benefitted from not framing my subject matter as a wicked problem. It forced me to really dissect it and figure out the intervention points and how to build a (practice-based) approach to designing wearable enhancement technology. It’s definitely not perfect, but it did lead me to several “contributions to knowledge” ⁴ that led me to add three letters after my name.