Dealing with Ambiguity

If you are going to design anything, you will likely need to deal with ambiguity. Simply put, this means you do not know for certain what the end result will be, and you also have to choose from several potential pathways to reach that solution. As designers, we have been trained (sometimes even explicitly) to deal with this uncertainty. However, as we increasingly bring clients into our process, we expose a whole group of people that has worked their entire academic and professional like to avoid ambiguous situations (a little hyperbole, I know).

This discussion focused on how design planners can better “deal with ambiguity”, and discussed ways to make this fact of design life easier on them.

Expectations versus reality

The discussion began by noting a graph drawn by Matt Beebe (from IDEO) that explained the difference between a design process’s actual and expected progress. At this point, Dave McGaw noted that most new designers have the same frustration--they expect progress to be linear.

The disconnect between expectations and progress:

Zach built on this idea and noted that it's not even a single-sloped learning-curve graph, but a slope with numerous, smaller rises and falls in level of ambiguity.

These issues are fairly common in any creative process, and designers need to make our clients feel better about ambiguity. At the same time, trying to force the creative process into a linear relationship with time would harm the overall design process. A slide showed some common client comments about ambiguity:

Why ambiguity is good and, in fact, necessary for innovation

A simple 2x2 diagram shows where good design programs and approaches stand with respect to level of definition for results and process; ID strives to use a defined process to arrive at undefined results, where traditional design programs use undefined processes to arrive at defined results. Undefined results are valuable because they are often the innovative concepts, but then the big questions are: how do we know when we're done, when we've arrived at that innovation?

Program types:

Hypothesis driven, fact-based is the strategic planning approach (much like the scientific process), wherein data is collect based on the premise to prove or disprove the premise. A hypothesis supported approach for innovation planning involves a hypothesis as the starting point for research, but it's understood that the initial hypothesis can and probably will change.

Classes of problem solving:

Disclaimer: Ambiguity does not mean you don't need a plan!

Ambiguity should not be confused with under-specification; we still want to have a well-defined process, clear deliverables, metrics for success, and a clear roadmap. Not all aspects of the design process benefit from some degree of ambiguity. At the same time, over-specification of the design process can be inefficient. This chart shows where open-endedness is good, and where specific definition is preferred, in the overall design process.

Under-specification:
> Poorly defined process
> Unclear deliverables
> No measure of project success
> Make it up as you go..

The problem with some Demo projects in the past is that many teams don't have a final goal in mind, and wherever they end up on May 15 is what they deliver as their final project. There are better ways to plan an innovation project:

The "meander" approach:

Hill climbing: determine a goal and work backwards to figure out how to get there from where you currently are. This approach is good for engineering projects, where the end product is already established.

Hill climbing

Efficient diversity: know where you're starting, determine a clear goal, but throughout the process you will make a series of decisions in order to get there. This is a more organic process that may be more fitting for innovation planning.

Efficient diversity:

Finding a balance

Ultimately, designers need to understand what you can control about the process, what they need to learn more about, and what can be eliminated in order to deal with ambiguity. You can deal with ambiguity by doing what you have been doing so far, but only changing one small part instead of changing everything and facing a completely unprecedented situation that is to unfamiliar and ambiguous.

Several techniques were offered:
1. Have a clear work plan and stick with it

2. Aim for short term wins -- Can we deliver some quick insights to the client to prove that we are on the right track? This instills trust and gives designers "a free hand" in moving forward.

3. Reason using analogies – how has this problem been solved before in other industries? How have we solved other problems like this at our own company?

4. Create information structures, a la structured planning -- This is a powerful way to deal with big topics and ambiguity because it places everything in a larger context, and ensures the client that the designer has considered many facets of the problem.

5. Holding frequent update meetings -- never surprise your client! Dave comments that this is the one that is hardest to implement even though it seems really easy. The only way it really works is to get a project manager who rules with an iron fist and enforces that, because a designer is not going to spend as much energy making sure it happens.

6. Focus on building trust -- "There are two types of people in this world: those that do what they say they're going to do, and everyone else."

Comments

[Vincent LaConte]

Interesting. Are Under-Specification and Meandering the same thing? How do we deal with the micro-ambiguity that exists at each intermediate square in Efficient Diversity? Finally, "Structured Planning" should be capitalized whenever it's used, it being a large collection of methods and tools, more like a book or lengthy article than a method itself.

[Logo Design]

yeah that's a great techniques you shared, i'm a design student and i always usually do planning and create some tasks before starting any work.