How with propose to we try something a impecunious attacking this later ?

perturn something like this ?

http://www.fluckhell23.com

It should go without saying (so why am I saying?) that it’s extremely important to focus on the ideal to resist the gravity of externalities and getting sucked into a pur supply-side mentality. This is one reason why I like the iNPD model so much–it includes in the design process disciplines better suited to managing these externalities, freeing up a bit more of the designer’s attention to focus on the user.

In an ideal world I would entirely agree, and in an ideal world the product that best meets user needs would also be the most successful in the market. In reality, factors beyond how well the product satisfies user needs have at least as much impact on whether the product is successful at making money, and that is what determines whether it will be made, can be made, and continues to be made. If none of these three factors are addressed, then the user needs don’t get satisfied anyway because the product never gets to market or flops once it’s there and is withdrawn.

But a good doctor always treats the patient, not the desease.

But better or worse relative to what? In my mind it is relative to the pain or problem experienced. Therefore, in a sort of J.S. Mill utilitarianism, solutions that relieve more pain can be said to be objectively better than solutions that relieve less pain.

So a rich understanding of the pain, the people who experiences it and their context should point us in a direction where we will find more better solutions than worse solutions. This then mitigates the wickedness and uncertainty a bit.

From this perspective “an appropriate vision of an optimal solution end state,” is simply one in which we relieve more pain than less pain. For instance, “Janice hates repetitive manual data entry, it wastes here time and hurts her morale.” So we assume a causal connection (which then makes it explicit and thus falsifiable) and imagine end state scenarios where Janice’s data entry either isn’t repetitive, manual or where it doesn’t exist at all.

This doesn’t mean diving into tactical details like “voice recognition would solve her problem.” Nor does it mean thinking of the absolute best solution. It means that through user research and scenarios we can avoid just fumbling in the darkness of unfounded implicit assumptions and opinions. I means we’ve got good head start on prototyping

When I say “context” I think I’m referring to all those environmental and strategic constraints (all that stuff beyond the user but that impacts the user and the project) you mention. So I don’t disagree with you. Of course in my mind and work, the user is still the center that holds all the research together and gives it actionable meaning for the designer. Indeed while the designer must reckon with all the contextual issues, I don’t think his or her primary focus should be such externalities—in other words, user research may only be one line item, but for the designer it should outweigh nearly everything else.

Thanks for the thoughtful response—made me think more about what I was getting at.

When you say that we can mitigate against wicked problems “By developing an appropriate vision of an optimal solution end state,” this assumes that optimum can be defined. In Rittel’s original definition of wicked problems, there can be no absolute right or wrong, only better or worse. This is what makes them difficult – the definition of what’s right and wrong changes over time, and changes depending on the perspective of the person looking at it. This introduces ongoing uncertainty into decision making.

While it’s true that I think you have to develop solutions in order to understand a wicked problem, I would not characterize the process as necessarily being as random, inefficient and slipshod as you describe in the paragraph prior to saying that I agree with that aproach. I would caution any company against such a random approach. There are things you can do to go about this systematically and sensibly, greatly increasing your chances of reaching a meaningful understanding. (I write about some of these in follow-ups on my blog.) Doing user research is only one part (and perhaps only a small part) of what’s needed – because the complexity of the problem often extends far beyond what customers can help you with. Decisions about developing a new product should address user needs (latent or explicit), but also can introduce issues of brand stretch, partnerships, legacy production capabilities, technology R&D, alignment with other efforts at the company, etc. All of these contributed to the wickedness of the problem, and cannot be sufficiently addressed with end-user research.

Adam