It Depends

By Charlie Kreitzberg
Senior UX Advisor
Princeton University

 

T

here is an on-gong joke in the design community. It goes like this:

Q: What is the answer to every question?

A: It depends.

It’s funny because it’s true. But it’s also frustrating. People want rules they can apply, the simpler and more straightforward the better. Well thought-out rules are easy to communicate. They help people make decisions, and that makes them really useful.

The nature of design, however, is to have few rules. A lack of rules does not necessarily make the design process chaotic because design gets structure from frameworks, principles and constraints. But a lack of rules does make the design process hard to communicate and teach. Almost every time someone tries to clarify things with a question, they get the same frustrating answer: “it depends.”

Why is this important? Because if our goal is to make design thinking a central part of all development and, on a larger scale, a core part of organizational culture, we have to be able to explain it in a way that non-designers find both comprehensible and actionable. Without the ability to clearly explain the approach to solving the problem, it’s impossible to create realistic project plans and make good decisions.

Rules

Rules help people make decisions. I go to the store and buy a bag of chips. These cost $2. I hand the cashier $5. All the cashier has to do is to follow the rule “hand the customer the correct change” and the transaction is complete. There is very little problem-solving that the cashier needs to do. Their task is simplified by the rule.

Not surprisingly, organizations love rules. Once processes are designed, rules put in place, and staff trained to use them, operations can run smoothly. So it’s only natural that as designers we are often asked to provide a set of design rules that others can use. It’s well-intentioned, but the result is rarely satisfactory because the “rules” that designers follow are not really rules.

For example, Adobe has published a set of “The 15 Rules Every UX Designer Should Know” (Babich, 2018). Here are the first three:

1. UX is not (only) UI: User Interface is a part of User Experience.
2. Know your audience: User research is a natural first step in the design process.
3. You are not the user: Testing with real users is an essential part of the design process.

These are all excellent statements, but they are not rules. A rule has to tell you what to do and these don’t. For example, rule 1 says that ‘user experience is more than just the user interface.’ It’s a valid and important point but it does not tell you how they are different and what to do because of it. Rule 2 says that you should lead with user research. Sure, but how? Focus groups, interviews, surveys? These are questions that perplex non-designers and the answers are rather lengthy because “it depends” on many factors like time, resources, participant availability.

I would call these statements principles. They provide useful guidance to the UX designer but they are not actionable. And this gets to the core of the problem. Ask how to apply a rule and you can expect a straightforward answer. Ask how to apply a principle and you will most likely be told “it depends” followed by a long explanation.

Does this mean that we cannot create rules for design? To some extent it does. There are certainly some rules that designers follow but mostly designers rely on principles and guidance.  And that’s an issue we need to address because, let’s face it, not everyone in an organization has the time or inclination to become expert in UX design. Yet we want to effect cultural transformation where everyone has, at a minimum, an appreciation of design and understands how the design process is conducted and where it fits in their work.

The first step is to explore why there are so few rules for design. To understand why design lacks rules, we can look at the nature of the problems to which we apply design thinking.

Problems

Design thinking is an approach to solving problems.

The term problem is a broad concept that we use to mean “a question that is a subject for inquiry and solution.” A problem is not necessarily unwelcome or harmful – deciding what to do with the money you just won in the lottery is a good problem to have. A problem may be something we want to correct, something we want to achieve, a situation we want to affect, or an opportunity we hope to realize. Whether a problem is large, small, good, or bad, its central characteristic is a desire to change the current situation.

In the world of experience design, the solution is usually based around a digital product. A digital product may include websites, software applications, hardware devices, and services. Whatever form it takes, the product is something that people interact with to achieve some goal.

The result of solving a problem is a solution. The ideal of the project team is to produce the best possible solution in the most cost effective and timely manner. The reality is that in an imperfect world, it’s a lot to ask. To, the project team must understand the nature of the problem and design a plan for solving it. They then need to execute on the plan, making consistently good decisions and mid-course corrections where needed. Their success will depend on the product they deliver.

The first step is to understand what type of problem you are dealing with. Understanding the type of problem helps you define an approach to solving it.

There are obviously many ways to describe a problem. One common dimension is urgency. The way you approach an urgent problem will usually be different from the way you would approach a lower priority problem.

Another common dimension is financial size.

A really interesting dimension for describing problems is certainty vs. uncertainty. A powerful way to look at problems is by how clear the path to a solution is.

Consider these four problems:

• I want to read but the room is dark, so I switch on a light.
• My new business lacks a website. I hire a designer and we develop a killer site.
• I’m committed to world peace. I begin contributing monthly to an organization that builds political bridges.
• I walk past the supply room and see smoke billowing out of a closet.

In all of these problems, there is a situation I want to change and a solution I am working towards. But these problems are quite different in how you would approach them.

Each of the four problems is an example of a different type of problem as defined by a taxonomy proposed by David Snowden and Mary Boone (Snowden & Boone, 2007). Their concept is to divide problems into four types based on the amount of uncertainty or ambiguity that needs to be overcome to get to a solution. We will call the four types of problems: rule-based, design-based, research-based, and chaotic.

Straightforward problems: rule-based approach

The first type of problem is one where the solution simply requires you to properly apply a set of rules to get to the solution. Solving the problem:

I want to read but the room is dark, so I switch on a light.

requires application of a simple rule – turn on the switch. Applying the rule leads straight to the solution. Similarly, the example we used earlier of a cashier making change can be solved by knowing the rules and applying them correctly.

The fact that the path to solution is rule-based, does not guarantee success. If the light is burned out, flipping the switch will not bring about the desired change. If the cashier runs out of change, they cannot complete the transaction. But once you have to deal with the situation, you no longer have a straightforward problem.

Not all straightforward problems are that simple. Making out a tax return can take a lot of time and effort but there are a clear set of rules, and taxpayers who want to avoid trouble follow them carefully.

Straightforward problems that can be solved by the application of rules are the basis of operational processes. In information technology they are often called business rules.

Most of the everyday problems we face are straightforward and that’s a good thing. We don’t have to spend a lot of time and energy solving everyday problems. What we must do is to understand the rules, select the correct rule and apply it properly. This may take a lot of knowledge and training, which is why many people leave their tax returns to an accountant.

Development problems: design-based approach

Many business problems require development of a solution. In particular, digital products like websites and software require a design-based solution.

My new business lacks a website. I hire a designer and we develop a killer site.

The problem of creating a website cannot be solved by rules. There are many possible paths and many points where the choices you make deeply affect the outcome.

With a competent team and adequate resources, a solution is possible. Almost certainly the website will be built. How effective it will be won’t be fully known until it’s released. There is no metric by which I can compare alternative solutions; I cannot say, for example, that the website is 75% of ideal. This is one place where the answer to most important questions is “it depends.”

While there is a fair amount of uncertainty about the best solution, the approach to development is clear. To get to a workable solution, we will have to do a lot of information gathering and explore alternate ideas. Many aspects of the site must be designed. The visual appearance, the navigation, the content presented and the interactions with the user all need to be designed. And while you are pretty much guaranteed to come up with something, creating a website that meets the objectives of the business and which users find useful and engaging makes this a complex problem.

Development problems are generally tractable. If you assemble a team with the right skills and give them the time and resources they need, you will most likely design and implement a good website. If you manage the process really well, you will likely achieve an excellent result. But there is no way to know if the solution you have designed is optimal. And as any author, songwriter or entrepreneur will tell you, developing a fine product is no guarantee of market success.

Wicked-problems, research-based approach

Rule-based problems and design-based problems account for many of the problems that organizations solve. But there are a class of problems that are more uncertain. We call these wicked problems and they require research to, hopefully find a solution.

I’m committed to world peace. I begin contributing monthly to an organization that builds political bridges.

World peace — is impossibly complex and difficult. No one knows how to do it or if any particular effort will help or even have negative effects.

The term “wicked problem” was suggested by Horst Rittel to refer to problems that are not well understood (Churchman, 1967). With wicked problems you may not know if what you are doing is bringing you closer to a solution or if you are headed toward a dead end. You may not even recognize a solution when you see it.

Organizations encounter various types of wicked problems

Business problems related to strategy and innovation are often wicked problems. John Cammilus notes that “Wicked problems often crop up when organizations have to face constant change or unprecedented challenges” (Cammillus, 2008).

What makes strategic problems wicked is the need to predict the future based on an imperfect understanding of many complex dimensions, We can research deeply and make informed guesses but we will not know how good our predications are until we see what actually happened.

 

Developing highly innovative digital products that involve artificial intelligence may also be wicked.

Some wicked problems are the domain of research scientists. Finding a cure for cancer, an alternative to antibiotics, ending climate change and building AI systems that hold meaningful conversations with people, are all examples.

Not all wicked problems are so complex. Product development and marketing are everyday examples of wicked problems. There Is no way to predict if a new product will be a hit. Clayton Christensen in The Innovator’s Dilemma, points out many examples of companies that do everything “correctly” and still fail in the marketplace (Christensen, 1997).

Sometimes a wicked problem can be solved in a blaze of insight but most often you chip away at it, solving aspects of the problem. You try to break the larger problem into less complex sub-problems in the hope that you can solve them and simplify the larger problem.

In doing this you reduce the ambiguity of the problem space.

Chaotic problems: command and control

The most uncertain problems are situations which are out of control:

I walk past the supply room and see smoke billowing out of a closet.

This is an example of a chaotic problem. There is little time for study and analysis, what is needed is action that can reassert control as quickly and with as little damage as possible.

Chaotic problems are ideally handled by professionals whose training and experience enables them to act in a constructive way using command and control. The goal is to reduce the chaotic problem to a development problem. Once the fire in the supply closet is out, it becomes possible to consider alternative paths and repair the damage.

Simplifying Problems

The classification scheme we have presented classifies problems based on the their uncertainty or ambiguity. As we solve problems, they become less ambiguous. For example, protecting people from the devastation of smallpox was once a wicked problem. No one knew how to solve it or if it could be solved. Then the work of Edward Jenner led to a vaccine and the problem was reduced to a straightforward one (Reidel, 2005).

As another example, think about the invention of the airplane. At first it was a wicked problem; no one was sure if it could be accomplished or how to do it. The illustration shows a design for an airship by the Italian monk Francesco Lana-Terzi, S.J. about 1670 (MacDonnell, n.d.). Lana-Terzi’s model was mathematically sound but could not be constructed with the materials available in the 17^th century. Over the years, many partial solutions were found, and sub-problems solved. Today, the design of a new jetliner is a (very) complex problem. As knowledge about aviation developed, the problem of designing an airplane shifted from a wicked problem to a complex one.

Why Design Has Few Rules

Every day we are confronted by a slew of problems. Many are straightforward and can be easily managed. In an organization; many of these straightforward problems are seen as transactions rather than problems. Organizations manage operations by developing processes and rules and training staff to perform them. Design is part of the process development but has little to do with straightforward operations.

But organizations also face many problems which are complex or wicked and in which design plays a major role. Examples of common complex problems are selecting or building software, web design, business process engineering, service design, and policy design. There are fewer wicked problems but research, marketing and strategy, are three areas where wicked problems pop up.

In the real world, it is common for projects to encounter elements of all three types of problems. Perhaps that is why there is so much uncertainty in project management.

Straightforward problems can be solved by the application of rules. Complex and wicked problems are solved by some form of design thinking. Since these types of problems cannot be solved with rules, the answers to design questions is almost always “it depends.”

For some people, the paucity of rules for design is not a problem; in fact, it’s a plus. Designers relish the freedom to innovate and the fewer constraints, the better. That’s fine on an individual level but a problem for organizations who want to build a design culture.

Building a design culture is essential for many organizations in this time of digital transformation where virtually every process and interaction is, in some way, digital. Poor design and usability problems are detrimental to the efficient running of the entire organization. The solution is to create a design aware staff who can infuse design thinking into every project. But gaining design proficiency requires learning a substantial body of knowledge and building skills through practice and mentorship. This is a type of training that is difficult to manage and does not scale well because beginners need a lot of attention and feedback.

What Can We Do?

We can’t create rules, but we can agree on principles and guidelines. We can teach them but until learners see how they operate in actual projects, they will tend to remain abstractions. As we saw earlier, principles don’t generally come with actions attached. And that is a gap we need to fill.

If our goal is to integrate design thinking into projects and foster a design culture as a core organizational competence, we must be able to communicate the design process in project-specific terms. Generalities won’t do it.

It is not necessary to turn everyone into a designer any more than it is necessary for everyone involved with digital projects to learn programming. At a minimum, we want everyone to be design aware so that they understand the arc of the design process and how it relates to their own work.

The audience for this kind of understanding is extensive. It includes developers and product owners who must work with designers or who have to do their best without one. It includes project managers who need to integrate the design process into the larger project. And it includes senior managers who decide on funding priorities and develop strategy.

Design “Doing”

Design thinking is an approach to problem-solving. “Design doing” is the operationalization of design thinking – applying it to projects. Design doing requires more than a superficial understanding of how design is done.

When skilled designers are presented with a problem, they can visualize the path that leads to a well-designed product. They are able to anticipate the important decisions that they will need to make and have the skills and knowledge to evaluate the alternatives and project the effect. IN Steven Covey’s words, they are able to “start with the end in mind.”

Those less skilled in design thinking struggle make the transition into design doing and need support. This situation arises when, for example, a developer or product owner is pressed into a design role that they are unprepared for. It also arises when designers are negotiating with stakeholders who are trying to understand the design process, so they can make appropriate decisions.

For example, as part of a larger project, a designer might be given the job of creating personas for customers. Given the complexity of this process, we should not be surprised when non-designers find an assignment like this overwhelming. However, a skilled designer would understand how to develop a plan like this one:

1. Understand the business need. Consider: Why are we creating these personas? How will they be used? What information would be most valuable?
2. Develop an audience research plan. Decide how to collect the information. Decide who will be studied or interviewed. Plan the data gathering.
3. Recruit participants and conduct interviews.
4. Analyze the results, much of which will be qualitative. Perform content analysis. Look for themes. Identify similarities and differences.
5. Synthesize what you have learned into several personas. Build an initial set of personas. Divide into primary and secondary.
6. Validate the personas. Refine them and iterate if needed. Decide how you will evaluate the personas. If needed, gather more data and refine.
7. Format and deliver them. Produce the personas in an appropriate format and introduce them into the project.

Framework

When you look at the simple project plan for personas, you can see a number of structural elements:

1. There is an overall logic and flow to the process.
2. There are seven distinct tasks. Each contains a number of steps.
3. There are many questions and decisions that need to be addressed. For example: what are our goals, who should we talk to, and what data will we need.
4. There are specific techniques that will be employed such as: planning and conducting interviews, analyzing qualitative data and formatting personas.

By laying these out, we can offer non-designers a framework that guides them through the design process. Producing a framework is relatively simple. All you need is:

1. A roadmap that lays out the flow and tasks.
2. A description of each step that is detailed and actionable enough so that the learner can execute on it.
3. Tools and decision-support aids that guide the learner through the techniques.

If every project were radically different, there would not be a lot

Roadmaps Show Flow and Tasks

The first thing that the non-designer needs to know is what does the project look like as a whole? This is sometime called the “view from 20,000 feet.” It’s important because it provides a context to understand the process.

Here is a roadmap for the persona development project:

The graphic provides the learner with a bird’s eye view of the entire project. Each task represented by a circle needs a description. The learner can explore a number of high-level questions such as:

1. What is the purpose of each step?
2. How long might each step take?
3. What important decisions will we have to make as we progress?
4. Who will be responsible for each step?
5. What problems or hurdles do we anticipate?
6. What will the final product look like?

These are examples and the number of questions in an actual project is likely to be more extensive. By answering these questions, we provide the learner with cognitive scaffolding that serves as context for the detailed work that they will undertake. That context makes the experience more meaningful.

As with the road trip, the learner can now explore the details at each step. This information does not have to be delivered to the learner all at once. That would be overwhelming for many. Instead we can deliver the information when initiating work on the specific step. Here area some examples of the questions that might be discussed. You will see that there is some overlap with the high-level questions, but the level of detail is higher:

1. What is the purpose of this step?
2. What information will we need?
3. What will we do?
4. How will we do it?
5. What decisions will we have to make?
6. What obstacles or hurdles might we encounter?
7. What will the deliverable or output of this step look like?
8. How will it be used?

Of course, the questions for each step can be more project specific.

Tools

There is yet another level of support we can develop. Within a step, the tasks can be fairly complex. For example, we might have the task: develop an interview protocol so we can gather the data for the personas.

Knowing how to develop a useful interview protocol takes some understanding of how to formulate the questions to gather the best possible information. Here a job aid or tool is valuable.

Job aids can be constructed for activities and decision-support. They can be as simple as a paper document or as elegant as an interactive tool with embedded just-in-time training. The job-aid starts to come close to the function of rules. It serves to guide the learner through the process step-by-step.

Summary

The problem we set out to explore was why so many of the questions people have about design have the unsatisfying answer “it depends.” We identified the source of the problem as inherent it complex and wicked problems which cannot be addressed by the application of rules.

To explain the process of design to non-designers so they can participate in design project or even do the design work, we propose a framework that at a high-level lays out the steps of the project as a directed graph or roadmap.

Each node on the graph corresponds to a major design task. The details of each design task can be explained and the specific activities are supported by job aids which incorporate just-in-time training.

The goal of this process is to provide the non-designer with the knowledge needed to understand the design process and the support needed to allow them to execute the activity or make a decision successfully.

Bibliography

Babich, N. (2018, Jan. 18). The 15 Rules Every UX Designer Should Know. Retrieved Nov. 12, 2018, from Adobe Blog: The 15 Rules Every UX Designer Should Know

Christensen, C. (1997). The innovator’s Dilemma. Cambridge: Harvard Business School Press.

Churchman, C. W. (1967). Wicked Problems. Management Science, 14(4), B141-B142.

Design Management Institute. (2016). The Value of Design. Retrieved from Design Management Institute: https://www.dmi.org/page/DesignValue

Reidel, S. (2005, Jan.). Edward Jenner and the history of smallpox and vaccination. Proveedings of the Baylor University Medical Center, 18(1), 21-25.

Snowden, D., & Boone, M. E. (2007, November). A Leader’s Framework for Decision Making 69–76. PMID 18159787. Harvard Business Review, 85(11), 68-76.

 

 

Appendix A

Taxonomy of Problem Types

	STRAIGHTFORWARD PROBLEMS	COMPLEX PROBLEMS	WICKED PROBLEMS
Level of Ambiguity or Unknowns	Low. There is a procedure or algorithm that leads to the solution.	Medium. There are many possible solutions. Good practice will produce (at least) an acceptable solution.	High. There are many unknowns and the
Certainty of Solution	High. Applying the correct rules will lead to a solution.	High. With a competent team and adequate resources	Low. You do not know if the problem is solvable.
Method of Solving	Follow the Process. Locate the appropriate procedure or algorithm and do what it says.	Design & Implement. Assemble a team. Work through the problem. Implement, validate and deploy the solution.	Research. Divide the problem into smaller and more tractable sub-problems. Simplify through the reduction of unknowns.
Example	You want chocolate chip cookies. You pick a recipe, follow the instructions and enjoy the cookies when they’re done.	You want to develop your own special recipe for chocolate chip cookies so you can start a business. You start with a basic recipe, make changes, taste test. Keep working on it until you have one you believe will sell well.	You want to develop cookies from algae as a new food source. You begin by attempting to create some form of useful and safe algae flour. This requires many experiments. If you are successful, you will then turn to discovering how to flavor it.

 

Most of the time, problems that are solved in business are complex ones.

One way to look at design is that we start with a problem and work towards a solution. Between the problem and the solution there is ambiguity. You can visualize the design process like this: