Our references are usually designers or design schools…architects or comic illustrators if we push it, we rarely cite events or characters that have little or nothing to do with our closest practice. I must confess, however, that two of my greatest influences in order to tackle design processes are the Cold War and the American invasion of Baghdad. Allow me to explain.

During the Cold War, intelligence work on both side consisted of coming up with questions such as: How many missiles does the Soviet Union have? Where are they? How far can they reach? Where are they pointing? How accurate are they? All of these questions had an answer, a solution, although at that time it was not yet known.

These questions solve a very concrete type of problem. We are faced with empty boxes. When we find the information that fits in them, we fill them and the problem is solved.

We call these problems puzzles. Sometimes they seem incredibly complicated, but once created, the puzzles are easy to understand, even if they are not easy to solve. We are easily forgiven when we cannot solve a puzzle; key information is missing in order to solve it; information was hidden; someone is hiding a fundamental piece of information in order to clarify it: the client, user, market, etc.

In order to solve puzzles we need to compile information. We look for information to fill the gaps of our answers. This involves a considerable expense of time and money. In order to solve the question of how many nuclear warheads the Soviet Union had, the United States built expensive satellites, created enormous research agencies, and designed a complex network of spies that it deployed in Soviet territory. What is frustrating about puzzles is the lack of information, but its solution widely compensates for the cost of research.

Presenting many of our clients’ problems as if they were puzzles is very appealing to the design world. We know how to research, we are experts in holding workshops with clients, we skillfully execute tests with users, and additionally, we compile hundreds of statistics through analysis. Many companies are thrilled with this approach; their ultimate goal is to find a clear answer, a simple solution to their problems. When we make mistakes in solving puzzles, it ends up being relatively easy for our clients to forgive us: it is not our fault, but rather a lack of information.

I would venture to say that the origin of our “puzzle” vision is based on usability. The user is not able to perform a task because the button is not positioned correctly; users cannot read well because the contrast between the text and the background is too low, the column width is not right, the font size is off, etc. Now then, are all of our problems puzzles, or do other kinds exist?

There are problems known as mysteries. In these, no concrete information solves the general problem. Think about the way to answer this question: What will happen in Iraq after an American invasion to topple Saddam Hussein? The answer to that question was not simple; we are not looking for a statistic that offers clarity. Now we need to make a judgment, a hypothesis regarding the problem, and we know that we will have to live with a certain degree of doubt in our response.

The distinction between puzzles and mysteries is not trivial. In mysteries, no isolated information solves the problem on its own; the amount of information itself is part of the problem. Puzzles always have a satisfactory answer, a conclusion. Mysteries do not generally have a definitive answer, because the answer is contingent, it depends on a future interaction with factors of which we are not aware; not because they are hidden, simply because there are too many of them to be understood and correctly processed.

What is surprising about mysteries is not that we have little information; the issue is that we have too much. The CIA had a vision for the Baghdad invasion, the Pentagon another, the State Department another, all of the taxi drivers in Baghdad had a vision regarding what would happen after an invasion. Here we are faced with a mystery.

The majority of design projects, at least the worthwhile ones, are mysteries, not puzzles. We constantly see design solutions that address mysteries as if they were puzzles. This is mission impossible. This sin leads many of our clients to never-ending workshops, research with no clear purpose, which only seeks to accumulate information, final products that show a glaring lack of judgment and vision. People increasingly think that our job is to create intermediate deliverables, prototypes with realistic effects that only seek to sensationalize and to justify excessive budgets.

When I was asked “What do designers do?”. A voice within me automatically responded:

“A designer solves problems within a set of constraints.”

Mike Monteiro

In this small but great quote, there are two words closely tied to one another: “problems” and “constraints”; its understanding terribly affects our work. Designing to address mysteries requires courage in the face of a problem, clear positioning, and the assumption of reasonable doubt in our conclusions.

Honesty in presenting our process to the client, explaining that our research can only be used to rule out 99% of the information found, but also showing at the same time that we are dealing with work that is essential for generating insights. All of our efforts and experience is poured into simple hypotheses in the form of an interface, but they are hypotheses that will contain the critical factors of a problem, that is designing. In order to do this, designers are needed to face mysteries head on, not to solve puzzles.

Sources

• Risks and Riddles Author: Gregory F. Treverton
• Design Solutions to Puzzles and Mysteries Author: O Danny Boy
• Open Secrets Autor: Malcolm Gladwell
• Are You Solving a Puzzle or a Mystery? Author: Tim Kastelle