Hi Ken,
In your view, can you do 'design' for tame problems, or only wicked ones?
e.g. if a graphic designer is desiging a business card and the problem is
'tame' (they've done it before and they know what to do) then is it 'design'
in your view?
Regards
Lauchlan Mackinnon
----- Original Message -----
From: "Ken Friedman" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Sunday, April 15, 2007 10:24 PM
Subject: Wicked Problems, Tame Problems
> Dear Chris and Klaus,
>
> Klaus's comments make sense to me. The term "wicked problem" works
> well as Rittel defines it. The issue as I see it is not that "tame
> problems" are ideal, but rather that mny aspects of supposedly wicked
> problems are not in reality wicked. In a long-ago conference at
> Politechnico di Milano, I recall Ezio Manzini proposing that many
> kinds of design problems in industry could be solved by off-the-shelf
> components that we might configure in different kinds of systems,
> allowing us to save time and money, increase sustainability, and
> encourage recycling.
>
> This systemic approach implies that we distinguish between classes of
> problems - and it suggests that from time to time, we do seek ways to
> tame parts of the wicked. I'd argue, further, that some problems that
> seem wicked are only wicked because we know too little. Some problems
> are inherently wicked: Rittle's criteria distinguishes those. Even
> simple wicked problems may always be wicked because they involve
> preferences and choices among people with differing desires, tastes,
> and wants. Such simple yet wicked problems involve questions like:
> What shall we eat for dinner? Which movie shall we watch?
>
> But some problems are tame and other problems can be tamed. In some
> cases, taming a problem is the ideal -- the art of judgement rests in
> knowing when we should look at a problem new and fresh, and when we
> should accept an algorithmic solution.
>
> One thing Chris wrote last week got me to thinking. I tend to
> disagree with Chris on the idea that wicked vs. tame problems
> distinguish design from engineering. There are many examples of tame
> design problems. A typographer who prepares a simple page layout to
> the standards of a design manual practices design rather than
> engineering. Physicians practice medicine when they solve effectively
> tame problems -- aspirin for a minor ailment, cough syrup for a cold.
> To me, it is implicit in the art of diagnosis that some problems will
> be tame and others difficult, even wicked. Even tame problems require
> judgement and expertise. Design studios do not send tame problems to
> engineers. The senior designers give them to the younger designers
> with some instructions and, depending on the nature of the problem, a
> degree of latitude in solving them, wide or narrow according to the
> judgement of the senior designer.
>
> For many working designers, taming problems is not merely ideal -- it
> is necessary. The greatest percentage of profit in the work of many
> design studios comes from routine production work once the real
> problems have been solved. This is especially the case in graphic
> design and architecture, That's how studios make a living and keep
> the staff employed, especially when they must often use surplus funds
> to work on the deeper aspects of wicked design problems. These often
> cost so much to examine and solve that a designer uses far more than
> the client can pay. The production work that follows permits
> designers to spend more hours on a project than the client may
> actually pay for.
>
> I'd argue that routine studio work on tame problems involves the
> exercise of simple craft skills along with expert design judgement.
> Nevertheless, much applied design takes place after the problems have
> been tamed, and I'd argue that this is not engineering but design.
>
> Most of these definitions function in a gray zone: the nature of
> design work (and the nature of engineering at different levels) often
> requires us to exercise all these kinds of approaches. My view on the
> virtue of using Rittel's definition is that it helps us to sort out
> different aspects of what it is that makes a problem wicked. Without
> arguing that tame problems are the ideal, I do argue that designers
> seek to tame problems as much as engineers do. If they did not, they
> could not run a studio and earn a living.
>
> Where Chris and Klaus and I probably all agree is that dealing with
> wicked problems is much more fun than dealing with tame problems. I
> don't run a studio and I don't want to. If I had ten or twenty
> employees -- as some of my friends do -- I would have to tame
> problems and work on routine design applications to pay the rent, the
> salaries, the various taxes and pension contributions, and so on. In
> contrast, professors get paid to think. We make just as much (or as
> little) solving the problems that interest us. Academic freedom means
> that we can work with wicked problems all we like -- even when we
> cannot solve them. My friends who run studios don't have that luxury.
>
> Warm wishes,
>
> Ken
>
>
> --
>
> Klaus Krippendorff wrote:
>
> it might be useful to use the word wicked and tame in rittel's sense
> -- until someone proposes a better definition.
>
> saying that the problem posed by wicked problem is to tame them
> assumes that tame problems are the ideal case. rittel defined
> wickednes by its untameability, calling for different methods
>
> --
>
> Chris Rust wrote:
>
> Ken's right that designers have to deal with tame problems, but
> whether they involve making sure your pencil is sharp or calculating
> the optimum "design" for a conventional structure, I don't believe
> that such routine and predictable tasks are a part of designing, any
> more than washing up, however necessary, is part of the art of a chef.
>
> This brings us back to an old chestnut that we have tussled over
> before and I'd like to have a go at resolving it. It's to do with the
> difference between designers and engineers, or rather between
> designing and engineering. I'll start by saying that I was quite
> surprised, many years ago, when I gave a lecture to a group of
> engineering students, to find that they had come to the view that
> "designing" was low-grade employment compared to what they referred
> to as "development". I realise now that their development was close
> to Lauchlan's designing and their view of designing was the solving
> of routinised mathematical problems.
>
> Since then I have discovered wicked problems and I think I now take a
> very simple view which is this: Designing is essentially the business
> of resolving problems that cannot be tamed, Engineering is the
> business of taming problems that have become tameable, at least for
> the time being and within some limits.
>
> So there are two quite different and equally difficult arts and, I
> suspect, two different temperaments at work. Of course there is no
> strict demarcation, people who are designers by instinct will still
> tame a problem if it suits them, a natural born engineer will not be
> averse to wrestling with a wicked (untameable) problem if one comes
> their way. But the tendency of the engineer is to fix things down and
> hope they will stay fixed, the designer will be fascinated by the
> problems that refuse to stay fixed. Maybe it's as simple as some
> people like rules and others don't.
>
> --
>
> --
>
> Prof. Ken Friedman
> Institute for Communication, Culture, and Language
> Norwegian School of Management
> Oslo
>
> Center for Design Research
> Denmark's Design School
> Copenhagen
>
> +47 46.41.06.76 Tlf NSM
> +47 33.40.10.95 Tlf Privat
>
> email: [log in to unmask]
|