Problem Framing PDF

6 Problem Framing Vanessa Svihla 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...

6 Problem Framing Vanessa Svihla 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 81 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 Scenario Management at a chemical plant identifies that the most expensive chemical is not typically used 1 efficiently, unless it is used under specific conditions. They contract an instructional designer to create a job aid to ensure the chemical reactor is operated optimally. The reactor includes 15 stages, six chemicals, and gauges for setting pressure, temperature, and rate at each stage. Data suggest workers tend to apply settings from a similar reactor, resulting in waste. Scenario Beth is hired by a dietician to create instructional materials—printed handouts—for parents/guardians of 2 children with special dietary needs based on a specific disability. The dietician provides published, effective dietary standards based on the specific disability and shares that some of the terms in the standards are hard for families to understand. The production budget is small and timeline tight. The organization provides a set of images they previously created and want used in the handouts. Scenario A university’s instructional technologies committee selects and implements a learning management 3 system (LMS), heavily guided by their own expertise, along with issues related to copyright law, tight institutional budget concerns, and interfacing with systems for registration and grading. As a consequence, instructional designers are hired primarily based on their capacity to provide technical support for the cumbersome, difficult to use LMS. To ensure they can support the faculty, they create a highly structured course shell. Scenario A district purchases science kits and curricula for teachers in Phoenix, AZ. While the resources seem 4 useful, the teachers realize there are issues. For instance, the curriculum teaches "Fall is when the leaves 82  change colors," but the teachers know their students have never seen leaves change color. They meet during a cross-school professional development session to address these issues, guided by curriculum leads who graduated from an instructional design program. Scenario An instructional designer is tasked with migrating courses from a decommissioned LMS to a newly 5 adopted one. None of the content or sequencing is to be changed. The two LMSs differ greatly in many ways (e.g., how objects are connected to courses, the order in which settings must be selected, and the number of features available). 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. 83  How might you convey to a client why framing the problem is important? 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? 84  If you are on a team that is resisting framing the problem, how will you communicate with your team? Using the key in Figure 3, how can you use tentative language to invite them to frame the problem with you? How will you help them understand the importance of framing the problem? 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 85 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 Date What do we know about the design What precedent do we want to What do we want to learn problem, learner needs, and other (or not want to) bring into the about the problem and how requirements or constraints? problem? will we learn it? 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 86 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. 87 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! Additional Readings and Resources Problem Framing Resources Gause, D. C., & Weinberg, G. M. (1990). Are your lights on? Dorset House. ISIXSIGMA Atlassian Root Cause Tools Google Drawings Draw.io MindMeister Mindomo Coggle.it Edrawsoft MindMup LucidChart Storyboarding Tools Storyboard That Pixton Witty Comics Strip Generator Make Beliefs Comix 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 Dorst, K. (2003). The problem of design problems. Design Thinking Research Symposium, Sydney, 17(19.11). 88 Dorst, K., & Cross, N. (2001). Creativity in the design process: co-evolution of problem-solution. Design Studies, 22(5), 425-437. doi:10.1016/S0142-694X(01)00009-6 Harfield, S. (2007). On design `problematization': Theorising differences in designed outcomes. Design Studies, 28(2), 159-173. doi:10.1016/j.destud.2006.11.005 Jonassen, D. H. (2000). Toward a design theory of problem solving. Educational Technology Research and Development, 48(4), 63-85. doi:10.1007/BF02300500 Kolko, J. (2010). Abductive thinking and sensemaking: The drivers of design synthesis. Design Issues, 26(1), 15-28. doi:10.1162/desi.2010.26.1.15 Ogle, D. M. (1989). The know, want to know, learn strategy. Children’s comprehension of text: Research into practice, 205-223. Ohno, T. (1978). Toyota production system: Beyond large-scale production. Vol. 1: Cambridge, MA: Productivity Press. Sandoval, W. (2014). Conjecture mapping: An approach to systematic educational design research. Journal of the Learning Sciences, 23(1), 18-36. doi:10.1080/10508406.2013.778204 Schön, D. A. (1983). The reflective practitioner: How professionals think in action. New York: Basic Books. Serrat, O. (2017). The five whys technique. Knowledge solutions (pp. 307-310): Springer. Vanessa Svihla University of New Mexico Dr. Vanessa Svihla is an assistant professor at the University of New Mexico with appointments in the learning sciences and engineering, and she directs the Interaction and Disciplinary Design in Educational Activity (IDDEA) Lab. Her research has been supported by the NSF and USDA, and she was selected as a 2014 National Academy of Education / Spencer Postdoctoral Scholar. Dr. Svihla received her MS (Geology) and PhD (Science Education) from The University of Texas at Austin. She served in the Peace Corps and was a post-doctoral scholar at UC Berkeley. She draws inspiration from her own practice in fashion design and instructional design, as her research focuses on how people learn when they design. She is particularly interested in how people find and frame problems, and how these activities relate to identity, agency and creativity. 89 This content is provided to you freely by EdTech Books. Access it online or download it at https://edtechbooks.org/id/problem_framing. 90