{"id":72,"date":"2006-03-02T02:52:13","date_gmt":"2006-03-01T21:22:13","guid":{"rendered":"http:\/\/www.scoobr.com\/niblettes_old\/2006\/03\/02\/the-wicked-witch-of-the-web\/"},"modified":"2021-06-12T03:40:57","modified_gmt":"2021-06-12T03:40:57","slug":"the-wicked-witch-of-the-web","status":"publish","type":"post","link":"http:\/\/www.scoobr.com\/niblettes_old\/2006\/03\/02\/the-wicked-witch-of-the-web\/","title":{"rendered":"The Wicked Witch of the Problem Space"},"content":{"rendered":"

<\/a><\/p>\n

A while back on cph127<\/a> Adam Richardson<\/a> of frog raised the issue of wicked problems<\/a>. I\u00e2\u20ac\u2122m really glad he brought it up because I\u00e2\u20ac\u2122ve always felt they are central to design as a professional practice. Curiously though there isn\u00e2\u20ac\u2122t much talk in design circles about them.<\/p>\n

In “Making Use,” John Carroll offers one of the most lucid descriptions of wicked problems I\u00e2\u20ac\u02dcve seen. To oversimplify him for clarity\u00e2\u20ac\u2122s sake, wicked problems are those whose end solution states are unknowable at the outset. <\/p>\n

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\u00e2\u20ac\u2122s internal rules. Once the rules are learned the puzzle is easily and solved.<\/p>\n

On the other hand, “we need a new tool to help improve our call center reps\u00e2\u20ac\u2122 productivity” is a wicked problem because the end solution state, the real root problems and their causal connections are unknown at the beginning.<\/p>\n

This suggests that to call design a problem solving endeavour (as I\u00e2\u20ac\u2122m 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\u00e2\u20ac\u2122s main value is in solving wicked problems.<\/p>\n

In my mind there are three general strategies in dealing with wickedness: mitigation, improvisation, and shot gun (I\u00e2\u20ac\u2122m not sure these are the best labels).<\/p>\n

<\/p>\n

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).<\/p>\n

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<\/strong> this is the product development version of a strategic planning evolutionary paradigm (p.31 in case you’re interested). <\/p>\n

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. <\/p>\n

Let\u00e2\u20ac\u2122s walk through the logic (again, oversimplified to clarity) of this backwards. <\/p>\n

How do we mitigate wickedness?<\/i>
\nBy developing an appropriate vision of an optimal solution end state.<\/p>\n

How do we do that?<\/i>
\nBy 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.<\/p>\n

How do we do that?<\/i>
\nBy discovering the right questions to ask\u00e2\u20ac\u201dclarity is easy once you\u00e2\u20ac\u2122re armed with the right questions.<\/p>\n

How do we do that?<\/i>
\nBy closely studying and modeling users and\/or customers, the pain they experience, their coping activities and their varied contexts.<\/p>\n

(After writing this I was struck by its similarity to the designer as physician diagram below. I didn\u00e2\u20ac\u2122t do this intentionally\u00e2\u20ac\u00a6 really)<\/p>\n

Now let\u00e2\u20ac\u2122s walk though it forwards. We start with a client\u00e2\u20ac\u2122s painful negative experience. No one knows how to alleviate this pain; if someone did, this wouldn\u00e2\u20ac\u2122t be a wicked problem, it would be a puzzle\u00e2\u20ac\u201dand so you would need an engineer and not a designer. <\/p>\n

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. <\/p>\n

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\u00e2\u20ac\u2122t gone, but we\u00e2\u20ac\u2122ve mitigated it, its no longer quite to so wicked. Not only have we reduced the wickedness, but we\u00e2\u20ac\u2122ve also dramatically improved the speed and effectiveness of our shotgun and improvisation strategies and tactics.<\/p>\n","protected":false},"excerpt":{"rendered":"

A while back on cph127 Adam Richardson of frog raised the issue of wicked problems. I\u00e2\u20ac\u2122m really glad he brought it up because I\u00e2\u20ac\u2122ve always felt they are central to design as a professional practice. Curiously though there isn\u00e2\u20ac\u2122t much talk in design circles about them. In “Making Use,” John Carroll offers one of the […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_post_was_ever_published":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":false,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2}},"categories":[6],"tags":[],"class_list":["post-72","post","type-post","status-publish","format-standard","hentry","category-old"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/parCYG-1a","_links":{"self":[{"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/posts\/72","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/comments?post=72"}],"version-history":[{"count":1,"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/posts\/72\/revisions"}],"predecessor-version":[{"id":433,"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/posts\/72\/revisions\/433"}],"wp:attachment":[{"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/media?parent=72"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/categories?post=72"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.scoobr.com\/niblettes_old\/wp-json\/wp\/v2\/tags?post=72"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}