Tame, Wicked, or Hybrid? The Question to Ask Before You Choose a Method

Two designers can look at the same brief and reach for completely different tools, and both be right, because they are not actually facing the same kind of problem. The Symbiotic Design Framework starts by asking you to tell the difference before you commit to a way of working.

## Tame problems: solvable, structured, bounded

A tame problem is not necessarily easy, but it is solvable. It lives inside a known world of rules, constraints, and predictable behavior, which is exactly what makes it open to structured, often linear, ways of working. {/* cite: problem_type-tame | tame problems are ultimately solvable; known universe of rules, constraints, predictable behaviors; amenable to structured, often linear approaches */}

You can recognize one by a handful of marks: the problem can be stated clearly and stays stable once it is; there is a definite point at which the work is done; solutions can be judged right or wrong, or at least better or worse, against objective measures; the problem belongs to a class of similar problems rather than being one of a kind; and you can try, test, and walk away from a failed attempt cheaply, without changing the nature of the problem itself. {/* cite: problem_type-tame | defining properties: well-defined stable statement; definite stopping point; objectively correct solutions; belongs to a class of similar problems; low-consequence trial and error */}

Facing a tame problem, the framework casts the designer as an expert executor: a skilled technician applying known principles to reach a predictable outcome efficiently. {/* cite: problem_type-tame | navigation posture: expert executor, a skilled technician applying known principles to achieve a predictable outcome efficiently */}

## Wicked problems: the kind that resists solving

Wicked problems sit at the other end. The term comes from planning theorists Horst Rittel and Melvin Webber, who used it for social and cultural challenges that are difficult or impossible to solve outright, because their requirements are incomplete, contradictory, and shifting, and are often hard to even recognize in the first place. {/* cite: problem_type-wicked | social/cultural challenges difficult or impossible to solve because of incomplete, contradictory, changing requirements often hard to recognise; attributed to planning theorists Horst Rittel and Melvin Webber */}

Rittel and Webber described ten traits that mark a wicked problem out. A few carry most of the weight: there is no definitive statement of the problem, only competing framings of it. There is no stopping rule, so nothing tells you the work is finished. Solutions are not true or false, only good or bad. There is no test, immediate or final, that settles whether a solution actually worked. And because there is no opportunity to learn by trial and error, every attempt is a one-shot operation: it changes the situation whether it succeeds or not. {/* cite: problem_type-wicked | ten defining characteristics from Rittel and Webber, incl. no definitive formulation, no stopping rule, good-or-bad not true-or-false, no immediate/ultimate test, one-shot operation */}

A technician's toolkit does not fit a wicked problem. Facing one, the framework asks the designer to become something else: an explorer, a facilitator, a systemic thinker. {/* cite: problem_type-wicked | navigation posture: explorer, facilitator, and systemic thinker */}

## Hybrid problems: most of the ones that matter

Pure tame and pure wicked are the two ends of a spectrum, and most real design challenges do not sit at either end. The framework calls the space between them hybrid: a problem that holds both a system and a blueprint at once, parts that can be planned and solved cleanly, tangled together with parts that resist any clean solution. {/* cite: problem_type-hybrid | most significant design challenges are hybrid, containing both a system and a blueprint; many real-world problems exist on a spectrum of wickedness */}

That mix asks something specific of the designer: to be a versatile navigator, capable of switching skillfully between mindsets, technician where the ground is firm, explorer where it gives way. {/* cite: problem_type-hybrid | navigation posture: versatile navigator, capable of skilfully switching between mindsets */}

## What this triage does not give you

It is worth being honest about what naming a problem's kind does not do. The framework does not hand you a step-by-step method for solving a wicked problem. There cannot be one: a problem with no definitive formulation cannot have a fixed procedure. What you get instead is a posture to adopt and a more accurate diagnosis to start from, which, for a problem of this kind, is often the more valuable thing to have.

## Why this is worth doing first

Naming the kind of problem in front of you is worth doing before anything else: before picking a method, before mapping a single component. It is often the highest-leverage move available, because it decides which of the postures above, technician, explorer, or versatile navigator, is even the right one to reach for.

This is one piece of a larger way of seeing design. If it is useful, the newsletter carries more of it, one idea at a time, and the Academy's foundations course starts from exactly this question.