Design and Ambiguity

Eide Neurolearnings has an article on “ambiguity” and how developing minds deal with it. I disagree with many of their implications (for instance, that the difficulty children have in dealing with ambiguity is a discrepancy between the development of the reasoning and communicating abilities), not to mention the very … err … ambiguous use of the term, “ambiguity” in each of the associated articles.

So I will limit myself to discussing ambiguity in brainstorming.

There’s no such thing.

Oh, fine, I’ll elaborate.

This referenced article describes the tolerance of ambiguity as “the ability to live in a universe where there are no right or wrong answers, where ideas or thoughts are vague and yet unformed.” These are two very different things. The former phrase is an assertion that, epistemologically, concepts have little or no relation to reality and, therefore, can not be used to determine truth or validity in relation to reality (alternatively, it could just be embracement of the same old tired subjective reality beliefs … yawn.) The latter phrase, on the other hand, is useful ... a statement that concepts can be incomplete. In other words, a statement of “insufficient data”.

What does this mean for us in a design situation … how do we minimize ambiguity, identify it, resolve it, and keep it from causing problems in our projects? (Note that this is not an exhaustive list … I don’t describe, for instance, the things that must be done in the process of mapping abstracts to concretes.)

1. Thoroughly define your context.
2. Identify constraints (typically concretes, so be aware of how these are reflected abstractly.)
3. Take measures to know what you know about every concept (attributes, intrinsic behavior, relationships, classifications, and methods of interaction), both in terms of completeness and confidence.
4. Take measures to know what you don’t know, both in terms of requirements to accomplish the specified goal as well as deficiencies implied by context, interaction, relationship, and      methods of implementation.
5. Figure out if the things you don’t know are relevant to the individual step in the chain of reasoning.
6. Figure out if a later reasoned step mitigates a lack of information in a former step.
7. Describe the efforts necessary to resolve each deficiency.
8. If you choose not to break up the brainstorming session in order to resolve the deficiencies, figure out what you think the conclusion will be, give it a degree of confidence, a      significance with regard to subsequent conclusions, and a description of risk to the entire solution if your conclusion is wrong.
9. Figure out if you can design out the risk (i.e., if a deficiency in knowledge has two ways in which it can resolved, determine if you are able to implement your solution in such a way that either case can be handled).

Omniscience is a fantasy. Beware anyone who never says, "I don't know." Train anyone who acknowledges ignorance, but doesn't yet deal with it in a structured manner. Embrace anyone who can describe for you a solution that compensates for ambiguity. Fire anyone who says, "You can't know."