Is design a problem solving process? To answer "No" suggests that designers do not produce solutions to design problems. However, in order to produce such solutions, designers must first frame—and typically reframe—the problem. Understanding this can help newcomers recognize the need for a different approach, rather than jumping straight to solutions. What does it mean to frame a problem? In this chapter, detailed below, I define it as follows:

Problem framing: To take ownership of and iteratively define what the problem really is, decide what should be included and excluded, and decide how to proceed in solving it.

To understand what problem framing looks like in practice, this chapter introduces and illustrates key terms that help us speak consistently about design problems and how they differ from other problems. Vignettes highlight how designers direct their problem framing process. The chapter concludes with tools for framing problems and diagnostics for common pitfalls.

The Problem of the Problem: What Makes Design Problems Different from Other Problems?

Most of us have had abundant opportunities to solve problems, beginning in elementary school. But these problems were predominantly well-structured (Jonassen, 2000), meaning there was a single correct answer and the instructor knew what that answer was. Repeated experiences with such problems can lead us to privilege accuracy and efficiency over spending time dwelling with the problem. And surely getting to the right answer quickly is valuable in many situations. But design problems differ—there is not a single right answer or even a best way to come to a solution.

As a result, when tackling these ill-structured problems we must first frame them (Jonassen, 2000). Framing a problem involves defining the problem and bounding it, then deciding what to include and exclude and how to proceed (Dorst & Cross, 2001; Schön, 1983). This, in turn, relies on activities described in other chapters in this text, including the following: (a) gathering information about the task, learners, and context; (b) generating tentative ideas about the problem and solution; (c) making and revising decisions about the problem (often influenced by precedent); and (d) evaluating tentative ideas in light of design requirements and learner needs. Some therefore treat problem framing as a higher-level category that includes all of these activities. Others treat problem framing as an activity threaded through the design process. Regardless, problem framing is the process by which designers take ownership of a problem. This means that two designers, given identical design briefs, would not only produce different solutions, but would have solved different problems (see Figure 1.; cf., Dorst, 2003; Harfield, 2007).

Figure 1

An Example of How the Same Initial Problem may be Framed and Solved Differently

To see how this might play out, try finding multiple problems in the scenarios below (Table 1). Can you frame the problem as an instructional design problem? Can you also frame the problem not as an instructional problem?

Once you have framed possible problems in the scenarios, consider the ill-structuredness, complexity, and domain specificity of each problem (Jonassen, 2000). Each problem you framed may differ in these dimensions (Figure 2):

• Structure refers to the degree to which a problem has a single solution and most-efficient solution path (well-structured) or many possible solutions and solution paths (ill-structured). Problems are sometimes presented to instructional designers as well-structured, but design problems are ill-structured by definition.
• Complexity refers to the number of variables involved and how interrelated they are. Most—but not all—design problems are complex. This characteristic can be tricky to assess simply because we use the term informally as a synonym for “difficult.”
• Domain specificity refers to whether domain general strategies would suffice; Jonassen (2000) described domain specific problems in terms of both “abstract” and “situated,” knowledge, generally placing such knowledge in formal domains. Almost all ID problems are domain specific.

Table 1

Framing Both Instructional Design and Other Problems

Figure 2

Problem Structure, Complexity, and Domain Specificity Differentiate Between Problem Types

Note. Design problems are always ill-structured, and usually complex and domain specific. The letters refer to the problems above related to scenario 1 in Table 1.

How Do Designers Frame Problems?

Problem framing can occur through both overt and covert activities. Some activities and deliverables make the problem visible, but other problem framing work happens through talk or individual thinking. Covert framing activities involve abductive reasoning—filling in gaps in knowledge (e.g., Kolko, 2010). This kind of thinking is heavily influenced by past precedent, and designers contend with the salience and limitations of their own experience.

From their first contact with the problem, designers consider whether the problem seems like one encountered previously and how the current problem seems to differ from past precedent.

Their framing of the problem is visible in the project objectives and learning goals they set. As they seek to understand and explore, researching the task, context, learners, and possibly other precedents, they reframe the problem and consider whether the client will accept their reframing, which is made visible in learning objectives and problem statements. Prototypes may likewise reveal their problem framing. Evaluation of a prototype’s feasibility, desirability, and ability to meet identified learning needs may lead to further reframing.

Clients often undervalue and underestimate the time and effort needed to frame the problem. Clients may request a specific deliverable or solution, yet may not have a deep understanding of the actual needs. Making a value proposition can sometimes help. This means communicating clearly about what problem framing is and why it can benefit the organization by preventing ineffective training.

What Does It Mean to Have Agency to Frame a Design Problem?

Experienced designers—regardless of discipline—know to direct their framing of the problem. They make consequential decisions that lead them to new understandings and reframings of the problem. This “framing agency” is a hallmark of design in which designers rely on information they gather and on their past precedent—as described in other chapters of this volume. What does framing agency look like in practice?

In the case below (Figure 3) a team faces some challenges in part because not all members understand that they need to frame the problem; this is visible in their expectations about their roles and in their talk. In the vignettes, words are highlighted to draw attention to ways the team members are talking that help us notice whether they are framing the problem or not. Designers often share framing agency with other designers, with envisioned stakeholders, and sometimes even with the materials in their designs. In ID, this happens when they reference the learning and transfer contexts, and the modes of learning (e.g., face-to-face, online, etc.) to justify decisions. Another indicator of framing agency is staying tentative, staying with the problem. Using verbs that show possible actions (e.g., could, might, etc.) and hedge words (e.g., maybe, kind of, etc.) invites both the designer and others to revise their thinking about the problem. In contrast, using verbs that show a lack of control (have to, need to, etc.) over the situation tends to shut down problem framing, unless the verb refers to a design requirement (like Yen’s use on “need to” in vignette 2).

Read through the vignettes in figure 3 and answer the following questions:

• Who treats the problem as not needing to be framed?
• How does the instructional designer encourage them to frame the problem?
• Who else shows framing agency?

Figure 3

Vignettes From a Design Team: Who Shows Framing Agency? Who Does Not?

Learning to notice how you talk with your team may help you diagnose whether or not you are framing the problem. When someone sounds tentative, consider it an invitation to engage in framing with them. Try to avoid no-control talk that shuts down problem framing.

What Tools Help Designers Frame Problems?

Mapping unknowns, assumptions, and conjectures can help clarify the work needed to frame problems. In addition to the tools that other chapters in this text have offered, I have found the following tools help make problem frames explicit yet open to revision:

• Problem statements
• Storyboarding
• KWL charting
• Design conjecture maps
• Root cause + sphere of influence analysis

It is important to remain tentative in using these tools. Just as we saw with design talk, staying open to revision is key. For this reason, I typically use pencil and paper or whiteboards for these kinds of activities. Rather than polishing and perfecting them, staying in draft mode can help you stay open.

Problem Statements

Problem statements are concise and provide clarity about the problem frame. Your problem statement should begin with one or two sentences describing a vision of what is possible if the problem is solved. Next, describe—in one to two sentences—what the specific issues are. This should include who, what, when, where and why. Finally, in one to two sentences, describe the primary symptoms of and evidence for the problem. You should not include a solution! Expect to write your problem statement multiple times to capture changes in your understanding of the problem.

Problem Statement Worksheet

Storyboarding

Vividly depict the problem—not the solution—as a sequence of events from a particular point of view. You may hand draw this, use photos, use a graphics program, or try out one of the many free storyboard/comic strip creation websites (see Additional readings and resources). When depicting the problem, consider other points of view, and represent these in another storyboard, with thought bubbles, or as a branching storyline. Avoid depicting the solution!

KWL Charting

KWL charting is adapted from tools commonly used in project-based learning classrooms and supports learners to identify what they do and do not know, as well as what they still need to know (Ogle, 1989). This tool is useful for designers as they manage the ambiguity of the design problem. Using it frequently as a means to track progress can help teams direct their own progress in bringing information into the problem.

Table 2

Example of KWL Charting

Design Conjecture Maps

Design conjecture maps are based in tools like logic models and design-based research conjecture maps (Sandoval, 2014). They help designers coherently link the task to learning objectives and to their design ideas. First, place the learning objectives on the same page as the task analysis, then make links between them. Second, after generating tentative ideas, try connecting these to the task analysis and learning objectives using yarn or string. Third, as you begin to develop more solid designs, try connecting these back to the task analysis and learning objectives.

Design Conjecture Mapping

Root Cause Analysis

Root cause analysis techniques, like the five whys (Ohno, 1978; Serrat, 2017), can help designers identify underlying causes rather than treating symptoms. While some use this approach to craft a linear set of causes and effects, creating a network of whys is more effective for framing problems from multiple points of view. In this way, for each problem, you should ask “Why does this happen?” and “Why else does this happen?” This results in a network of possible root causes. Pairing this analysis with sphere of influence analysis—meaning, deliberately analyzing whether each cause is within your capacity to influence the problem through instructional design—provides an opportunity to consider the feasibility and impact for any particular cause. To do this, for each cause you should consider whether it is a problem you can influence and whether it is an instructional design problem (Figure 4). Which of these causes suggest an instructional design problem?

Figure 4

Example of the Five Whys as a Network

Do-It-Yourself

Now that we have learned about several tools, here are some specific ways you can apply these. First, you can try out the tools in the previous section using the scenarios above in Table 1. Second, if you are in a class that includes developing an instructional design, you can use these tools for your class. When teaching instructional design, I always require students to work for clients on real design projects because I have observed issues that come up without clients. Students spend as much or more time inventing fake clients as they would learning how to assess needs. Without a real client and context, it can be hard to learn to frame problems authentically, to really understand that even though you are designing something for others, by framing the problem, you are taking ownership of it. That is challenging to do if it is a problem of your own invention. Likewise, without a client, the reasons for reframing are likelier to stem from challenges you encounter than new understanding of the problem space. Of course, working with real clients can be challenging in other ways. Make sure your client understands that you have course deadlines and are just learning to design. Agree on the scope of work beforehand using a formal design brief.

Conclusion

While problem framing is typically treated as something that happens at the beginning of a design project, it is important to remember that it is a process that continues until the design is finalized. You may revisit and revise along the way, especially for short deliverables like problem statements and KWL charting. Prototypes, especially low fidelity prototypes, and evaluation often reveal the need for reframing. And, as contexts and needs change by location or over time, a solution may no longer function, and the problem can pop back open. In considering the iterative nature of problem framing, how will you use these tools to guide and document reframings of the problem?

Finally, my advice to you as new designers is this: Dwell with the problem. Wallow in some uncertainty. Stay tentative!

Acknowledgments

This material is based upon work supported by the National Science Foundation under Grant No. EEC 1751369. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author and do not necessarily reflect the views of the National Science Foundation.

References