View in EDS HTML Full Text PDF Full Text

Encouraging Engineering Design Teams to Engage in Expert Iterative Practices with Tools to Support Coaching in Problem-Based Learning

Saved in:
Bibliographic Details
Title: Encouraging Engineering Design Teams to Engage in Expert Iterative Practices with Tools to Support Coaching in Problem-Based Learning
Language: English
Authors: Rees Lewis, Daniel G. (ORCID 0000-0002-0928-3831), Carlson, Spencer E., Riesbeck, Christopher K., Gerber, Elizabeth M., Easterday, Matthew W.
Source: Journal of Engineering Education. 2023 112(4):1012-1031.
Availability: Wiley. Available from: John Wiley & Sons, Inc. 111 River Street, Hoboken, NJ 07030. Tel: 800-835-6770; e-mail: cs-journals@wiley.com; Web site: https://www.wiley.com/en-us
Peer Reviewed: Y
Page Count: 20
Publication Date: 2023
Sponsoring Agency: National Science Foundation (NSF), Division of Information and Intelligent Systems (IIS)
Contract Number: 1530833
1530837
Document Type: Journal Articles
Reports - Research
Descriptors: Engineering, Design, Coaching (Performance), Problem Based Learning, Problem Solving, Expertise, Teaching Methods, Metacognition, Engineering Education, Cooperative Learning, Planning, Risk
DOI: 10.1002/jee.20554
ISSN: 1069-4730
2168-9830
Abstract: Background: To create design solutions experienced engineering designers engage in expert iterative practice. Researchers find that students struggle to learn this critical engineering design practice, particularly when tackling real-world engineering design problems. Purpose/Hypothesis: To improve our ability to teach iteration, this study contributes (i) a new teaching approach to improve student teams' expert iterative practices, and (ii) provides support to existing frameworks--chiefly the Design Risk Framework--that predict the key metacognitive processes we should support to help students to engage in expert iterative practices in real-world engineering design. Design/Method: In a 3-year design-based research study, we developed a novel approach to teaching students to take on real-world engineering design projects with real clients, users, and contexts to engage in expert iterative practices. Results: Study 1 confirms that student teams struggle to engage in expert iterative practices, even when supported by problem-based learning (PBL) coaching. Study 2 tests our novel approach, Planning-to-Iterate, which uses (i) templates, (ii) guiding questions to help students to define problem and solution elements, and (iii) risk checklists to help student teams to identify risks. We found that student teams using Planning-to-Iterate engaged in more expert iterative practices while receiving less PBL coaching. Conclusions: This work empirically tests a design argument--a theory for a novel teaching approach--that augments PBL coaching and helps students to identify risks and engage in expert iterative practices in engineering design projects.
Abstractor: As Provided
Entry Date: 2023
Accession Number: EJ1396465
Database: ERIC
Full text is not displayed to guests.
FullText Links:
  – Type: pdflink
    Url: https://content.ebscohost.com/cds/retrieve?content=AQICAHj0k_4E0hTGH8RJwT4gCJyBsGNe_WN95AvKlDbXJGqwxwEaL9aQH-GhTPM8M6btKO3OAAAA4jCB3wYJKoZIhvcNAQcGoIHRMIHOAgEAMIHIBgkqhkiG9w0BBwEwHgYJYIZIAWUDBAEuMBEEDFoQwr7aUljowFYIywIBEICBmt0WJ9XKvkymMS21qVsTlvpGfHkDl08ATwDQkVq7hDTJQ9ItHPhRoT9uARyGBgNr1hi7z5ewxbSQolkpPf8dqiJewRo6cFH-UStXWtGK-rj82V1_ULoxlKJXjn-5FdJu7LR5Q5zoU7_ll8aS1xcqzxQfNaWMt_TnPqI7-I0Ajv94cZ9KS4qzzPnl-Vzz9TYdPwR7kXjKtYyQJWo=
Text:
  Availability: 1
  Value: <anid>AN0173054171;6m401oct.23;2023Oct20.06:18;v2.2.500</anid> <title id="AN0173054171-1">Encouraging engineering design teams to engage in expert iterative practices with tools to support coaching in problem‐based learning </title> <p>Background: To create design solutions experienced engineering designers engage in expert iterative practice. Researchers find that students struggle to learn this critical engineering design practice, particularly when tackling real‐world engineering design problems. Purpose/Hypothesis: To improve our ability to teach iteration, this study contributes (i) a new teaching approach to improve student teams' expert iterative practices, and (ii) provides support to existing frameworks—chiefly the Design Risk Framework—that predict the key metacognitive processes we should support to help students to engage in expert iterative practices in real‐world engineering design. Design/Method: In a 3‐year design‐based research study, we developed a novel approach to teaching students to take on real‐world engineering design projects with real clients, users, and contexts to engage in expert iterative practices. Results: Study 1 confirms that student teams struggle to engage in expert iterative practices, even when supported by problem‐based learning (PBL) coaching. Study 2 tests our novel approach, Planning‐to‐Iterate, which uses (i) templates, (ii) guiding questions to help students to define problem and solution elements, and (iii) risk checklists to help student teams to identify risks. We found that student teams using Planning‐to‐Iterate engaged in more expert iterative practices while receiving less PBL coaching. Conclusions: This work empirically tests a design argument—a theory for a novel teaching approach—that augments PBL coaching and helps students to identify risks and engage in expert iterative practices in engineering design projects.</p> <p>Keywords: coaching; design practice; design process; iteration; metacognition; problem‐based learning</p> <hd id="AN0173054171-2">INTRODUCTION</hd> <p>Iteration is critical in engineering design. Engineering design problems require iteration because they have many unknown problem and solution elements (Jonassen & Hung, [<reflink idref="bib36" id="ref1">36</reflink>]; Simon, [<reflink idref="bib71" id="ref2">71</reflink>]) Thus, design engineers continually engage in expert iterative practices to test and revise their solution to gain evidence that a given solution will work and to rule out seemingly feasible solutions that either will not work or people do not want to use (Knapp et al., [<reflink idref="bib37" id="ref3">37</reflink>]). When designers fail to iterate, they will likely waste significant time and other resources working on a solution that will not work (Blank & Dorf, [<reflink idref="bib9" id="ref4">9</reflink>]; Marks & Chase, [<reflink idref="bib43" id="ref5">43</reflink>]).</p> <p>To become effective design engineers, students must learn to iterate (Crismond & Adams, [<reflink idref="bib20" id="ref6">20</reflink>]). That is, students must learn the expert practice of gathering information and applying that information to simultaneously improve products and learn more about the problem (Adams et al., [<reflink idref="bib3" id="ref7">3</reflink>]; Atman et al., [<reflink idref="bib5" id="ref8">5</reflink>]; Wynn & Eckert, [<reflink idref="bib78" id="ref9">78</reflink>]). Design engineers iterate because the problems they are solving are highly ill‐structured, with an unknown solution or solution path (Jonassen, [<reflink idref="bib35" id="ref10">35</reflink>]), which requires iteratively developing and testing ideas to find a solution that solves the problem (Schön, [<reflink idref="bib65" id="ref11">65</reflink>]). However, existing research suggests that engineering design students struggle to engage in expert iterative practices that can improve their products (Adams et al., [<reflink idref="bib3" id="ref12">3</reflink>]; Lande & Leifer, [<reflink idref="bib40" id="ref13">40</reflink>]).</p> <p>The Accreditation Board for Engineering and Technology (ABET), the prestigious US accreditation agency for engineering education, requires that programs prepare students to iterate effectively in engineering design. ABET defines engineering design as "identifying opportunities, developing requirements, performing analysis and synthesis, generating multiple solutions, evaluating solutions against requirements, considering risks, and making trade‐offs, for the purpose of obtaining a high‐quality solution under the given circumstances." (ABET, [<reflink idref="bib1" id="ref14">1</reflink>], p. 7). Four of the seven criteria directly address the need for engineers to design solutions that people can and want to use and then employ this information to improve both their design and their understanding of the design problem. This emphasizes the criticality of expert iterative practices to address real‐world design problems. Specifically, the ABET criteria address the need for engineers to conduct experiments, understand the context in which they are designing, and communicate with a range of audiences. The US National Academy of Engineering report, entitled <emph>The Engineer of 2020: Visions of Engineering in the New Century</emph>, argued that the engineers of tomorrow must be equipped with the skills necessary to address real‐world challenges holistically (NAE, [<reflink idref="bib48" id="ref15">48</reflink>]). Together, these reports emphasize the criticality of expert iterative practices to address real‐world design problems.</p> <p>Theoretically, problem‐based learning (PBL) coaching could be an effective way to teach students to engage in expert iterative practices. PBL coaching is an educational approach in which a coach helps student teams during problem‐solving. The coach does so by helping student teams to identify gaps in their knowledge and form questions to close these gaps (Hmelo‐Silver, [<reflink idref="bib30" id="ref16">30</reflink>]; Hmelo‐Silver & Barrows, [<reflink idref="bib31" id="ref17">31</reflink>]). PBL coaching might help students to understand what information they need to gather and how to apply the information to improve their products. However, there is an open question as to whether PBL coaching can support students to engage in expert iterative practices in real‐world engineering design; Jonassen and Hung ([<reflink idref="bib36" id="ref18">36</reflink>]) argue that PBL coaching might not support teaching real‐world engineering design because the problems student teams face are so ill‐structured. That is, Jonassen and Hung ([<reflink idref="bib36" id="ref19">36</reflink>]) hypothesize that because there are so many interdependent undefined elements, students may need more than a coach to support effective engineering design practices, including expert iterative practices.</p> <p>In this paper, we present two studies that took place over 3 years in an undergraduate engineering design program. In Study 1, we employed a PBL coaching approach and started with the following research question: <emph>How can we augment PBL coaching to help students in the context of a real‐world engineering design class engage in increased expert iterative practices?</emph> We found that PBL coaching alone did not help student teams to engage in expert iterative practices; thus our research question progressed. After Study 1 and before Study 2, we conducted the Design Risks Framework (DRF) study, which suggested that we should create scaffolds that help students to <emph>identify risks</emph> as a key metacognitive process in expert iterative practices. Thus, in Study 2, we asked: <emph>How can we augment PBL coaching to help students in the context of a real‐world engineering design class to identify risks and will this lead to increased expert iterative practices?</emph> We compared the expert iterative practices across Study 1 and Study 2, thus also asking the more specific question: <emph>Did coupled revision, cascades, and vital conclusions increase from Study 1 to Study 2?</emph> We found students engaged much more frequently in expert iterative practices in Study 2.</p> <hd id="AN0173054171-3">BACKGROUND</hd> <p></p> <hd id="AN0173054171-4">Expert iterative practice in design</hd> <p>To design solutions that people can and want to use, engineering education and design studies researchers have developed a <emph>theory of iteration in design</emph>. Iterations are cycles of creation, testing, and then revision that can occur throughout the development of a given design (Adams et al., [<reflink idref="bib3" id="ref20">3</reflink>]; Atman et al., [<reflink idref="bib5" id="ref21">5</reflink>]; Marks & Chase, [<reflink idref="bib43" id="ref22">43</reflink>]). Wynn and Ekert's ([<reflink idref="bib78" id="ref23">78</reflink>], pp. 166–171) meta‐review of iteration includes conceptually discrete functions of (i) progressing toward completion, (ii) correcting errors, and (iii) coordinating people, decisions, and work. Progressing toward completion describes how teams gain more knowledge and build more of a design that might address the problem. Correcting errors describes how teams note how their design will fail and so need to redesign. Coordinating describes how iteration in teams and organizations necessarily involves actors working together, such as coming to shared understanding as iteration brings about new knowledge. We aim to create scaffolds that support iteration and address all three functions.</p> <p>Wynn and Eckert's ([<reflink idref="bib78" id="ref24">78</reflink>]) meta‐review also summarizes the types of iteration in progressing the design toward completion. <emph>Exploration</emph> involves iterating to initially define the problem and solution definition (Dorst & Cross, [<reflink idref="bib24" id="ref25">24</reflink>]) to manage how ill‐structured design challenges are when the problem is first tackled. <emph>Concretization</emph> involves iterating to "firm up" (p. 167) the parts of a design that have been previously decided upon. <emph>Convergence iteration</emph> involves investigating whether the design parts are meeting the set performance and seeking to optimize the design elements. <emph>Refinement</emph> involves iterating once there is evidence that the design meets its main goal—this iteration is focused on "secondary characteristics" (p. 167) that are not vital to achieving the main goal.</p> <p>We focus on supporting student design teams to learn to engage in expert iterative practices in the earlier stage of design, that is, iteration for exploration to define the problem and solution definition, an expert design practice involving gathering and applying information, often in the form of tests, to improve their solutions (Adams et al., [<reflink idref="bib3" id="ref26">3</reflink>]; Atman et al., [<reflink idref="bib5" id="ref27">5</reflink>]; Dorst & Cross, [<reflink idref="bib24" id="ref28">24</reflink>]). Helping students to engage in these expert iterative practices is critical for them to learn to take on highly ill‐structured problems (Boling et al., [<reflink idref="bib10" id="ref29">10</reflink>]; Nguyen et al., [<reflink idref="bib50" id="ref30">50</reflink>]). This theory of iteration for exploration emerged from Schön's theory of the <emph>reflective practitioner</emph> (Schön, [<reflink idref="bib65" id="ref31">65</reflink>])—emphasizing that expert designers frequently iterate by attending to the real‐world context and incorporating feedback from multiple sources.</p> <p>In this study, we use the term <emph>expert</emph> from the task analysis literature to denote target practices or ways of thinking drawn from studying experts (Crandall et al., [<reflink idref="bib18" id="ref32">18</reflink>]; Tofel‐Grehl & Feldon, [<reflink idref="bib75" id="ref33">75</reflink>]). Thus, expert iterative practices describe a set of practices that learners might realistically attain (Shaffer & Resnick, [<reflink idref="bib66" id="ref34">66</reflink>]) but are distinct from expert performance, which can typically only be attained after many years of practice.</p> <p>Empirical work shows that student design engineers do not iterate the way experienced designers do. Adams et al. ([<reflink idref="bib3" id="ref35">3</reflink>]) showed that expert engineering designers are much more likely than students to engage in <emph>coupled revisions</emph>—gathering information to simultaneously improve the solution and gain fuller understanding of the problem (Adams et al., [<reflink idref="bib3" id="ref36">3</reflink>]; Dorst & Cross, [<reflink idref="bib24" id="ref37">24</reflink>]). Coupled revisions incorporate Wynn and Eckert's ([<reflink idref="bib78" id="ref38">78</reflink>]) iterative functions of progressing toward completion—as engineering designers update their knowledge of the problem—and correcting errors—as engineering designers then propose fixes to their designs based upon this new knowledge. In supporting student engineering design teams to conduct coupled revisions together, we also seek to support Wynn and Eckert's ([<reflink idref="bib78" id="ref39">78</reflink>]) third function of iteration: coordinating people, decisions, and work.</p> <p>To inform coupled revision, experts tend to engage in more information gathering that inform revisions than students—a process Atman and colleagues called <emph>cascades</emph> (Atman et al., [<reflink idref="bib5" id="ref40">5</reflink>]). Cascades involve interleaving design activities including developing solutions, user interviews, and testing, which commonly inform coupled revisions (Atman et al., [<reflink idref="bib5" id="ref41">5</reflink>]). Compared to experts, students are less likely to view designing in a cascaded way as useful (Crismond & Adams, [<reflink idref="bib20" id="ref42">20</reflink>]; Mosborg et al., [<reflink idref="bib46" id="ref43">46</reflink>]), and therefore develop and test fewer solutions and gather less information than experts (Atman et al., [<reflink idref="bib5" id="ref44">5</reflink>]). This may be in part because students are more likely to think that they can solve design engineering problems "first time," without iteration (Lande & Leifer, [<reflink idref="bib40" id="ref45">40</reflink>]; Mosborg et al., [<reflink idref="bib46" id="ref46">46</reflink>]).</p> <p>Experts are also more likely to conduct experiments that help them to generate <emph>vital conclusions</emph> about their design (Blank & Dorf, [<reflink idref="bib9" id="ref47">9</reflink>]; Guindon, [<reflink idref="bib29" id="ref48">29</reflink>]), specifically, conclusions about their designs' <emph>relevance</emph>, <emph>effectiveness</emph>, and <emph>viability</emph> (Adams & Atman, [<reflink idref="bib2" id="ref49">2</reflink>]; Knapp et al., [<reflink idref="bib37" id="ref50">37</reflink>]; Smith & Tjandra, [<reflink idref="bib73" id="ref51">73</reflink>]; Wynn & Eckert, [<reflink idref="bib78" id="ref52">78</reflink>])—generating conclusions about whether the design can meet stakeholder needs, rather than superficial questions about their design. Here we define</p> <p></p> <ulist> <item> <emph>Relevance</emph> as conclusions about whether the design solutions address a significant problem that the stakeholders care about;</item> <p></p> <item> <emph>Effectiveness</emph> as conclusions about whether a given design would work; and</item> <p></p> <item> <emph>Viability</emph> as conclusions about whether a design can feasibly function within the context it is being created for.</item> </ulist> <p>Experts are more likely to practice design in a way so they can make vital conclusions, such as whether people can use the design in a way that leads to the desired outcome (effectiveness). Experts are less likely to immediately test something less central about relevance, effectiveness, and viability. According to Wynn and Eckert ([<reflink idref="bib78" id="ref53">78</reflink>]), experts do not focus on iteration for the sake of <emph>refinement</emph> if they have yet not understood other more vital areas of the design. It is worth noting that vital conclusions do not in themselves definitively show that a design is relevant, effective, or viable. Rather, experts seek to make evidence‐based conclusions about vital aspects of the design (Knapp et al., [<reflink idref="bib37" id="ref54">37</reflink>]; Smith & Tjandra, [<reflink idref="bib73" id="ref55">73</reflink>]).</p> <p>We use coupled revisions, cascades, and vital conclusions as measures of expert iterative practice as a comparison between student teams between Study 1 and Study 2.</p> <hd id="AN0173054171-5">Challenges for students iterating in engineering design</hd> <p>Students taking design classes often avoid iterating (Crismond & Adams, [<reflink idref="bib20" id="ref56">20</reflink>]; Lande & Leifer, [<reflink idref="bib40" id="ref57">40</reflink>]). Students face challenges both in terms of motivation and how to conduct effective expert iterative practices. Engineering education researchers have noted that students are often not motivated to iterate, as they believe that people can solve problems "first time" (Mosborg et al., [<reflink idref="bib46" id="ref58">46</reflink>]). This belief is compounded by the fact students might also overestimate the quality of the designs they create (Norton et al., [<reflink idref="bib51" id="ref59">51</reflink>]). As such, students might not believe that iteration is useful. Beyond motivation, researchers also argue that it is hard to conduct iterations in engineering design problems because these problems are so complex and ill‐structured. This means that there are many uncertain elements of the project to consider (e.g., user need, root cause of the problem). Thus, student engineering design teams might make one plan, but then be continually distracted by other elements of the project leading to "impulsively" moving between activities—what some engineering education researchers have called a "haphazard" process resulting in "little learning" about how to address the engineering design problem (Badke‐Schaub & Gehrlicher, [<reflink idref="bib7" id="ref60">7</reflink>]; Crismond & Adams, [<reflink idref="bib20" id="ref61">20</reflink>], p. 749). Conducting expert iterative practices for real‐world engineering design problems is so complex that some argue it may be too challenging for K–16 students (Jonassen & Hung, [<reflink idref="bib36" id="ref62">36</reflink>]).</p> <p>Given how challenging it is to support multiple student teams independently iterating on different real‐world engineering design projects (Rees Lewis et al., [<reflink idref="bib61" id="ref63">61</reflink>]), educators might be tempted to create learning environments where students only iterate at the very end of the class. One common approach in design education is to have student teams follow a "waterfall" approach in which they complete a step in the design process every 1–3 weeks, culminating in building and testing in the last few weeks of a class. Even expert engineering designers cannot predict what designs might work without iteration (Jonassen, [<reflink idref="bib35" id="ref64">35</reflink>]; Wynn & Eckert, [<reflink idref="bib78" id="ref65">78</reflink>]). Thus, the waterfall approach may teach students that engineering design is the practice of proposing designs that do not work at the end of a project. We argue against the waterfall approach for design education, as have others (Crismond & Adams, [<reflink idref="bib20" id="ref66">20</reflink>]), because it gives the wrong impression of expert design practice.</p> <p>We now discuss approaches for supporting student teams to engage in expert iterative practices.</p> <hd id="AN0173054171-6">Problem‐based learning coaching</hd> <p>We often teach engineering design to student teams through PBL coaching (Hmelo‐Silver & Barrows, [<reflink idref="bib31" id="ref67">31</reflink>]). PBL coaching appears to be an effective way to teach expert iterative practices in design engineering, although there is great variation to how PBL coaching is implemented (Azer et al., [<reflink idref="bib6" id="ref68">6</reflink>]; Hung, [<reflink idref="bib34" id="ref69">34</reflink>]). Research suggests PBL coaching helps student teams to learn disciplinary content equally well as approaches such as lecture, while being more effective at helping students to learn the practices of a discipline (Hmelo‐Silver et al., [<reflink idref="bib33" id="ref70">33</reflink>]; Prince & Felder, [<reflink idref="bib54" id="ref71">54</reflink>]). PBL is informed by theories of cognitive apprenticeship, which posits that we can support student learning through sustained engagement in expert practices (Collins & Kapur, [<reflink idref="bib17" id="ref72">17</reflink>]).</p> <p>PBL coaching involves cycles of helping student teams to first generate hypotheses, such as what designs might work, and then identify gaps in understanding and questions they must answer to reduce these gaps (Hmelo‐Silver, [<reflink idref="bib30" id="ref73">30</reflink>]; Tawfik & Kolodner, [<reflink idref="bib74" id="ref74">74</reflink>]). Thus, PBL coaches support student thinking by asking questions about key elements of the student team's project, such as their design, and the problem (Hmelo‐silver & Barrows, [<reflink idref="bib31" id="ref75">31</reflink>]). Furthermore, PBL coaches also make statements, such as summarizing what was discussed or noting the reasons for a given disciplinary practice (Hmelo‐Silver & Barrows, [<reflink idref="bib32" id="ref76">32</reflink>]). PBL coaching could encourage student teams to engage in expert iterative practices by helping the teams to understand that they need to reduce the gaps in their understanding and can do so through iteration.</p> <p>PBL coaching tools include project templates that coaches use with student teams to help them track their knowledge, questions, and plans (Hmelo‐Silver, [<reflink idref="bib30" id="ref77">30</reflink>]). Teams use project templates to record (i) facts they know about the problem, (ii) potential solutions, (iii) issues that identify gaps in their knowledge, and (iv) action plans for what they will do between the current coaching session and the next coaching session (Hmelo‐Silver, [<reflink idref="bib30" id="ref78">30</reflink>], fig. 2, p. 243).</p> <p>Jonassen and Hung argue that it is unclear the extent to which PBL coaching is sufficient to support students tackling engineering design problems and that some other augmented PBL is needed ([<reflink idref="bib36" id="ref79">36</reflink>]). We now describe the Design Risk Framework (DRF) study we conducted between Study 1 and Study 2 to inform how to augment PBL coaching.</p> <hd id="AN0173054171-7">The design risks framework</hd> <p>The PBL coaching in Study 1 did not effectively encourage students to engage in expert iterative practices (see below). Consequently, we conducted the DRF Study between Study 1 and Study 2 (Carlson et al., [<reflink idref="bib13" id="ref80">13</reflink>]; Carlson et al., [<reflink idref="bib14" id="ref81">14</reflink>]) to understand the metacognition that helped expert engineering designers to engage in expert iterative practices.</p> <p>In recent years, researchers in design studies have called for increasing our understanding of metacognition in engineering design (Ball & Christensen, [<reflink idref="bib8" id="ref82">8</reflink>]). We draw on Winnie and Azevedo's definition: "metacognition is thinking about the contents and processes of one's mind." (Winne & Azevedo, [<reflink idref="bib77" id="ref83">77</reflink>], p. 63; see also NAS, [<reflink idref="bib49" id="ref84">49</reflink>]; Pintrich, [<reflink idref="bib53" id="ref85">53</reflink>]). Ball and Christensen ([<reflink idref="bib8" id="ref86">8</reflink>]) argue that an underexplored component of metacognition in engineering design is exploring what activities designers should do based upon this knowledge. That is, we know little about how designers plan to direct their future thinking, including in engineering design iteration (Crilly & Cardoso, [<reflink idref="bib19" id="ref87">19</reflink>]).</p> <p>The DRF Study notes three types of metacognition involved in engendering expert iterative practices. The first type is one form of metacognitive monitoring called <emph>focusing attention</emph>—thinking about the knowledge of the different elements of the project, such as what is currently known about the client needs or root cause of the problem. This includes judging the quality of this knowledge, for example, knowing the extent that user need(s) have been well defined. The second type is also an aspect of metacognitive monitoring called <emph>identifying risks</emph>—identifying gaps in their current thinking that could cause the project to fail. Design risks are metacognitive, as they require the designer to explore the extent of their knowledge about the project (Ball & Christensen, [<reflink idref="bib8" id="ref88">8</reflink>]). For example, design engineers need to ask themselves whether they have a clear, plausible root cause and if they have gathered good evidence for their root cause. The third type is a form of metacognitive control called <emph>choosing strategies</emph>—identifying how to plan to respond to the risks in the project, such as testing prototypes with users to understand user needs better and develop a design (Adams et al., [<reflink idref="bib3" id="ref89">3</reflink>]; see also Dorst & Cross, [<reflink idref="bib24" id="ref90">24</reflink>]).</p> <p>Our comparison of student and expert metacognition found that experts engaged more in each type of metacognition in the DRF—focusing attention, identifying risks, and choosing strategies—with the core reason why students did not iterate was that they identified far fewer <emph>risks</emph>. For example, experts identified that student teams might struggle to articulate a possible "root cause" of the issue, and struggle to articulate the "causal chain"—another type of hypothesis that describes the proximal and distal causes of the issue. Without a plausible root cause, design teams cannot generate a plausible design solution.</p> <p>The DRF study identified 49 distinct risks that students ignored but experts saw as reasons to engage in expert iterative practices (Carlson et al., [<reflink idref="bib14" id="ref91">14</reflink>]). Identifying risks leads to testing or other activities that should lead the student team to have an augmented understanding of the problem and to revise their solution—that is, engage in coupled revision (Adams et al., [<reflink idref="bib3" id="ref92">3</reflink>]; Dorst & Cross, [<reflink idref="bib24" id="ref93">24</reflink>]).</p> <p>The DRF Study also showed that students and experts tend to have the opposite assumption about whether their design would work. Students identified fewer design risks and would assume that, without evidence to the contrary, their designs would be effective and their understanding of the problem was correct. Experts, on the other hand, would assume that designs would not work until they had gathered evidence that it might work and that their understanding of the problem may be incorrect or incomplete. Thus, expert designers are motivated to engage in expert iterative practices. Furthermore, experts specified risks they want to address during testing.</p> <p>The DRF framework predicts the metacognitive inputs—focusing attention, identifying risks, and choosing strategies—that will result in expert iterative practices.</p> <hd id="AN0173054171-8">RESEARCH QUESTIONS</hd> <p>As is common in design‐based research, our goal was to create a design argument—a theoretical description of the features of a learning environment for promoting learning processes and learning outcomes and in a given context (van den Akker et al., [<reflink idref="bib76" id="ref94">76</reflink>]). Consistent with design‐based research (DBR), to create the design argument we drew upon previous literature and our own work within this DBR Project (Easterday et al., [<reflink idref="bib26" id="ref95">26</reflink>]; Rees Lewis et al., [<reflink idref="bib59" id="ref96">59</reflink>]). Following the common format of research questions in DBR (Easterday et al., [<reflink idref="bib27" id="ref97">27</reflink>]; van den Akker et al., [<reflink idref="bib76" id="ref98">76</reflink>]), our overarching research question was <emph>How can we augment PBL coaching to help students in the context of a real‐world engineering design class engage in increased expert iterative practices?</emph> Consistent with DBR, we refined the research questions as we built upon our findings. Thus, between Study 1 and Study 2, the DRF study suggested that <emph>risk identification</emph> is central to expert iterative practices. As such, our research question changed between Study 1 and Study 2 to <emph>How can we augment PBL coaching to help students in the context of a real‐world engineering design class to identify risks and will this lead to increased expert iterative practices?</emph> We operationalize expert iterative practices through measuring coupled revisions, cascades, and vital conclusions. Thus, more specifically, we asked: <emph>Did coupled revision, cascades, and vital conclusions increase from Study 1 to Study 2?</emph></p> <p>The learning goals of both the PBL coaching in Study 1 and Planning‐to‐Iterate in Study 2 were to support teams in engaging in expert iterative practices. In this work, we draw on Sherin et al. ([<reflink idref="bib68" id="ref99">68</reflink>]) scaffolding analysis perspective—all learning environments have scaffolding, so the focus of this research is to note the differences in scaffolding between implementations.</p> <p>We now describe Planning‐to‐Iterate and how it was informed by the DRF study.</p> <hd id="AN0173054171-9">DESIGN ARGUMENT FOR PLANNING‐TO‐ITERATE</hd> <p></p> <hd id="AN0173054171-10">Origin of Planning‐to‐Iterate</hd> <p>To support student engineering design teams to engage in expert iterative practices, we created the <emph>Planning‐to‐Iterate</emph> design argument for Study 2. We developed this design argument after Study 1 and the DRF Study. The DRF Study informed our scaffolds, in that the scaffolds were designed to support student design teams in three connected aspects of metacognition—focusing attention, identifying risks, and choosing strategies (Table 1).</p> <p>1 TABLE How the Planning‐to‐Iterate design features map to both the metacognitive processes defined in the DRF and scaffolding theory.</p> <p> <ephtml> <table><thead valign="bottom"><tr><th align="left">Metacognitive processes (identified in the DRF study)</th><th align="left">Planning‐to‐Iterate design feature (drawn from the learning sciences and design tools)</th><th align="left">Scaffolding processes (drawn from the learning sciences)</th></tr><tr><th align="left">Problematizing</th><th align="left">Structuring</th></tr><tr><th align="left">Articulating</th><th align="left">Restricted representation</th><th align="left">Decomposing tasks</th><th align="left">Focusing effort</th><th align="left">Recording</th></tr></thead><tbody valign="top"><tr><td align="left">Focusing attention (monitoring)</td><td align="left">Project template</td><td align="left">X</td><td align="left">X</td><td align="left">X</td><td align="left" /><td align="left">X</td></tr><tr><td align="left">Guiding questions</td><td align="left">X</td><td align="left" /><td align="left">X</td><td align="left" /><td align="left" /></tr><tr><td align="left">Identifying risks (monitoring)</td><td align="left">Project template (filled out)</td><td align="left">X</td><td align="left">X</td><td align="left">X</td><td align="left">X</td><td align="left">X</td></tr><tr><td align="left">Risk checklists</td><td align="left">X</td><td align="left" /><td align="left">X</td><td align="left" /><td align="left" /></tr><tr><td align="left">Traffic lights system</td><td align="left" /><td align="left" /><td align="left" /><td align="left">X</td><td align="left" /></tr><tr><td align="left">Choosing strategies (monitoring)</td><td align="left">Risk prioritized (on project template)</td><td align="left" /><td align="left">X</td><td align="left" /><td align="left">X</td><td align="left">X</td></tr><tr><td align="left">Planning template</td><td align="left">X</td><td align="left" /><td align="left">X</td><td align="left" /><td align="left">X</td></tr></tbody></table> </ephtml> </p> <hd id="AN0173054171-11">Overview of Planning‐to‐Iterate</hd> <p>The Planning‐to‐Iterate design argument draws on scaffolding approaches from the learning sciences and professional design tools. The design argument proposes that we can support student team iteration by supporting a planning process in which teams define problem and solution elements (Atman et al., [<reflink idref="bib5" id="ref100">5</reflink>]; Schön, [<reflink idref="bib65" id="ref101">65</reflink>]), identify the risks associated with these elements, prioritize which risks to address, and make plans to iterate to reduce those risks (Guindon, [<reflink idref="bib29" id="ref102">29</reflink>]). Student teams are supported in this by using (i) a <emph>project template</emph> for defining project and solution elements and a <emph>planning template</emph> for summarizing what was learned in the previous cycle and planning the next cycle (Knapp et al., [<reflink idref="bib37" id="ref103">37</reflink>]; Kolodner et al., [<reflink idref="bib38" id="ref104">38</reflink>]; Osterwalder & Pigneur, [<reflink idref="bib52" id="ref105">52</reflink>]; Rasmusson, [<reflink idref="bib58" id="ref106">58</reflink>]), which help teams to attend to important project and solution elements and risks (<emph>structuring</emph> and <emph>problematizing</emph>; Murray et al., [<reflink idref="bib47" id="ref107">47</reflink>]; Reiser, [<reflink idref="bib63" id="ref108">63</reflink>]); (ii) <emph>guiding questions</emph> that help teams to define the project elements; and (iii) <emph>risks checklists</emph> that help students to identify the risks related to each element.</p> <p>Planning‐to‐Iterate differs from traditional PBL coaching by adding more supports to the process, including identifying risks. Planning‐to‐Iterate does this by using guiding questions and risk checklists drawn from risks identified in the DRF Study. Furthermore, the project templates explicitly provide many more elements than traditional PBL templates. Finally, in Planning‐to‐Iterate at the start of the project, nearly every element of the project contains risks.</p> <hd id="AN0173054171-12">Use of Planning‐to‐Iterate</hd> <p>The intended student experience using Planning‐to‐Iterate is as follows. Each week, all student teams engage in the same 2‐h session, working sequentially through the templates (Figure 1). The coach then follows up with a 15‐min PBL coaching session with each team separately. The team members discuss and record what they have learned over the previous week on the planning template's <emph>learn</emph> section (Figure 1, far left). The team then updates their project template based upon what they have learned, such as new information about the cause of the problem, competitors, and how this impacts solutions. The team uses guiding questions to articulate elements of their project on the project template. For example, the guiding questions for the client section of the project template prompt the design team to define their client organization and contact, the contact's role within the organization, the client needs, and the evidence they have for these needs.</p> <p> <img src="https://imageserver.ebscohost.com/img/embimages/rdk/6M4/01oct23/jee20554-fig-0001.jpg?ephost1=dGJyMNXb4kSepq84yOvqOLCmsE6epq5Srqa4SK6WxWXS" alt="jee20554-fig-0001.jpg" title="1 Example Planning‐to‐Iterate project and planning templates. Student teams use the templates weekly by (1) discussing and updating the left‐hand planning template and all of the project template with what they have learned over the previous week, using guiding questions to help them to articulate, (2) identifying the risks on the project template using the risk checklist, (3) prioritizing their risks to address, and (4) planning their work for the coming cycle (week) using the right‐hand planning template." /> </p> <p></p> <p>After updating the project template, the team then identifies the risks. The team uses the risks checklist that helps them to identify risks in each section of the project template based on the 49 risks identified in the DRF Study. For example, if teams do not have any evidence of the clients' needs and resources, they can easily propose a design that the client organization cannot support. Each box in the project template housed multiple risks. So, risks were associated with the Community Partner, Users, Accessing Users, Demoing to Partner, Value, Root Cause, Value Proposition, Existing Solutions, Impact, and Implementation Strategy. So, one Existing Solutions risk was developing a design that is the same as an established design that community partners already have easy access to. The teams use a traffic light system, with significant risk marked in red, less significant risks marked in yellow, and when the team had evidence that there were no risks for a given element, marked in green.</p> <p>After identifying risks, the team then prioritizes which risks are most critical to reduce over the cycle (1 week). The student team then plans their next cycle, explicitly noting the highest priority risk(s) on the <emph>build</emph> part of their planning template (Figure 1, far right). The team then plans how they will reduce that risk over the next cycle by identifying questions they need to answer in their iteration and methods they will apply. At the end of the planning session, the coach meets with each team separately to discuss their plan for 15 min. The team then enacts their plan over the cycle.</p> <hd id="AN0173054171-14">Scaffolding that supports metacognition in Planning‐to‐Iterate</hd> <p>Planning‐to‐Iterate is informed by key metacognitive differences between student teams and expert practice identified in the DRF Study. We sought to support "focusing attention" on the project elements with the project template and guiding questions, so that teams articulated the extent of their knowledge about the project. We then sought to support "identifying risks" with the risk checklist on what students had articulated on the project template, so that teams noted what was risky about their current state of knowledge. We sought to support "choosing strategies" with the planning template and identified risks, so that students would plan to iterate to reduce these risks. The scaffolds were designed to prompt and support students' metacognition—for example, that they did have evidence for user need A, but have no evidence for user need B, and that it is critical that they establish evidence for user need B which they then plan to do.</p> <p>We draw on a range of theories from scaffolding in the learning sciences literature to inform Planning‐to‐Iterate (Hmelo‐Silver, [<reflink idref="bib30" id="ref109">30</reflink>]; Puntambekar & Kolodner, [<reflink idref="bib56" id="ref110">56</reflink>]). Table 1 shows how the Planning‐to‐Iterate design features map to both the metacognitive processes defined in the DRF and scaffolding theory. The project and planning templates, guiding questions, and risk checklists both <emph>problematize</emph> and <emph>structure</emph> design teams' planning as they define the problem and solution elements. Problematizing refers to making students aware of elements of the project they might not attend to (Chase et al., [<reflink idref="bib15" id="ref111">15</reflink>]; Reiser, [<reflink idref="bib63" id="ref112">63</reflink>]). For example, it might be common for student designers to ignore client resource constraints. The project template, guiding questions, and risk checklists help students to <emph>articulate</emph> (Reiser, [<reflink idref="bib63" id="ref113">63</reflink>]) their understanding of the problem and solution elements, and then to identify risks, which can help student teams to focus on an important element of project they might otherwise ignore (Scardamalia & Bereiter, [<reflink idref="bib64" id="ref114">64</reflink>]). This is achieved in part by focusing the team on key elements of the problem and solution as they plan through a <emph>restricted representation</emph> (Reiser, [<reflink idref="bib63" id="ref115">63</reflink>]).</p> <p>The project template, planning template, guiding questions, and risk checklists also <emph>structure</emph> the process of defining problem and solution elements. Structuring refers to giving students less choice and reducing complexity through <emph>decomposing tasks</emph>, <emph>focusing effort</emph>, and <emph>recording</emph> (Murray et al., [<reflink idref="bib47" id="ref116">47</reflink>]; Reiser, [<reflink idref="bib63" id="ref117">63</reflink>]). The project template, planning template, and guiding questions lead the team through updating the project template, a type of <emph>decomposing the task</emph> of defining problem and solution elements—the teams fill out each box of the project template and follow the guiding questions in each box. Moving through the process of defining problem and solution elements, identifying risk, and then planning how to reduce risks decomposes expert iterative practices for students (Siverling et al., [<reflink idref="bib72" id="ref118">72</reflink>]). The <emph>project template</emph> also supports teams monitoring both within the session and across the week. Planning‐to‐Iterate structures the task by <emph>focusing effort</emph> between defining the problem and solution elements, identifying risk, and planning. Depending on what students define as the problem and solution elements, the team narrows their focus on what they will discuss during risk identification. Risk identification, in turn, narrows what a team will focus on in planning. Focusing effort on specific problem and solution elements is particularly important because design problems have no fixed end points that require narrowing the problem (Schön, [<reflink idref="bib65" id="ref119">65</reflink>]; Simon, [<reflink idref="bib71" id="ref120">71</reflink>]) and instructors cannot focus effort simply by preselecting data or project goals (Quintana et al., [<reflink idref="bib57" id="ref121">57</reflink>]) as they might with a statistics exercise. Planning‐to‐Iterate also structures the task by helping students to <emph>record</emph> the state of their project (Kolodner et al., [<reflink idref="bib38" id="ref122">38</reflink>]; Reiser, [<reflink idref="bib63" id="ref123">63</reflink>]). Because design engineering problems are very complex and ill‐structured, student engineering design teams might make one plan but be distracted by other elements of the project and "impulsively" move between activities (Crismond & Adams, [<reflink idref="bib20" id="ref124">20</reflink>], p. 749). The templates with the risk checklist and a plan for how to reduce those risks might help students to record and refer to their plans in comparison with their current actions, and so better engage in effective iteration.</p> <hd id="AN0173054171-15">METHODS</hd> <p>We conducted a multiphase, design‐based research study (Brown, [<reflink idref="bib11" id="ref125">11</reflink>]; Easterday et al., [<reflink idref="bib26" id="ref126">26</reflink>]; Table 2). Study 1 investigated whether PBL coaching could encourage expert iterative practices. Our results in Study 1 suggest that PBL in engineering design must include different scaffolds to support iteration. Study 2 investigated Planning‐to‐Iterate—a design argument informed by the DRF Study, the learning sciences, and professional design tools.</p> <p>2 TABLE Overarching research involved three studies; Study 1 and Study 2 are reported in this paper, whereas the DRF Study, which took place in between those studies, is summarized in the background (Carlson et al., 2020).</p> <p> <ephtml> <table><thead valign="bottom"><tr><th align="left" /><th align="left">Study 1 (Year 1)</th><th align="left">Design Risk Framework (DRF) study (Year 2)</th><th align="left">Study 2 (Year 3)</th></tr></thead><tbody valign="top"><tr><td align="left">Context</td><td align="left">6‐Week full‐time undergraduate design class</td><td align="left">6‐Week full‐time undergraduate design class</td><td align="left">6‐Week full‐time undergraduate design class</td></tr><tr><td align="left">Methods</td><td align="left">Qualitative assessment of student teams iterative practices (same as Study 2)</td><td align="left">Qualitative analysis of expert–novice difference in metacognition involved in iteration</td><td align="left">Qualitative assessment of student teams iterative practices (same as Study 1)</td></tr><tr><td align="left">Design being studied</td><td align="left">PBL coaching</td><td align="left">NA</td><td align="left">PBL coaching + Planning‐to‐Iterate</td></tr><tr><td align="left">Coaching time supporting planning each week</td><td align="left">2 h/team each week</td><td align="left">NA</td><td align="left">15 min/team each week</td></tr><tr><td align="left">Educator time supporting planning each week</td><td align="left">10 h/week</td><td align="left">NA</td><td align="left">3 h and 15 min/week (one 2‐h Planning‐to‐Iterate workshop +15 min/team)</td></tr><tr><td align="left">Influence on overall research</td><td align="left">Led to decision to conduct DRF Study</td><td align="left">Informed Planning‐to‐Iterate in Study 2</td><td align="left">Provided evidence for impact of Planning‐to‐Iterate and provides support for DRF</td></tr><tr><td align="left">Reporting in this paper</td><td align="left">Reported in the findings below</td><td align="left">Summarized in background; fully reported in Carlson et al. (<xref ref-type="bibr" rid="bibr14">2020</xref>)</td><td align="left">Reported in the findings below</td></tr></tbody></table> </ephtml> </p> <hd id="AN0173054171-16">Context and participants</hd> <p>Data collection took place in an extracurricular 6‐week full‐time (40 h a week) undergraduate summer design class in a private US university. The goal of the program was to provide an authentic engineering design learning experience. Teams of 4–5 designed products and/or services to solve a need identified by a local client organization—an approach recommended in engineering design education literature to help students to learn to take on real‐world challenges (Dym et al., [<reflink idref="bib25" id="ref127">25</reflink>]; Nguyen et al., [<reflink idref="bib50" id="ref128">50</reflink>]). A facilitator managed the program, including coordinating 2–4 h of design methods workshops each week (e.g., user interviewing, value propositions) led by engineering design educators. The facilitator did not act as a PBL coach. The program provided the same workshops each year of the program.</p> <p>In both Study 1 and Study 2, there was a 2‐h weekly planning session each Tuesday, with the goal of planning for the next week. In Study 1, this session was led by the coach as part of the PBL coaching, and in Study 2 this session was a 2‐h Planning‐to‐Iterate session.</p> <p>In both studies, all students in the class were included, although all of them were able to opt out of the study. Participants in Study 1 were 18 undergraduates who made up four teams with 4–5 students per team (3 first, 11 s, and 4 third year; 61% female) aged 18–22 years. Students majored or double‐majored in engineering (<reflink idref="bib12" id="ref129">12</reflink>), sciences (<reflink idref="bib4" id="ref130">4</reflink>), social sciences (<reflink idref="bib1" id="ref131">1</reflink>), art (<reflink idref="bib3" id="ref132">3</reflink>), journalism (<reflink idref="bib2" id="ref133">2</reflink>), and theater (<reflink idref="bib1" id="ref134">1</reflink>). Participants in Study 2 were 21 undergraduates who made up five teams with 4–5 students per team (4 first, 12 s, 5 third year; 57% female) aged 18–22 years. Students majored or double‐majored in engineering (<reflink idref="bib15" id="ref135">15</reflink>), sciences (<reflink idref="bib3" id="ref136">3</reflink>), social sciences (<reflink idref="bib3" id="ref137">3</reflink>), art (<reflink idref="bib3" id="ref138">3</reflink>) and journalism (<reflink idref="bib3" id="ref139">3</reflink>). Consistent with the program's practices at the time, we did not capture data on ethnicity/race. This was due to feedback from student leadership, noting that students felt essentialized by data collection on race. The programs in Study 1 and Study 2 were implemented in the same way, other than the different coaching interventions. This includes the recruitment process for the program.</p> <hd id="AN0173054171-17">Differences in coaching interventions between Study 1 and Study 2</hd> <p>The core difference between the studies is that in Study 1 student teams received 2 h of coaching each week, and in Study 2 student teams received the Planning‐to‐Iterate approach and 15 min of coaching each week. In Study 1, the first author coached each team separately for 2 h every week. Following PBL coaching theory, the first author asked the teams about their current understanding of the project, possible gaps in their knowledge, and plans for reducing those gaps (Hmelo‐Silver & Barrows, [<reflink idref="bib31" id="ref140">31</reflink>]). Teams used PBL project boards as described in Hmelo‐Silver ([<reflink idref="bib30" id="ref141">30</reflink>]). The first author had over 10 years' experience in coaching and teaching engineering design at two different engineering schools in the United States and Europe, and over 8 years' experience conducting design engineering projects in industry. The first author expected that the PBL coaching would be more successful than it was in Study 1.</p> <p>In Study 2, the first author led the 2‐h Planning‐to‐Iterate workshops (described above; Figure 1), followed by coaching each team separately for 15 min. The first author spent the following time supporting students: (i) Study 1: 8 h/week, or 2 h per team/week; (ii) Study 2: 3 h 15 min/week, or 39 min per team/week.</p> <hd id="AN0173054171-18">Data collection and analysis</hd> <p>To examine students' iterative practices, we video/audio‐recorded 2 h of planning and coaching each week from each team. In both studies, student engineering design teams were asked to discuss what information they had gathered and what vital conclusions and coupled revisions they generated. In Study 1, we audio‐recorded interactions with coaches, and in Study 2 we video‐recorded the workshop and interactions with students as Planning‐to‐Iterate involved more written planning. In both studies, we photographed each team's planning artifacts and designs (including prototypes and mockups) before and after each planning session. We collected 43 planning sessions (72 h of audio/video).</p> <p>We conducted a qualitative analysis of the video/audio data and artifacts to understand the extent that teams were conducting (i) coupled revisions, (ii) cascades, and (iii) generating vital conclusions about <emph>viability</emph>, <emph>relevance</emph>, and <emph>effectiveness</emph>.</p> <p>To understand whether a team conducted coupled revisions, we deductively coded (Miles et al., [<reflink idref="bib45" id="ref142">45</reflink>]) the video/audio in which student teams reported their activity from the previous week. Three authors developed the initial codebook, the first and second authors conducted the coding, and all authors reviewed coding during debriefing sessions (Shenton, [<reflink idref="bib67" id="ref143">67</reflink>]). We applied and developed three sub‐codes to capture coupled revisions: (i) <emph>problem conclusions</emph>, where the team reported learning about the problem; (ii) <emph>solution conclusions</emph>, where the team reported learning about the solution through testing, and (iii) <emph>design revision</emph>, where the team planned to change the solution based on their learning. We coded a given cycle as involving coupled revision only if there was evidence of all three codes and if it was clear how the problem conclusions and solution conclusions informed the design revision.</p> <p>To understand the extent teams were conducting cascades, each week we recorded student teams' reports of the number of (i) user interviews they conducted, (ii) mockups/prototypes they created, and (iii) tests they conducted.</p> <p>To understand the types of vital conclusions teams made each week, we conducted multiple rounds of deductive coding (Miles et al., [<reflink idref="bib45" id="ref144">45</reflink>]) on the parts of the planning sessions in which teams reported their conclusions. Our goal was to code evidence‐based conclusions that the teams made—this was not a judgment upon the design quality; such a judgment would not be possible in the middle of an ill‐structured engineering design challenge (Jonassen & Hung, [<reflink idref="bib36" id="ref145">36</reflink>]). Specifically, we coded the video/audio and artifacts in which teams drew conclusions from evidence about relevance, effectiveness, and viability.</p> <p>We applied several recognized qualitative methodological approaches to establish trustworthiness and credibility. Throughout the analysis, we conducted frequent debriefing sessions every 2–3 weeks with all authors (Shenton, [<reflink idref="bib67" id="ref146">67</reflink>]). These sessions allowed those with a wide range of expertise and perspectives to note flaws and potential biases in the analysis. In the findings, we sought to provide as in‐depth description of the practices, context, and design as was possible within the word limit (Lincoln & Guba, [<reflink idref="bib42" id="ref147">42</reflink>]). These descriptions allow the reader to judge the extent the finding seems plausible. During our analysis, we also examined results from previous findings in design engineering education to note both which parts of our findings are novel and which parts are supported elsewhere in the literature (Silverman, [<reflink idref="bib70" id="ref148">70</reflink>]). This adds both credibility to our findings and helps define novelty (Shenton, [<reflink idref="bib67" id="ref149">67</reflink>]). We also engaged source triangulation (Lincoln & Guba, [<reflink idref="bib42" id="ref150">42</reflink>]) between video/audio of plans, photos of planning artifacts, and photos of prototypes and mockups. This allowed us to check these different sources of data against one another as we were coming to conclusions about coupled revisions, cascades, and vital conclusions. For example, for cascades, if teams reported they made four prototypes in a week in the audio, we would also cross‐reference this with photos of planning templates and prototypes.</p> <p>We also conducted a test of inter‐rater reliability on our code book for coupled revisions and vital conclusions. Two researchers independently coded the same randomly selected 14% of the data from Study 1 and Study 2 (2 cycles each from Study 1 and Study 2). The first author was the first coder, and the second coder was a research assistant unfamiliar with the coding scheme, data, or project. We then calculated a pooled (De Vries et al., [<reflink idref="bib22" id="ref151">22</reflink>]) PABAK Kappa (Byrt et al., [<reflink idref="bib12" id="ref152">12</reflink>]) measure for inter‐rater reliability, which was 0.875, showing "almost perfect agreement" between coders (Landis & Koch, [<reflink idref="bib41" id="ref153">41</reflink>]). We did not code inter‐rater reliability for cascades, as coding student teams reporting a number does not require complex social interpretation.</p> <hd id="AN0173054171-19">STUDY 1: PBL COACHING</hd> <p>Our first study asked to what extent PBL coaching might encourage student engineering design teams to engage in expert iterative practices.</p> <hd id="AN0173054171-20">Results</hd> <p>We found that with a PBL coaching approach, student design teams struggled to engage in expert iterative practices. Half of the teams only conducted coupled revisions in the final weeks of the program (Figure 2), despite the PBL coach encouraging the teams to engage in expert iterative practices throughout the program. Furthermore, there were few cascades. No team conducted any prototype testing in the first half of the program. No team generated any vital conclusions in the first cycle, or about the effectiveness and viability in the first half of the program (Figure 3). All teams did come to conclusions about relevance in the second cycle of the program.</p> <p> <img src="https://imageserver.ebscohost.com/img/embimages/rdk/6M4/01oct23/jee20554-fig-0002.jpg?ephost1=dGJyMNXb4kSepq84yOvqOLCmsE6epq5Srqa4SK6WxWXS" alt="jee20554-fig-0002.jpg" title="2 Student teams in Study 2 engaged in more coupled revisions (Column 1) and cascades (Columns 2–4) than student teams in Study 1. Cascades were measured by the extent teams interleaved user interviews, building prototypes, and stakeholder tests each cycle (week). Each week, the student teams in Study 1 were supported by 2 h of PBL coaching, while the student teams in Study 2 were supported by Planning‐to‐Iterate and 15 min of PBL coaching." /> </p> <p></p> <p> <img src="https://imageserver.ebscohost.com/img/embimages/rdk/6M4/01oct23/jee20554-fig-0003.jpg?ephost1=dGJyMNXb4kSepq84yOvqOLCmsE6epq5Srqa4SK6WxWXS" alt="jee20554-fig-0003.jpg" title="3 Student teams in Study 2 drew more vital conclusions about relevance, effectiveness, viability compared to teams in Study 1. Each week, the student teams in Study 2 were supported by Planning‐to‐Iterate and 15 min of PBL coaching, while the student teams in Study 1 were supported by 2 h of PBL coaching." /> </p> <p></p> <p>To illustrate these results in Study 1, consider the example of the Recycling team. The team partnered with a chain of stores that sell recycled building materials to reduce CO<subs>2</subs> emissions but struggled with low sales. In week 2, after visiting the stores, the coach asked the team about the reasons for low sales—the root cause of the problem. In response to the coach, the team hypothesized it was because "the store is disorganized" and customers had little faith that they would find what they wanted, so quickly left the stores without buying materials. The coach then asked the team about their next course of action. The team proposed creating signage to help customers to have more confidence that the store is well organized and a website for distributing the signage to all stores. The coach asked how the team might test these two hypotheses. Two team members replied that they could interview customers who left the store and stated that they were confident that the signs would work. At the end of the meeting, the coach suggested that one way they might test both hypotheses would be to put up their signs in stores and see if there were changes in customer purchases.</p> <p>The following week in the coaching session, the coach asked the Recycling team what they had learned over the last week. The team replied that they had focused upon both building some of the signs and creating the website. There was no evidence of coupled revision—the team reported that they were "on the right track" and did not need to revise their designs. Furthermore, the team reported that they did not interview customers to find the reason why they left the store, nor did they test the signs in the store.</p> <p>The team spent the next 3 weeks designing the signage and creating an online platform for distributing the signs. In week 5, the team tested the signage in a local store and found that the signs did not change customer behavior.</p> <p>To illustrate our coding for coupled revisions and vital conclusions, in week 5 the Recycling team did engage in coupled revision. The team conducted a test by installing the signs in a store for a week. Through observations, the team saw that customers left the store quickly after entering at the same rate and the store's sales did not change. In the coaching session, the team discussed how the signs did not work and that they needed to change their design. The team also discussed the alternative design they would pursue if they had more time.</p> <p>This example illustrates coupled revision as the team discussed: (i) how problem understanding changed (customers do not see signs; the stores being disorganized might not be the root cause of the problem), (ii) current design (that the signs are not effective in changing behavior), and (iii) how to change their design (changing from signs to other design approaches). The team generated two types of vital conclusions: (i) the team noted that the design was not effective, as there were no changes to customer behavior, and (ii) that the signs might be considered viable, as owners and store staff allowed them to install the signs.</p> <p>Ultimately, with only 1 week remaining, the team had no time to develop a new solution and the problem went unsolved.</p> <hd id="AN0173054171-23">Summary of Study 1</hd> <p>Study 1 found that PBL coaching, which focused on encouraging expert iterative practices, did not promote student teams to engage in expert iterative practices. The teams saw limited expert iterative practices in the first half of the program.</p> <p>The Recycling team illustrates the issue with this lack of expert iterative practices when taking on real‐world engineering design problems. The Recycling team only tested design generated in the first week of the program in week 5 of a 6‐week program and found it did not work. Consequently, they went into the last week of the program knowing that their solution would not work. The expert iterative practices that the Recycling team engaged in during week 5 could have occurred much earlier. Had the team done so, they might have avoided creating an ineffective solution. We saw a similar pattern occur with all the teams in Study 1.</p> <p>We turn to Study 2 to see how augmenting PBL coaching with Planning‐to‐Iterate would impact student team expert iterative practices.</p> <hd id="AN0173054171-24">STUDY 2: PLANNING‐TO‐ITERATE</hd> <p>In Study 2, we used what we learned from the DRF Study to inform tools to encourage student engineering design teams to engage in expert iterative practices. Specifically, we ask: <emph>How can we augment PBL coaching to help design students identify risks and thus engage in increased expert iterative practices?</emph></p> <hd id="AN0173054171-25">Findings</hd> <p>In Study 2, we found that student teams using Planning‐to‐Iterate engaged in more expert iterative practices than in Study 1.</p> <hd id="AN0173054171-26">Coupled revisions</hd> <p>Student teams in Study 2 were more likely to engage in coupled revisions—gathering and using feedback to improve the solution and their understanding of the problem (Figure 2, Column 1). Specifically, the teams in Study 2 demonstrated coupled revisions in 68% of cycles (13/19). In comparison, teams in Study 1 engaged in coupled revisions in 31% of cycles (5/16). Furthermore, teams in Study 2 conducted coupled revisions earlier in the process, with all teams conducting iterations in the cycle week 2–3, whereas none of the teams in Study 1 had conducted coupled iterations at that point. In week 3–4, one team was in the field so did not attend the Planning‐to‐Iterate session, so we only have data for four teams in week 3–4.</p> <hd id="AN0173054171-27">Example of coupled revisions</hd> <p>To illustrate these findings, we now show an example of coupled revision from a team working on teen depression in Study 2. In week 2, the team tested three prototypes of an "emotions planner" designed to foster conversations between middle school students and parents. The planner built on research in child psychology regarding "building emotional vocabulary" (written on project template). The team reported seeking information from "middle school students," "parents," and a "child psychologist." The team both wrote, and one team member said "we got feedback that kids would only fill out the planner if someone enforced it," and discussed how this information came from showing their prototypes to a student and parent (triangulated between video and artifact data). On the planning template, the team had a post‐it note, which read, "look into 'digital' planner and how it could be implemented." The team discussed the design details (video data). Finally, on the project template the team added a note reading "weekly mental health related prompts aim to increase communication b/w students + parents → form habit."</p> <p>This example illustrates coupled revision. The team discussed (i) how problem understanding changed (students do not start conversations about emotions), (ii) current design (the design needed to prompt students), and (iii) how to change their prototype (add human/email prompts to start emotional conversations).</p> <p>In comparison to the Recycling team in Study 1, who did not conduct coupled revisions until the final weeks of the program, the team working on teen depression was able to see a flaw in their design early in the program and make amendments to their proposed design aligned with stakeholder needs.</p> <hd id="AN0173054171-28">Cascades</hd> <p>The teams in Study 2 also conducted far more activity within each cycle that suggests cascades than in Study 1 (Figure 2, Columns 2–4). Each cycle teams conducted more user interviews, created more prototypes, and conducted more user tests. In Study 2, the mean of every single measure for cascades was higher than in Study 1 in every single corresponding cycle (Figure 2, Columns 2–4).</p> <hd id="AN0173054171-29">Vital conclusions</hd> <p>In Study 2, student teams engaged in generating more vital conclusions (Figure 3). Teams in Study 2 recorded and discussed conclusions about relevance in 13/19 cycles (68% of cycles), effectiveness in 7/19 cycles (37%), and viability in 13/19 cycles (68%). In comparison, teams in the Study 1 came to conclusions about relevance in 7/16 cycles (44% of cycles), effectiveness in 3/16 cycles (19%), and viability in 4/16 cycles (25%) (Figure 3). Teams in Study 2 also came to vital conclusions about effectiveness and viability much earlier in the program than in Study 1.</p> <p>The following example illustrates a team generating vital conclusions about relevance and viability. The Wheelchair team were working with an accessibility advocacy group and local airport on reducing the thousands of annual breakages to wheelchairs transported in the hold of passenger aircraft. During the week 3–4 cycle, the Wheelchair team tested lifting straps and stickers with baggage handlers. The baggage handlers told the team that they would not use the lifting straps because of space and time constraints during the busy loading periods. However, the baggage handlers reported that the stickers were a good option, as they did not know the proper lifting points for wheelchairs and had never received any training for lifting wheelchairs. Furthermore, they noted they currently do attend to stickers on luggage. We coded this cycle as drawing vital conclusions about (i) relevance, because baggage handlers reported that they had limited knowledge and training for how to lift wheelchairs, and (ii) viability, because the baggage handlers reported that they could not use the straps given their real‐world space and time considerations—but stickers were viable, as baggage handlers can and do attend to stickers.</p> <p>We now discuss the implications on this study for how to create learning environments to support expert iterative practices.</p> <hd id="AN0173054171-30">DISCUSSION</hd> <p>Engineering design problems are too complex and ill‐structured for people to offer effective solutions the "first time" (Cross, [<reflink idref="bib21" id="ref154">21</reflink>]; Jonassen & Hung, [<reflink idref="bib36" id="ref155">36</reflink>]; Mosborg et al., [<reflink idref="bib46" id="ref156">46</reflink>]). Thus, as noted in the literature, iteration is core to effective engineering design practice (Atman et al., [<reflink idref="bib5" id="ref157">5</reflink>]; Knapp et al., [<reflink idref="bib37" id="ref158">37</reflink>]).</p> <p>The primary implication of this paper is encapsulated in the Planning‐to‐Iterate design argument—that is, a theoretical claim for how to design to support student engineering design teams to engage in expert iterative practices (Easterday et al., [<reflink idref="bib26" id="ref159">26</reflink>]). This research offers evidence that we can help student teams to engage in expert iterative practices by (i) giving students time and scaffolds to identify risks before planning, and (ii) viewing designs as starting as risky and so view iterating as a way of making progress. As such, student teams were encouraged to engage in metacognitive thinking—identifying what they knew and did not know about their projects, identifying risks in their projects, and then generating strategies based upon their assessment of their knowledge (Ball & Christensen, [<reflink idref="bib8" id="ref160">8</reflink>]). Thus, design engineering educators and educational researchers might take up and build upon these educational practices. Study 1 also contributed further evidence that students struggle to engage in expert iterative practices and that we need to augment PBL coaching to do so. Furthermore, our research supports the theory of metacognition developed in the DRF, building on the work of others (Ball & Christensen, [<reflink idref="bib8" id="ref161">8</reflink>]; Kolodner et al., [<reflink idref="bib38" id="ref162">38</reflink>])—the Planning‐to‐Iterate scaffolds were directly influenced by this framework, as this research saw an increase in expert iterative practices as would be predicted by DRF.</p> <hd id="AN0173054171-31">Possible mechanisms for encouraging expert iterative practices</hd> <p>So, why did a combination of PBL coaching with a Planning‐to‐iterate encourage more expert iterative practices than the more intensive PBL coaching? This is an especially interesting question, as educators spent far less time supporting students in Study 2 than in Study 1. We offer three hypotheses.</p> <p>First, the Planning‐to‐Iterate frames design projects as inherently risky, which may have reduced the likelihood of students dismissing coaches' questions and suggestions about risks. Both Study 1 and Study 2 supported students by problematizing and structuring scaffolds related to project risk. However, in Study 1, PBL coaching was the main way in which risks were raised and discussed, and talk of risks might have come toward the end of sessions. Without an initial framing of projects as inherently risky, students may have seen the coach's questions about the projects risks as a critique that their design was low quality. This may have caused some motivated thinking in students, so they reject any questions or suggestions the coach might have made and so avoid identifying risks (Kunda, [<reflink idref="bib39" id="ref163">39</reflink>])—that is, social psychology suggests that students are likely to see perceived critiques of designs as negative judgments about them, and so are motivated to find reasons to reject the coache's questions and suggestions to maintain a positive self‐image (Sherman & Cohen, [<reflink idref="bib69" id="ref164">69</reflink>]). Conversely, when using Planning‐to‐Iterate, students' design canvases started as being fully risky and then used a checklist of risks that can occur in all engineering design projects. The process might have felt less like a specific critique of their design but rather a normal process that is not suggesting a negative judgment on the students. As such, Planning‐to‐Iterate aligns with approaches that seek to frame failure and iteration as a normal part of engineering design practice (Marks & Chase, [<reflink idref="bib43" id="ref165">43</reflink>]). While Marks and Chase ([<reflink idref="bib43" id="ref166">43</reflink>]) seek to do this through direct instruction, Planning‐to‐Iterate seeks to support expert iterative practices though how the design project is represented on the template.</p> <p>Second, Planning‐to‐Iterate framed iteration in terms of progress. In Study 1, students might have perceived the coach's suggestions to iterate as a waste of time, because students are likely to think they can solve design problems "first time" (Mosborg et al., [<reflink idref="bib46" id="ref167">46</reflink>]) and overestimate the effectiveness of their own designs (Norton et al., [<reflink idref="bib51" id="ref168">51</reflink>]). For example, the Recycling team in Study 1 might have experienced the coach raising the risk of the signs not being effective as a threat to their sense of progress, and as such it would not be motivated to spend time testing (Kunda, [<reflink idref="bib39" id="ref169">39</reflink>]). In Study 2, students used the project template, upon which each element <emph>started</emph> risky, as represented by a red sticker in a traffic light system. As such, had the Recycling team used Planning‐to‐Iterate, they might have viewed testing the signs as potential for progress—a chance to change the value proposition box from red to green.</p> <p>Third, the Planning‐to‐Iterate templates might have allowed students to maintain a more comprehensive and stable idea of their project state, risks, and how their plans would address risks. That is, the Planning‐to‐Iterate scaffolds that support metacognitive monitoring might have been more effective. In Study 1, project risks were typically introduced by the coach, and at most the students would record a short phrase to represent that risk as something to learn about. However, teams in the following coaching meeting a week later would often report they did not address these risks. This might happen because engineering design projects are highly complex and ill‐structured, with many things that the team might focus on (Jonassen & Hung, [<reflink idref="bib36" id="ref170">36</reflink>]). Without careful metacognitive monitoring of which risks to focus on, teams can easily shift to some other part of the project. Although PBL coaching also elicits risks, it does not prompt students to comprehensively record and prioritize these risks for future monitoring. Students using the Planning‐to‐Iterate scaffolds first had to articulate all problem elements and risks, and then record their highest priority risk. As such, Planning‐to‐Iterate aligns with elements of distributed scaffolding approaches, in which material and social scaffolds support students over time (Puntambekar, [<reflink idref="bib55" id="ref171">55</reflink>]; Puntambekar & Kolodner, [<reflink idref="bib56" id="ref172">56</reflink>])—from this perspective, Planning‐to‐Iterate offered a more comprehensive array of material scaffolds over the course of the week between the social scaffolds of the coaching. Such extended focus on identifying risks, prioritizing risks, and then planning iteration based on those risks may have helped students to maintain a more comprehensive and stable idea about how and why they are iterating.</p> <hd id="AN0173054171-32">Implications for engineering education tools and practice</hd> <p>This work builds on and extends research and development of tools to support students to learn engineering design and other forms of problem‐solving. As noted in the design argument above, we draw on tools that support team planning, particularly those that seek to provide templates and social support over extended periods (Hmelo‐Silver & Barrows, [<reflink idref="bib31" id="ref173">31</reflink>]; Kolodner et al., [<reflink idref="bib38" id="ref174">38</reflink>]; Puntambekar & Kolodner, [<reflink idref="bib56" id="ref175">56</reflink>]; Zhang et al., [<reflink idref="bib79" id="ref176">79</reflink>]). Our work builds on this research by both developing a design argument for how to support risking and testing how this design argument for risking impacts how teams engage in expert iterative practices. Our work provides a template for real‐world design, which requires different categories to previous templates (see Hmelo‐Silver, [<reflink idref="bib30" id="ref177">30</reflink>], fig. 2, p. 243; Kolodner et al., [<reflink idref="bib38" id="ref178">38</reflink>], p. 520). Work elsewhere has focused on both how to design educator interactions in supporting similar iterative design processes (Gomoll et al., [<reflink idref="bib28" id="ref179">28</reflink>]) and tools to support such interactions (Rees Lewis et al., [<reflink idref="bib60" id="ref180">60</reflink>]). Here, we do not measure or explicitly design for interactions between the PBL coach and student team.</p> <p>In developing design arguments, one outcome of DBR is to provide detailed descriptions of teaching approaches that educators might use. Educators might adopt and adapt Planning‐to‐Iterate in their engineering design classes—especially for classes that involve real‐world design work. While the Planning‐to‐Iterate approach in Study 2 saved time compared to PBL coaching in Study 1, it is still time‐intensive. Planning‐to‐Iterate involved a 2‐h workshop attended by all teams—if facilitated by one educator, that would equal a total of 2 h of educator time. The educator then spent an additional 15 min coaching each team for a total of 3 h 15 min of educator time. For a larger design engineering class of 15 teams, this would require the 2‐h Planning‐to‐Iterate workshop as well as 3 h and 45 min of coaching time for a total of 5 h 45 min. As such, Planning‐to‐Iterate should be adopted when educators are able to dedicate the time to supporting student design team planning.</p> <p>This research has developed and empirically tested a design argument—a theory for how to support target learning in a given context (Easterday et al., [<reflink idref="bib26" id="ref181">26</reflink>]) that outlines how to support iteration in engineering education. In so doing, this offers some empirical support for the DRF as an explanatory theory that describes some of the metacognition involved in iteration. This is particularly exciting given that iteration is a highly challenging and important practice (Crismond & Adams, [<reflink idref="bib20" id="ref182">20</reflink>]).</p> <hd id="AN0173054171-33">Limitations and future work</hd> <p>The goal of this design‐based research study was to build a theory around how to support students in engaging in expert iterative practices. Consequently, this research has the typical limitations associated with a single‐context research. As such, we should be careful in over‐generalizing these findings. Furthermore, as each team focused on different projects with different partners and different challenges, we did not investigate project quality. However, we can show that project teams like the Wheelchair team were much more successful than the Recycling teams at discounting design approaches that would not work. This is part of the limitation of working with real‐world engineering design projects: the team, educator, and client do not know what designs will actually work, and each project is unique so that projects cannot be easily compared (Jonassen & Hung, [<reflink idref="bib36" id="ref183">36</reflink>]). We were following established practices for naturalist study of participant thinking—making inferences from participants' gestures, language use, and future actions (e.g., Derry et al., [<reflink idref="bib23" id="ref184">23</reflink>]; McCord & Matusovich, [<reflink idref="bib44" id="ref185">44</reflink>]) to measure expert iterative practices.</p> <p>Another limitation is that we did not have a pre–post learning measure to compare student metacognition and practices before and after Study 1 and Study 2. This is because, consistent with DBR research (Collins et al., [<reflink idref="bib16" id="ref186">16</reflink>]), during Study 1 we did not have the key concepts regarding metacognition we needed to create such a measure.</p> <p>In terms of student demographics, our population had many more female students than is typical of engineering education in the United States (American Society for Engineering Education, [<reflink idref="bib4" id="ref187">4</reflink>]). As with any single‐context study, we should be conservative in terms of generalizing our findings to other contexts with different populations.</p> <p>Future research might also examine coaching interactions and explore how technology might offer further scaffolding to students. First, future work might conduct an in‐depth analysis of coaching strategies and how team members interact with and without Planning‐to‐Iterate; a limitation of this research is that we did not conduct an in‐depth analysis that allowed us to make claims about how Planning‐to‐Iterate impacts the types of interactions and co‐construction involved. Such a study would be similar to research conducted on specific coaching strategies in medical PBL (Hmelo‐silver & Barrows, [<reflink idref="bib31" id="ref188">31</reflink>]). Second, future research might examine how technology could augment coaching, such as helping coaches see patterns across teams that might inform coaching strategies or redesign elements of Planning‐to‐Iterate.</p> <hd id="AN0173054171-34">CONCLUSION</hd> <p>This design‐based research study developed and investigated Planning‐to‐Iterate, a design argument that posits the scaffolds needed for supporting student teams' iterative practices in early stage engineering design problems. Its findings suggest that the Planning‐to‐Iterate supports iteration in engineering design: student teams conducted more coupled revisions and in a more cascaded fashion and generated a wider range of vital conclusions. That is, the students who used Planning‐to‐Iterate engaged in more expert iterative practices.</p> <p>Thus, to teach engineering design students iterative design practices, engineering design education might employ the scaffolds described in the Planning‐to‐Iterate design argument—project templates, planning templates, guiding questions, and risk checklists, all of which focus students on risks and support expert iterative practices. Furthermore, one component of these tools may be to help students to see designs as having many risks from the start of the project.</p> <p>This research contributes to our understanding of iteration in defining a design argument for how to scaffold student engineering design teams to conduct expert iterative practices. Furthermore, this research adds empirical support to the theories of iteration advanced in DRF, as scaffolds directly informed by DRF saw students engage in more expert iterative practices. Defining how to help student engineering design teams to lead their own iterations with less coaching support makes it easier to offer more effective engineering design education and more real‐world problem‐solving in engineering education. Thus, this work can directly help engineering programs to meet ABET goals. Supporting engineering design students to identify project risks and engage in expert iterative practices will better prepare them to understand and meet the needs of the stakeholders they are serving.</p> <hd id="AN0173054171-35">ACKNOWLEDGMENTS</hd> <p>We thank Bruce Sherin, Haoqi Zhang, Leesha Maliakal, Jamie Gorson, and the Delta Lab for feedback on earlier drafts and conceptualizations of this paper. This work was supported through funding by the National Science Foundation (IIS‐1530833 and IIS‐1530837), the Spencer Postdoctoral Research Fellowship.  Pepper Fellowship. Any opinions, findings, conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation or other funding bodies. Research reported in this publication was also supported, in part, by the US National Institutes of Health's National Institute of Aging, Grant Number P30AG059988. The content is solely the responsibility of the authors and does not necessarily represent the official views of the National Insitute of Health. This work extends an earlier and less well‐developed conference paper presented at the International Conference of the Learning Sciences (Rees Lewis et al., [<reflink idref="bib62" id="ref189">62</reflink>]).</p> <ref id="AN0173054171-36"> <title> REFERENCES </title> <blist> <bibl id="bib1" idref="ref14" type="bt">1</bibl> <bibtext> ABET. (2021). Criteria for accrediting engineering programs. ABET website: https://<ulink href="http://www.abet.org/wp-content/uploads/2022/01/2022-23-EAC-Criteria.pdf">www.abet.org/wp-content/uploads/2022/01/2022-23-EAC-Criteria.pdf</ulink></bibtext> </blist> <blist> <bibl id="bib2" idref="ref49" type="bt">2</bibl> <bibtext> Adams, R. S., & Atman, C. J. (1999). Cognitive processes in iterative design behavior. Paper presented at the Proceedings of the 29th ASEE/IEEE Frontiers in Education Conference, San Juan, Puerto Rico. https://doi.org/10.1109/FIE.1999.839114</bibtext> </blist> <blist> <bibl id="bib3" idref="ref7" type="bt">3</bibl> <bibtext> Adams, R. S., Turns, J., & Atman, C. J. (2003). Educating effective engineering designers: The role of reflective practice. Design Studies, 24 (3), 275 – 294. https://doi.org/10.1016/S0142-694X(02)00056-X</bibtext> </blist> <blist> <bibl id="bib4" idref="ref130" type="bt">4</bibl> <bibtext> American Society for Engineering Education. (2022). Profiles of engineering and engineering technology, 2021. Washington, DC.</bibtext> </blist> <blist> <bibl id="bib5" idref="ref8" type="bt">5</bibl> <bibtext> Atman, C. J., Adams, R. S., Cardella, M. E., Turns, J., Mosborg, S., & Saleem, J. (2007). Engineering design processes: A comparison of students and expert practitioners. Journal of Engineering Education, 96 (4), 359 – 379. https://doi.org/10.1002/j.2168-9830.2007.tb00945.x</bibtext> </blist> <blist> <bibl id="bib6" idref="ref68" type="bt">6</bibl> <bibtext> Azer, S. A., Mclean, M., Onishi, H., Tagawa, M., & Scherpbier, A. (2013). Cracks in problem‐based learning: What is your action plan? Medical Teacher, 35 (10), 806 – 814. https://doi.org/10.3109/0142159X.2013.826792</bibtext> </blist> <blist> <bibl id="bib7" idref="ref60" type="bt">7</bibl> <bibtext> Badke‐Schaub, P., & Gehrlicher, A. (2003). Patterns of decisions in design: Leaps, loops, cycles, sequences and meta‐processes. Paper presented at the DS 31: Proceedings of ICED 03, the 14th International Conference on Engineering Design, Stockholm.</bibtext> </blist> <blist> <bibl id="bib8" idref="ref82" type="bt">8</bibl> <bibtext> Ball, L. J., & Christensen, B. T. (2019). Advancing an understanding of design cognition and design metacognition: Progress and prospects. Design Studies, 65, 35 – 59. https://doi.org/10.1016/j.destud.2019.10.003</bibtext> </blist> <blist> <bibl id="bib9" idref="ref4" type="bt">9</bibl> <bibtext> Blank, S., & Dorf, B. (2012). The startup owner's manual: The step‐by‐step guide for building a great company. K&S Ranch.</bibtext> </blist> <blist> <bibtext> Boling, E., Schwier, R. A., Gray, C. M., Smith, K. M., & Campbell, K. (2016). Studio teaching in higher education: Selected design cases. Routledge. https://doi.org/10.4324/9781315697420</bibtext> </blist> <blist> <bibtext> Brown, A. L. (1992). Design experiments: Theoretical and methodological challenges in creating complex interventions in classroom settings. The Journal of the Learning Sciences, 2 (2), 141 – 178.</bibtext> </blist> <blist> <bibtext> Byrt, T., Bishop, J., & Carlin, J. B. (1993). Bias, prevalence and kappa. Journal of Clinical Epidemiology, 46 (5), 423 – 429. https://doi.org/10.1016/0895-4356(93)90018-V</bibtext> </blist> <blist> <bibtext> Carlson, S. E., Maliakal, L. V., Lewis, D. R., Gorson, J., Gerber, E., & Easterday, M. (2018). Defining and assessing risk analysis: The key to strategic iteration in real‐world problem solving. Rethinking Learning in the Digital Age: Making the Learning Sciences Count, 1, 352 – 359.</bibtext> </blist> <blist> <bibtext> Carlson, S. E., Rees Lewis, D. G., Maliakal, L. V., Gerber, E. M., & Easterday, M. W. (2020). The design risks framework: Understanding metacognition for iteration. Design Studies, 70, 100961. https://doi.org/10.1016/j.destud.2020.100961</bibtext> </blist> <blist> <bibtext> Chase, C. C., Connolly, H., Lamnina, M., & Aleven, V. (2019). Problematizing helps! A classroom study of computer‐based guidance for invention activities. International Journal of Artificial Intelligence in Education, 29 (2), 283 – 316. https://doi.org/10.1007/s40593-019-00178-y</bibtext> </blist> <blist> <bibtext> Collins, A., Joseph, D., & Bielaczyc, K. (2004). Design research: Theoretical and methodological issues. Journal of the Learning Sciences, 13 (1), 15 – 42. https://doi.org/10.1207/s15327809jls1301_2</bibtext> </blist> <blist> <bibtext> Collins, A., & Kapur, M. (2014). Cognitive apprenticeship. In K. Sawyer (Ed.), The Cambridge handbook of the learning sciences (2nd ed., pp. 109 – 127). Cambridge University Press. https://doi.org/10.1017/CBO9781139519526.008</bibtext> </blist> <blist> <bibtext> Crandall, B., Klein, G. A., & Hoffman, R. R. (2006). Working minds: A practitioner's guide to cognitive task analysis. MIT Press. https://doi.org/10.7551/mitpress/7304.001.0001</bibtext> </blist> <blist> <bibtext> Crilly, N., & Cardoso, C. (2017). Where next for research on fixation, inspiration and creativity in design? Design Studies, 50, 1 – 38. https://doi.org/10.1016/j.destud.2017.02.001</bibtext> </blist> <blist> <bibtext> Crismond, D. P., & Adams, R. S. (2012). The informed design teaching and learning matrix. Journal of Engineering Education, 101 (4), 738 – 797. https://doi.org/10.1002/j.2168-9830.2012.tb01127.x</bibtext> </blist> <blist> <bibtext> Cross, N. (2011). Design thinking: Understanding how designers think and work. Berg. https://doi.org/10.5040/9781474293884</bibtext> </blist> <blist> <bibtext> De Vries, H., Elliott, M. N., Kanouse, D. E., & Teleki, S. S. (2008). Using pooled kappa to summarize interrater agreement across many items. Field Methods, 20 (3), 272 – 282. https://doi.org/10.1177/1525822X08317166</bibtext> </blist> <blist> <bibtext> Derry, S. J., Pea, R. D., Barron, B., Engle, R. A., Erickson, F., Goldman, R., ... Sherin, B. L. (2010). Conducting video research in the learning sciences: Guidance on selection, analysis, technology, and ethics. The Journal of the Learning Sciences, 19 (1), 3 – 53. https://doi.org/10.1080/10508400903452884</bibtext> </blist> <blist> <bibtext> Dorst, K., & Cross, N. (2001). Creativity in the design process: Co‐evolution of problem–solution. Design Studies, 22 (5), 425 – 437. https://doi.org/10.1016/S0142-694X(01)00009-6</bibtext> </blist> <blist> <bibtext> Dym, C. L., Agogino, A. M., Eris, O., Frey, D. D., & Leifer, L. J. (2005). Engineering design thinking, teaching, and learning. Journal of Engineering Education, 94 (1), 103 – 120. https://doi.org/10.1002/j.2168-9830.2005.tb00832.x</bibtext> </blist> <blist> <bibtext> Easterday, M. W., Rees Lewis, D. G., & Gerber, E. M. (2017). The logic of design research. Learning: Research and Practice, 4, 1 – 30. https://doi.org/10.1080/23735082.2017.1286367</bibtext> </blist> <blist> <bibtext> Easterday, M. W., Rees Lewis, D. G., & Gerber, E. M. (2018). The logic of design research. Learning: Research and Practice, 4 (2), 131 – 160. https://doi.org/10.1080/23735082.2017.1286367</bibtext> </blist> <blist> <bibtext> Gomoll, A., Tolar, E., Hmelo‐Silver, C. E., & Šabanović, S. (2018). Designing human‐centered robots: The role of constructive failure. Thinking Skills and Creativity, 30, 90 – 102.</bibtext> </blist> <blist> <bibtext> Guindon, R. (1990). Knowledge exploited by experts during software system design. International Journal of Man‐Machine Studies, 33 (3), 279 – 304. https://doi.org/10.1016/S0020-7373(05)80120-8</bibtext> </blist> <blist> <bibtext> Hmelo‐Silver, C. E. (2004). Problem‐based learning: What and how do students learn? Educational Psychology Review, 16 (3), 235 – 266. https://doi.org/10.1023/B:EDPR.0000034022.16470.f3</bibtext> </blist> <blist> <bibtext> Hmelo‐Silver, C. E., & Barrows, H. S. (2006). Goals and strategies of a problem‐based learning facilitator. Interdisciplinary Journal of Problem‐Based Learning, 1 (1), 4. https://doi.org/10.7771/1541-5015.1004</bibtext> </blist> <blist> <bibtext> Hmelo‐Silver, C. E., & Barrows, H. S. (2008). Facilitating collaborative knowledge building. Cognition and Instruction, 26 (1), 48 – 94. https://doi.org/10.1080/07370000701798495</bibtext> </blist> <blist> <bibtext> Hmelo‐Silver, C. E., Duncan, R. G., & Chinn, C. A. (2007). Scaffolding and achievement in problem‐based and inquiry learning: A response to Kirschner, Sweller, and Clark (2006). Educational Psychologist, 42 (2), 99 – 107. https://doi.org/10.1080/00461520701263368</bibtext> </blist> <blist> <bibtext> Hung, W. (2011). Theory to reality: A few issues in implementing problem‐based learning. Educational Technology Research and Development, 59 (4), 529 – 552. https://doi.org/10.1007/s11423-011-9198-1</bibtext> </blist> <blist> <bibtext> Jonassen, D. H. (2000). Toward a design theory of problem solving. Educational Technology Research and Development, 48 (4), 63 – 85. https://doi.org/10.1007/BF02300500</bibtext> </blist> <blist> <bibtext> Jonassen, D. H., & Hung, W. (2015). All problems are not equal: Implications for problem‐based learning. In A. Walker, H. Leary, C. Hmelo‐Silver, & P. A. Ertmer (Eds.), Essential readings in problem‐based learning (pp. 7 – 41). Purdue University Press. https://doi.org/10.2307/j.ctt6wq6fh.7</bibtext> </blist> <blist> <bibtext> Knapp, J., Zeratsky, J., & Kowitz, B. (2016). Sprint: How to solve big problems and test new ideas in just five days. Simon and Schuster.</bibtext> </blist> <blist> <bibtext> Kolodner, J. L., Camp, P. J., Crismond, D., Fasse, B., Gray, J., Holbrook, J., Puntambekar, S., & Ryan, M. (2003). Problem‐based learning meets case‐based reasoning in the middle‐school science classroom: Putting learning by design (tm) into practice. The Journal of the Learning Sciences, 12 (4), 495 – 547. https://doi.org/10.1207/S15327809JLS1204_2</bibtext> </blist> <blist> <bibtext> Kunda, Z. (1990). The case for motivated reasoning. Psychological Bulletin, 108 (3), 480 – 498. https://doi.org/10.1037/0033-2909.108.3.480</bibtext> </blist> <blist> <bibtext> Lande, M., & Leifer, L. (2010). Difficulties student engineers face designing the future. International Journal of Engineering Education, 26 (2), 271‐277.</bibtext> </blist> <blist> <bibtext> Landis, J. R., & Koch, G. G. (1977). The measurement of observer agreement for categorical data. Biometrics, 33 (1), 159 – 174. https://doi.org/10.2307/2529310</bibtext> </blist> <blist> <bibtext> Lincoln, Y. S., & Guba, E. G. (1986). But is it rigorous? Trustworthiness and authenticity in naturalistic evaluation. New Directions for Program Evaluation, 1986 (30), 73 – 84. https://doi.org/10.1002/ev.1427</bibtext> </blist> <blist> <bibtext> Marks, J., & Chase, C. C. (2019). Impact of a prototyping intervention on middle school students' iterative practices and reactions to failure. Journal of Engineering Education, 108 (4), 547 – 573. https://doi.org/10.1002/jee.20294</bibtext> </blist> <blist> <bibtext> McCord, R. E., & Matusovich, H. M. (2019). Naturalistic observations of metacognition in engineering: Using observational methods to study metacognitive engagement in engineering. Journal of Engineering Education, 108 (4), 481 – 502. https://doi.org/10.1002/jee.20291</bibtext> </blist> <blist> <bibtext> Miles, M. B., Huberman, A. M., & Saldaña, J. (2014). Qualitative data analysis: A methods sourcebook (3rd ed.). Sage.</bibtext> </blist> <blist> <bibtext> Mosborg, S., Adams, R., Kim, R., Atman, C. J., Turns, J., & Cardella, M. (2005). Conceptions of the engineering design process: An expert study of advanced practicing professionals. Paper presented at the ASEE Annual Conference and Exposition, Portland, Oregon, US. https://doi.org/10.18260/1-2--14999</bibtext> </blist> <blist> <bibtext> Murray, J. K., Studer, J. A., Daly, S. R., McKilligan, S., & Seifert, C. M. (2019). Design by taking perspectives: How engineers explore problems. Journal of Engineering Education, 108 (2), 248 – 275. https://doi.org/10.1002/jee.20263</bibtext> </blist> <blist> <bibtext> NAE. (2004). The engineer of 2020: Visions of engineering in the new century. National Academies Press.</bibtext> </blist> <blist> <bibtext> National Academies of Sciences, Engineering, and Medicine. (2018). How people learn II: Learners, contexts, and cultures. National Academies Press.</bibtext> </blist> <blist> <bibtext> Nguyen, H., Wu, L., Fischer, C., Washington, G., & Warschauer, M. (2020). Increasing success in college: Examining the impact of a project‐based introductory engineering course. Journal of Engineering Education, 109, 384 – 401. https://doi.org/10.1002/jee.20319</bibtext> </blist> <blist> <bibtext> Norton, M. I., Mochon, D., & Ariely, D. (2012). The IKEA effect: When labor leads to love. Journal of Consumer Psychology, 22 (3), 453 – 460. https://doi.org/10.1016/j.jcps.2011.08.002</bibtext> </blist> <blist> <bibtext> Osterwalder, A., & Pigneur, Y. (2010). Business model generation: A handbook for visionaries, game changers, and challengers. Wiley.</bibtext> </blist> <blist> <bibtext> Pintrich, P. R. (2000). The role of goal orientation in self‐regulated learning. In M. Boekaerts, P. R. Pintrich, & M. Zeider (Eds.), Handbook of self‐regulation (pp. 451 – 502). San Diego Academic Press. https://doi.org/10.1016/B978-012109890-2/50043-3</bibtext> </blist> <blist> <bibtext> Prince, M. J., & Felder, R. M. (2006). Inductive teaching and learning methods: Definitions, comparisons, and research bases. Journal of Engineering Education, 95 (2), 123 – 138. https://doi.org/10.1002/j.2168-9830.2006.tb00884.x</bibtext> </blist> <blist> <bibtext> Puntambekar, S. (2022). Distributed scaffolding: Scaffolding students in classroom environments. Educational Psychology Review, 34 (1), 451 – 472. https://doi.org/10.1007/s10648-021-09636-3</bibtext> </blist> <blist> <bibtext> Puntambekar, S., & Kolodner, J. L. (2005). Toward implementing distributed scaffolding: Helping students learn science from design. Journal of Research in Science Teaching: The Official Journal of the National Association for Research in Science Teaching, 42 (2), 185 – 217. https://doi.org/10.1002/tea.20048</bibtext> </blist> <blist> <bibtext> Quintana, C., Reiser, B. J., Davis, E. A., Krajcik, J., Fretz, E., Duncan, R. G., Kyza, E., Edelson, D., & Soloway, E. (2018). A scaffolding design framework for software to support science inquiry. The Journal of the Learning Sciences, 13 (3), 337 – 386.</bibtext> </blist> <blist> <bibtext> Rasmusson, J. (2010). The agile samurai: How agile masters deliver great software. The Agile Samurai.</bibtext> </blist> <blist> <bibtext> Rees Lewis, D. G., Carlson, S. E., Riesbeck, C. K., Lu, K. J., Gerber, E. M., & Easterday, M. W. (2020). The logic of effective iteration in design‐based research. Paper presented at the Proceedings of the 14th International Conference of the Learning Sciences, Nashville, TN.</bibtext> </blist> <blist> <bibtext> Rees Lewis, D. G., Easterday, M. W., Harburg, E., Gerber, E. M., & Riesbeck, C. K. (2018). Overcoming barriers between volunteer professionals advising project‐based learning teams with regulation tools. British Journal of Educational Technology, 49 (3), 354 – 369. https://doi.org/10.1111/bjet.12550</bibtext> </blist> <blist> <bibtext> Rees Lewis, D. G., Gerber, E. M., Carlson, S. E., & Easterday, M. W. (2019). Opportunities for educational innovations in authentic project‐based learning: Understanding instructor perceived challenges to design for adoption. Educational Technology Research and Development, 67 (4), 953 – 982. https://doi.org/10.1007/s11423-019-09673-4</bibtext> </blist> <blist> <bibtext> Rees Lewis, D. G., Gorson, J. S., Maliakal, L. V., Carlson, S. E., Gerber, E. M., & Easterday, M. W. (2018). Planning to iterate: Supporting iterative practices for real‐world ill‐structured problem‐solving. Rethinking Learning in the Digital Age: Making the Learning Sciences Count, 1, 9 – 16.</bibtext> </blist> <blist> <bibtext> Reiser, B. J. (2004). Scaffolding complex learning: The mechanisms of structuring and problematizing student work. Journal of the Learning Sciences, 13 (3), 273 – 304. https://doi.org/10.1207/s15327809jls1303_2</bibtext> </blist> <blist> <bibtext> Scardamalia, M., & Bereiter, C. (1994). Computer support for knowledge‐building communities. The Journal of the Learning Sciences, 3 (3), 265 – 283. https://doi.org/10.1207/s15327809jls0303_3</bibtext> </blist> <blist> <bibtext> Schön, D. A. (1983). The reflective practitioner: How professionals think in action. Basic Books.</bibtext> </blist> <blist> <bibtext> Shaffer, D. W., & Resnick, M. (1999). "Thick" authenticity: New media and authentic learning. Journal of Interactive Learning Research, 10 (2), 195 – 216.</bibtext> </blist> <blist> <bibtext> Shenton, A. K. (2004). Strategies for ensuring trustworthiness in qualitative research projects. Education for Information, 22 (2), 63 – 75. https://doi.org/10.3233/EFI-2004-22201</bibtext> </blist> <blist> <bibtext> Sherin, B., Reiser, B. J., & Edelson, D. (2004). Scaffolding analysis: Extending the scaffolding metaphor to learning artifacts. The Journal of the Learning Sciences, 13 (3), 387 – 421. https://doi.org/10.1207/s15327809jls1303_5</bibtext> </blist> <blist> <bibtext> Sherman, D. K., & Cohen, G. L. (2006). The psychology of self‐defense: Self‐affirmation theory. Advances in Experimental Social Psychology, 38, 183 – 242. https://doi.org/10.1016/S0065-2601(06)38004-5</bibtext> </blist> <blist> <bibtext> Silverman, D. (2015). Interpreting qualitative data (5th ed.). Sage.</bibtext> </blist> <blist> <bibtext> Simon, H. A. (1973). The structure of ill structured problems. Artificial Intelligence, 4 (3–4), 181 – 201. https://doi.org/10.1016/0004-3702(73)90011-8</bibtext> </blist> <blist> <bibtext> Siverling, E. A., Moore, T. J., Suazo‐Flores, E., Mathis, C. A., & Guzey, S. S. (2021). What initiates evidence‐based reasoning?: Situations that prompt students to support their design ideas and decisions. Journal of Engineering Education, 110 (2), 294 – 317. https://doi.org/10.1002/jee.20384</bibtext> </blist> <blist> <bibtext> Smith, R. P., & Tjandra, P. (1998). Experimental observation of iteration in engineering design. Research in Engineering Design, 10 (2), 107 – 117. https://doi.org/10.1007/BF01616691</bibtext> </blist> <blist> <bibtext> Tawfik, A. A., & Kolodner, J. L. (2016). Systematizing scaffolding for problem‐based learning: A view from case‐based reasoning. Interdisciplinary Journal of Problem‐Based Learning, 10 (1), 6, 385‐406. https://doi.org/10.7771/1541-5015.1608</bibtext> </blist> <blist> <bibtext> Tofel‐Grehl, C., & Feldon, D. F. (2013). Cognitive task analysis‐based training: A meta‐analysis of studies. Journal of Cognitive Engineering and Decision Making, 7 (3), 293 – 304. https://doi.org/10.1177/1555343412474821</bibtext> </blist> <blist> <bibtext> van den Akker, J. (1999). Principles and methods of development research. In J. van den Akker, R. M. Branch, K. Gustafson, N. Nieveen, & T. Plomp (Eds.). Design approaches and tools in education and training (pp. 1‐14). Springer Netherlands. https://doi.org/10.1007/978-94-011-4255-7</bibtext> </blist> <blist> <bibtext> Winne, P. H., & Azevedo, R. (2014). Metacognition. In K. Sawyer (Ed.), The Cambridge handbook of the learning sciences (2nd ed., pp. 63 – 87). Cambridge University Press. https://doi.org/10.1017/CBO9781139519526.006</bibtext> </blist> <blist> <bibtext> Wynn, D. C., & Eckert, C. M. (2017). Perspectives on iteration in design and development. Research in Engineering Design, 28 (2), 153 – 184. https://doi.org/10.1007/s00163-016-0226-3</bibtext> </blist> <blist> <bibtext> Zhang, H., Easterday, M. W., Gerber, E. M., Rees Lewis, D., & Maliakal, L. (2017). Agile research studios: Orchestrating communities of practice to advance research training. Paper presented at the Proceedings of the ACM Conference on Computer Supported Cooperative Work and Social Computing, Portland, Oregon, USA. https://doi.org/10.1145/2998181.2998199</bibtext> </blist> </ref> <aug> <p>By Daniel G. Rees Lewis; Spencer E. Carlson; Christopher K. Riesbeck; Elizabeth M. Gerber and Matthew W. Easterday</p> <p>Reported by Author; Author; Author; Author; Author</p> <p></p> <p>Daniel G. Rees Lewis is a Researcher Professor of Design, HCI, and Learning at Northwestern University, 2133 Sheridan Drive Evanston, IL 60208; daniel‐lewis@northwestern.edu.</p> <p>Spencer E. Carlson is a Researcher in the Delta Lab at Northwestern University, 2133 Sheridan Drive Evanston, IL 60208; spencer.carlson@me.com.</p> <p>Christopher K. Riesbeck is an Associate Professor of Computer Scienceat Northwestern University, 2233 Tech Drive Seely Mudd; c‐riesbeck@northwestern.edu.</p> <p>Elizabeth M. Gerber a Professor of Mechanical Engineering and Communication Studies, 2133 Sheridan Drive Evanston, IL 60208; egerber@northwestern.edu.</p> <p>Matthew W. Easterday is an Associate Professor of Learning Sciences at Northwestern University, 2210 Campus Drive, Annenberg Hall; easterday@northwestern.edu.</p> </aug> <nolink nlid="nl1" bibid="bib36" firstref="ref1"></nolink> <nolink nlid="nl2" bibid="bib71" firstref="ref2"></nolink> <nolink nlid="nl3" bibid="bib37" firstref="ref3"></nolink> <nolink nlid="nl4" bibid="bib43" firstref="ref5"></nolink> <nolink nlid="nl5" bibid="bib20" firstref="ref6"></nolink> <nolink nlid="nl6" bibid="bib78" firstref="ref9"></nolink> <nolink nlid="nl7" bibid="bib35" firstref="ref10"></nolink> <nolink nlid="nl8" bibid="bib65" firstref="ref11"></nolink> <nolink nlid="nl9" bibid="bib40" firstref="ref13"></nolink> <nolink nlid="nl10" bibid="bib48" firstref="ref15"></nolink> <nolink nlid="nl11" bibid="bib30" firstref="ref16"></nolink> <nolink nlid="nl12" bibid="bib31" firstref="ref17"></nolink> <nolink nlid="nl13" bibid="bib24" firstref="ref25"></nolink> <nolink nlid="nl14" bibid="bib10" firstref="ref29"></nolink> <nolink nlid="nl15" bibid="bib50" firstref="ref30"></nolink> <nolink nlid="nl16" bibid="bib18" firstref="ref32"></nolink> <nolink nlid="nl17" bibid="bib75" firstref="ref33"></nolink> <nolink nlid="nl18" bibid="bib66" firstref="ref34"></nolink> <nolink nlid="nl19" bibid="bib46" firstref="ref43"></nolink> <nolink nlid="nl20" bibid="bib29" firstref="ref48"></nolink> <nolink nlid="nl21" bibid="bib73" firstref="ref51"></nolink> <nolink nlid="nl22" bibid="bib51" firstref="ref59"></nolink> <nolink nlid="nl23" bibid="bib61" firstref="ref63"></nolink> <nolink nlid="nl24" bibid="bib34" firstref="ref69"></nolink> <nolink nlid="nl25" bibid="bib33" firstref="ref70"></nolink> <nolink nlid="nl26" bibid="bib54" firstref="ref71"></nolink> <nolink nlid="nl27" bibid="bib17" firstref="ref72"></nolink> <nolink nlid="nl28" bibid="bib74" firstref="ref74"></nolink> <nolink nlid="nl29" bibid="bib32" firstref="ref76"></nolink> <nolink nlid="nl30" bibid="bib13" firstref="ref80"></nolink> <nolink nlid="nl31" bibid="bib14" firstref="ref81"></nolink> <nolink nlid="nl32" bibid="bib77" firstref="ref83"></nolink> <nolink nlid="nl33" bibid="bib49" firstref="ref84"></nolink> <nolink nlid="nl34" bibid="bib53" firstref="ref85"></nolink> <nolink nlid="nl35" bibid="bib19" firstref="ref87"></nolink> <nolink nlid="nl36" bibid="bib76" firstref="ref94"></nolink> <nolink nlid="nl37" bibid="bib26" firstref="ref95"></nolink> <nolink nlid="nl38" bibid="bib59" firstref="ref96"></nolink> <nolink nlid="nl39" bibid="bib27" firstref="ref97"></nolink> <nolink nlid="nl40" bibid="bib68" firstref="ref99"></nolink> <nolink nlid="nl41" bibid="bib38" firstref="ref104"></nolink> <nolink nlid="nl42" bibid="bib52" firstref="ref105"></nolink> <nolink nlid="nl43" bibid="bib58" firstref="ref106"></nolink> <nolink nlid="nl44" bibid="bib47" firstref="ref107"></nolink> <nolink nlid="nl45" bibid="bib63" firstref="ref108"></nolink> <nolink nlid="nl46" bibid="bib56" firstref="ref110"></nolink> <nolink nlid="nl47" bibid="bib15" firstref="ref111"></nolink> <nolink nlid="nl48" bibid="bib64" firstref="ref114"></nolink> <nolink nlid="nl49" bibid="bib72" firstref="ref118"></nolink> <nolink nlid="nl50" bibid="bib57" firstref="ref121"></nolink> <nolink nlid="nl51" bibid="bib11" firstref="ref125"></nolink> <nolink nlid="nl52" bibid="bib25" firstref="ref127"></nolink> <nolink nlid="nl53" bibid="bib12" firstref="ref129"></nolink> <nolink nlid="nl54" bibid="bib45" firstref="ref142"></nolink> <nolink nlid="nl55" bibid="bib67" firstref="ref143"></nolink> <nolink nlid="nl56" bibid="bib42" firstref="ref147"></nolink> <nolink nlid="nl57" bibid="bib70" firstref="ref148"></nolink> <nolink nlid="nl58" bibid="bib22" firstref="ref151"></nolink> <nolink nlid="nl59" bibid="bib41" firstref="ref153"></nolink> <nolink nlid="nl60" bibid="bib21" firstref="ref154"></nolink> <nolink nlid="nl61" bibid="bib39" firstref="ref163"></nolink> <nolink nlid="nl62" bibid="bib69" firstref="ref164"></nolink> <nolink nlid="nl63" bibid="bib55" firstref="ref171"></nolink> <nolink nlid="nl64" bibid="bib79" firstref="ref176"></nolink> <nolink nlid="nl65" bibid="bib28" firstref="ref179"></nolink> <nolink nlid="nl66" bibid="bib60" firstref="ref180"></nolink> <nolink nlid="nl67" bibid="bib23" firstref="ref184"></nolink> <nolink nlid="nl68" bibid="bib44" firstref="ref185"></nolink> <nolink nlid="nl69" bibid="bib16" firstref="ref186"></nolink> <nolink nlid="nl70" bibid="bib62" firstref="ref189"></nolink>
Header DbId: eric
DbLabel: ERIC
An: EJ1396465
AccessLevel: 3
PubType: Academic Journal
PubTypeId: academicJournal
PreciseRelevancyScore: 0
IllustrationInfo
Items – Name: Title
  Label: Title
  Group: Ti
  Data: Encouraging Engineering Design Teams to Engage in Expert Iterative Practices with Tools to Support Coaching in Problem-Based Learning
– Name: Language
  Label: Language
  Group: Lang
  Data: English
– Name: Author
  Label: Authors
  Group: Au
  Data: <searchLink fieldCode="AR" term="%22Rees+Lewis%2C+Daniel+G%2E%22">Rees Lewis, Daniel G.</searchLink> (ORCID <externalLink term="https://orcid.org/0000-0002-0928-3831">0000-0002-0928-3831</externalLink>)<br /><searchLink fieldCode="AR" term="%22Carlson%2C+Spencer+E%2E%22">Carlson, Spencer E.</searchLink><br /><searchLink fieldCode="AR" term="%22Riesbeck%2C+Christopher+K%2E%22">Riesbeck, Christopher K.</searchLink><br /><searchLink fieldCode="AR" term="%22Gerber%2C+Elizabeth+M%2E%22">Gerber, Elizabeth M.</searchLink><br /><searchLink fieldCode="AR" term="%22Easterday%2C+Matthew+W%2E%22">Easterday, Matthew W.</searchLink>
– Name: TitleSource
  Label: Source
  Group: Src
  Data: <searchLink fieldCode="SO" term="%22Journal+of+Engineering+Education%22"><i>Journal of Engineering Education</i></searchLink>. 2023 112(4):1012-1031.
– Name: Avail
  Label: Availability
  Group: Avail
  Data: Wiley. Available from: John Wiley & Sons, Inc. 111 River Street, Hoboken, NJ 07030. Tel: 800-835-6770; e-mail: cs-journals@wiley.com; Web site: https://www.wiley.com/en-us
– Name: PeerReviewed
  Label: Peer Reviewed
  Group: SrcInfo
  Data: Y
– Name: Pages
  Label: Page Count
  Group: Src
  Data: 20
– Name: DatePubCY
  Label: Publication Date
  Group: Date
  Data: 2023
– Name: SourceSuprt
  Label: Sponsoring Agency
  Group: SrcSuprt
  Data: National Science Foundation (NSF), Division of Information and Intelligent Systems (IIS)
– Name: NumberContract
  Label: Contract Number
  Group: NumCntrct
  Data: 1530833<br />1530837
– Name: TypeDocument
  Label: Document Type
  Group: TypDoc
  Data: Journal Articles<br />Reports - Research
– Name: Subject
  Label: Descriptors
  Group: Su
  Data: <searchLink fieldCode="DE" term="%22Engineering%22">Engineering</searchLink><br /><searchLink fieldCode="DE" term="%22Design%22">Design</searchLink><br /><searchLink fieldCode="DE" term="%22Coaching+%28Performance%29%22">Coaching (Performance)</searchLink><br /><searchLink fieldCode="DE" term="%22Problem+Based+Learning%22">Problem Based Learning</searchLink><br /><searchLink fieldCode="DE" term="%22Problem+Solving%22">Problem Solving</searchLink><br /><searchLink fieldCode="DE" term="%22Expertise%22">Expertise</searchLink><br /><searchLink fieldCode="DE" term="%22Teaching+Methods%22">Teaching Methods</searchLink><br /><searchLink fieldCode="DE" term="%22Metacognition%22">Metacognition</searchLink><br /><searchLink fieldCode="DE" term="%22Engineering+Education%22">Engineering Education</searchLink><br /><searchLink fieldCode="DE" term="%22Cooperative+Learning%22">Cooperative Learning</searchLink><br /><searchLink fieldCode="DE" term="%22Planning%22">Planning</searchLink><br /><searchLink fieldCode="DE" term="%22Risk%22">Risk</searchLink>
– Name: DOI
  Label: DOI
  Group: ID
  Data: 10.1002/jee.20554
– Name: ISSN
  Label: ISSN
  Group: ISSN
  Data: 1069-4730<br />2168-9830
– Name: Abstract
  Label: Abstract
  Group: Ab
  Data: Background: To create design solutions experienced engineering designers engage in expert iterative practice. Researchers find that students struggle to learn this critical engineering design practice, particularly when tackling real-world engineering design problems. Purpose/Hypothesis: To improve our ability to teach iteration, this study contributes (i) a new teaching approach to improve student teams' expert iterative practices, and (ii) provides support to existing frameworks--chiefly the Design Risk Framework--that predict the key metacognitive processes we should support to help students to engage in expert iterative practices in real-world engineering design. Design/Method: In a 3-year design-based research study, we developed a novel approach to teaching students to take on real-world engineering design projects with real clients, users, and contexts to engage in expert iterative practices. Results: Study 1 confirms that student teams struggle to engage in expert iterative practices, even when supported by problem-based learning (PBL) coaching. Study 2 tests our novel approach, Planning-to-Iterate, which uses (i) templates, (ii) guiding questions to help students to define problem and solution elements, and (iii) risk checklists to help student teams to identify risks. We found that student teams using Planning-to-Iterate engaged in more expert iterative practices while receiving less PBL coaching. Conclusions: This work empirically tests a design argument--a theory for a novel teaching approach--that augments PBL coaching and helps students to identify risks and engage in expert iterative practices in engineering design projects.
– Name: AbstractInfo
  Label: Abstractor
  Group: Ab
  Data: As Provided
– Name: DateEntry
  Label: Entry Date
  Group: Date
  Data: 2023
– Name: AN
  Label: Accession Number
  Group: ID
  Data: EJ1396465
PLink https://search.ebscohost.com/login.aspx?direct=true&site=eds-live&db=eric&AN=EJ1396465
RecordInfo BibRecord:
  BibEntity:
    Identifiers:
      – Type: doi
        Value: 10.1002/jee.20554
    Languages:
      – Text: English
    PhysicalDescription:
      Pagination:
        PageCount: 20
        StartPage: 1012
    Subjects:
      – SubjectFull: Engineering
        Type: general
      – SubjectFull: Design
        Type: general
      – SubjectFull: Coaching (Performance)
        Type: general
      – SubjectFull: Problem Based Learning
        Type: general
      – SubjectFull: Problem Solving
        Type: general
      – SubjectFull: Expertise
        Type: general
      – SubjectFull: Teaching Methods
        Type: general
      – SubjectFull: Metacognition
        Type: general
      – SubjectFull: Engineering Education
        Type: general
      – SubjectFull: Cooperative Learning
        Type: general
      – SubjectFull: Planning
        Type: general
      – SubjectFull: Risk
        Type: general
    Titles:
      – TitleFull: Encouraging Engineering Design Teams to Engage in Expert Iterative Practices with Tools to Support Coaching in Problem-Based Learning
        Type: main
  BibRelationships:
    HasContributorRelationships:
      – PersonEntity:
          Name:
            NameFull: Rees Lewis, Daniel G.
      – PersonEntity:
          Name:
            NameFull: Carlson, Spencer E.
      – PersonEntity:
          Name:
            NameFull: Riesbeck, Christopher K.
      – PersonEntity:
          Name:
            NameFull: Gerber, Elizabeth M.
      – PersonEntity:
          Name:
            NameFull: Easterday, Matthew W.
    IsPartOfRelationships:
      – BibEntity:
          Dates:
            – D: 01
              M: 01
              Type: published
              Y: 2023
          Identifiers:
            – Type: issn-print
              Value: 1069-4730
            – Type: issn-electronic
              Value: 2168-9830
          Numbering:
            – Type: volume
              Value: 112
            – Type: issue
              Value: 4
          Titles:
            – TitleFull: Journal of Engineering Education
              Type: main
ResultId 1