Tame Problems and Wicked Problems

Explaining the difference between a wicked problem and a tame problem has occupied my idle thoughts for the past few weeks. I am in the process of helping a very successful team understand that there is a fundamental difference between the design problems we presently face (which are wicked) and those we have faced together in the past (tame like kittens). Our motivation is an adventurous spirit to climb another mountain. Given that metaphor, if you haven't read Deep Surivial, I recommend it - It points out the importance of adjusting your mental model to the current state of your world in order to avoid, well, death. Adjusting my own mental model, and those of my compadres to the wicked nature of our latest design challenge is therefore important. I welcome any available feedback from those who have been there before.

Trying to Explain Wicked Problems
Here's what I've got: Wicked problems are hard to solve because there is no solution that is provable, no constituency who, if they approve, will testify that your "work here is done". Ambidextrous magazine sells a T-Shirt with the slogan, "Math is Easy. Design is hard." Put in the tame versus wicked problem frame, math is most often used to address tame problems like "how much weight can this bridge hold?". Some design problems are tame, but in the sphere of social and collaborative software, one must appreciate the wickedness of the design challenge.

Since we learn best by doing, I'm going to try an example. My team recently went through several iterations of a wizard-like application for one of our clients. The idea was to help our client's customers identify what products should be recommended, given a series of customer provided constraints, and software-encoded 'valid configurations'. In this case, the problem was constrained by the physical properties of the universe (meaning that, like a math problem, we could find "an answer"). One screen of our first iteration looked like this:

Once we did an expert review and discussed the interaction amongst ourselves (15 or so screens in total) we determined that we were missing an important element in this kind of system, which was some sort of "within feature context". Although normal site navigation is apparent in our first comp, the tool we designed was complex enough that the user would need to do wayfinding within it, as well as across the wider site context.

Our solution to this tame design problem was to provide the context, shown below:

The provision of context is not a new concept for interaction design. In fact, it's one that has been talked about a good deal for the past decade. In addition, though our design problem is important for this client, this design can be measured, evaluated and refined against criteria of goal attainment (do users complete the wizard and download the spec?), and user retention. It is a tame problem.

Wicked problems are defined in a number of places, with more available through a simple Yahoo! search. I won't review them here. It will be more helpful to provide an example of why I think social software and collaborative software design (our current design challenge) is an especially wicked problem. This is not a new thought. Such assertions are nearly ubiquitous in the CSCW community. It is "new to my team", however.

Here's the thesis: Technology driven approaches to the analysis of work (like the one above) do not suit the purpose of understanding collaboration. Mostly, this is because traditional analysis focuses on understanding the flow of information between systems. Information flow is only one component in human activity, and it is not the most central to collaboration. When I look for a book at the office, for example, the process is typically navigated socially and initiated with a question like, "Have you seen Women, Fire and Dangerous Things lately?"

To illustrate further, here's an example visualization of the proximal relationships between participants in an online course with 12 members:

If we imagine that there are many different interactions between each of the participants in this course, the network of relationships, relationship types, and other measures of closeness become fairly complex. If we lay over that discussion the design of tools to support collaobration in a virtual setting, the number of possible interactions is not practical to enumerate or design for explicitly.

Confounding the design challenge, there is no one *thing* that you can measure to determine that "this interaction design" is the one that will support the goals (which are fluid, and difficult to specify in advance) this tool must support. Also difficult to specify in advance are the processes that folks follow. Imagining the lines between people in a set of 12 may seem solvable. If you wish to design collaborative spaces to support greater volumes of users, however, the wickedness of the problem comes into view. Visualize the connection types and points in a set of 100 or more:

Large networks of collaborators don't have the well defined needs, or goal driven challenges of folks using technology as one dimension of their effort to work together. In fact, technology may not, for many of our users, be the currently dominant mode of coordination.

The challenge for social software design is social. Information flow is secondary, and it can be a very distracting frame of reference for analysis.

These differences have important implications for how we go about understanding the challenge, for the ways we design, for the relative importance of requirement gathering and prototyping and perhaps most importantly for what kinds of skills and experiences are required to succeed in this wicked world.

What suggestions do folks have for further explaining or helping my colleagues appreciate wicked collaborative software design challenges?