Abstract

Incorporation of contextual factors into design processes is important for successful engineering design outcomes. Through document analysis and semi-structured interviews, we investigated the types of contextual factors incorporated by novice engineering designers and their approaches during design processes. Our findings demonstrated that participants primarily considered technical and institutional contextual factors across all design stages, informed largely by contextual observations and interviews with stakeholders. Socio-political contextual factors were less frequently considered. We also found that a broader set of contextual factors were incorporated when projects were set in unfamiliar contexts. And, contextual factors that could be easily quantified were more readily applied to design decisions. We suggest that there are opportunities for more intentional approaches to incorporating contextual factors throughout design processes.

1 Introduction

Successful product design requires not only the incorporation of technical and stakeholder information throughout a design process but also the incorporation of many relevant contextual factors, i.e., characteristics of a potential solution's broad use-context, such as the industrial, institutional, and cultural context, which can affect how stakeholders interact with it in practice [13]. Contextual factors are particularly critical when designers work within international or low-income contexts, where a designer’s experience in the intended use-context may be limited [46]. Product failure due to designers’ lack of incorporating relevant contextual information has been documented in the literature [7,8]. For example, millions of people in Bangladesh were left to drink contaminated water after the United Nations implemented a well-drilling program without investigating the environmental context [9]. In another high-profile example, governments around the world felt the unsuccessful promise of the One Laptop Per Child due to designers failing to take into account the full institutional, economic, and educational contexts of their countries [10]. While a handful of studies have suggested that experienced engineering designers are skilled at considering the broader context of a designed artifact [11,12], limited research has examined how designers learn about and incorporate contextual factors at the beginning of their careers. Understanding how novice engineering designers incorporate context would establish a baseline for understanding how they differ from experts and inform pedagogy for design educators.

While previous literature recommends that engineers incorporate contextual factors into design decisions [4,13,14], engineering remains focused on technical performance over appropriateness for context. As such, many scholars argue that much more attention to context is needed [1518], particularly in decision-making models [1921]. Furthermore, there is increased interest in tools to deepen novice engineering designers’ consideration of contextual information [2224]. For example, some prior work has investigated how engineering students consider contextual information during specific design stages of problem scoping [25] or requirements development [26], but incorporating contextual factors throughout multiple stages in a design has yet to be investigated. This study explores the behaviors of novice engineering designers as they incorporate (or do not incorporate) contextual information throughout design processes.

2 Background

2.1 Importance of Incorporating Context in Engineering Design.

Contextual factors are elements of a product's broad use-context that can affect how the product is implemented and used in practice. Scholars recommend that designers incorporate contextual factors [4,5], i.e., engineers should consider the implications of contextual factors when arriving at design decisions, throughout engineering design processes. Notably, findings from a study investigating technologies implemented by Engineers Without Borders found that designers “failing to have adequate contextual knowledge” was the top reason for project failures [7]. Failing to incorporate relevant contextual information has also been documented to lead to design outcome failures for a broad range of solutions: energy systems [27,28], sanitation solutions [29], water treatment technology [8,30], medical devices [4], and information technology [31].

2.2 Design Processes and Methods to Investigate Contextual Factors.

A variety of people-focused design processes emphasize methods to investigate the context of stakeholders (most often the intended users), such as participatory design, human-centered design, and empathic design, among others. Many of these design methodologies include an immersive “empathy-building” stage, requiring designers to spend time in the use-context and collect relevant stakeholder and contextual information [3234]. Participatory design requires the direct involvement of people as co-designers throughout a design process, emphasizing their expertise, experiences, values, and context [35]. Participatory design methods encourage co-design activities to collect and incorporate more contextualized information [36]. Other design methodologies, such as social and contextual design [37,38], focus the designer's attention on a broader set of stakeholders and contextual information, especially those that may be initially hidden from the designer's view. Engineers have also used ethnographic methods from the social sciences to investigate and gather contextual information. Traditional ethnography is a lengthy, detailed observational practice aimed at providing the researcher with an understanding of context-specific attributes; it is a process that requires months or years of fieldwork [39]. However, design ethnography [40] and rapid ethnography [41] have emerged as shorter versions of these traditional methods, while continuing to emphasize participant observation. In particular, design ethnography calls for contextual investigation of individuals and communities to inform problem definition, requirements development, and solution evaluation [38,42,43]. Although these methodologies encourage an understanding of contextual information, they lack specific guidance for incorporating relevant factors into various stages across design processes.

In fields that center on technological innovation as a driver for social and economic development, e.g., humanitarian engineering [44], development engineering [45], and global engineering [46], scholars emphasize investigating context during design processes. One review synthesized ten recommendations for designing solutions to support the development of marginalized societies, of which “developing a holistic understanding of the context” was identified as the first guideline [47]. Another study of medical devices designed for use in low-resource settings identified nine categories of contextual information relevant for designers: technological, industrial, institutional, public health, infrastructure, economic, political, socio-cultural, and environmental [4]. Products designed for use in low- and middle-income countries (LMICs) risk contributing to neocolonialism when designers fail to suitably incorporate social, cultural, and industrial considerations, among other factors [48,49]. As such, engineers in global health and development applications frequently use processes and methods to collect and apply contextualized information [5,50]. One study identified that most engineering-for-development design literature explicitly investigated relevant contextual information, particularly during early-stage needs assessment and back-end field testing [51].

2.3 Investigating the Practices of Novice Engineering Designers.

Several studies have investigated upper-level undergraduate engineering students [5255] to identify what knowledge and information students have absorbed and what skills or gaps exist in their behaviors and practices. This research finds that novice engineering designers focus on objective features and follow strict rules to problem-solve [52], focusing on technical details of engineering design [56] and often neglecting the larger context [54]. Perhaps surprisingly, fourth-year engineering students have a narrower view of contextual factors when compared with first-year students [25,57], similarly suggesting that a traditional engineering education may focus attention on technical concerns at the expense of context.

Capstone design experiences are a so-called “turning point” for students’ development of information literacy, i.e., skills, abilities, and attitudes surrounding the gathering, management, and application of information [58]. Thus, scholars often investigate engineering behavior while students participate in capstone projects because it integrates multiple concepts from students' education [26]. Along these lines, Eteläpelto [11] suggests that design courses can be used as an opportunity to promote students’ “orientation to users’ contextual knowledge.” However, the authors do not identify any specific design stages during which contextual information can be explicitly used. In another study of capstone engineering design teams, researchers determined a direct correlation between the number of distinct information sources used and the level of “tailoring of the requirements to the design context,” recommending that novice engineering designers gather information from diverse sources as a useful strategy for identifying context- and stakeholder-specific requirements [26]. In one study of a senior capstone course, Neumeyer et al. [23] identified that while some students incorporate broader global, social, economic, and environmental contextual factors into their designs, others do not; the authors, however, do not identify what mindsets or motivations account for the difference.

During capstone projects, novice engineering designers may benefit from tools and methods to facilitate familiarization and sorting of information gathered during contextual investigation. Recommendations by some researchers [59,60] provide general guidance for synthesizing and applying broad sets of gathered information during design processes. However, tools or methods for identifying, collecting, and synthesizing contextual information during design processes are lacking [60]. While novice engineering designers have been shown to elicit contextual factors during design, they may be using such approaches in unintentional and unstructured ways [53,61].

Overall, examining novice engineering designers can be used as a baseline to compare behaviors with experienced engineering designers, explore design pedagogy gaps, and offer recommendations for professional practice [62]. Studies of designer behavior have shown that experts elicit more detailed information from stakeholders [63] and gather more contextual data [64,65] than novices. However, how exactly they do this has not been examined in detail. Moreover, while categorizations of contextual factors exist (e.g., Ref. [4]), existing research has not considered contextual incorporation by novice engineering designers according to such categories.

In our research, we sought a more detailed understanding of how and at what stage of a design processes novice engineering designers incorporate contextual factors. Such an understanding should further illuminate differences between novice and expert design engineers and inform the development of pedagogical scaffolding to promote engineering designers’ understanding and use of contextual factors during design processes.

3 Methods

We investigated how novice engineering designers incorporate contextual factors, with attention paid to which contextual factors they emphasize and at what point in their design processes they involve them. The following research questions guided this study:

RQ1: How do novice engineering designers incorporate contextual factors during their design processes?

RQ2: What contextual factors do novice engineering designers consider more important in their design processes?

Due to the exploratory nature of the research questions, we used a qualitative research approach [66], which included analysis of 20 capstone design final reports and semi-structured interviews with members representing ten of the corresponding teams.

3.1 Data Source.

We investigated novice engineering designer practice within the context of final-year undergraduate capstone design course projects. At the university, where this study was conducted, most undergraduate engineering students complete a single-semester capstone design project, typically in their final year of study. Projects in these courses range in scope and application. In one capstone mechanical engineering design course, approximately 30 unique projects are solicited per semester by the instructional teams from various project sponsors including industry, research, and community sponsors. During the timeframe when this study was conducted, the majority of offered projects in this course involved a U.S.-based sponsor (noted in this manuscript as projects for domestic contexts) and roughly 20% of the projects offered were global health-themed, involving an institutional sponsor based in an LMIC (noted in this manuscript as projects for international contexts). Students were divided into teams of three to five; their project preferences were considered prior to project assignment by the instructional teams. The course's primary objective was for students to “solve an open-ended mechanical engineering design problem including considerations of performance, cost, standards, and societal impact” (from the capstone course syllabus).

As part of the coursework, instructors recommended that teams meet with key stakeholders throughout the semester. During the course, the teams completed four “Design Reviews,” which included a written and/or oral presentation. As part of the written deliverables, teams were required to cite all background knowledge properly and include a bibliography with a minimum of 20 sources. As a final deliverable, teams submitted a lengthy, cumulative report that included the following required elements: problem description and background, user requirements and engineering specifications, concept generation, concept selection, concept description, verification and validation results, discussion, and design critique. Capstone design final reports are well-suited for investigating novice designer behavior due to the clear structure that they must follow [67,68].

A subset of the students in the capstone course also completed an immersive global experiential learning experience during the summer preceding their enrollment in the capstone course [69]. This immersive experience included two months of preparatory training in the United States, followed by 6–8 weeks abroad at the sponsoring institution. Since a designer's contextual experience influences perceptions and behavior during design processes [70], we specifically included data from both international and domestic projects, acknowledging that students working on domestic projects likely had more familiarity with the project context than those working in global contexts.

3.2 Data Collection.

To investigate the research questions, we collected two sets of data. The first, reported by Burleson et al. [71], included a sample of ten capstone design final reports comprising five projects in international contexts and five projects in domestic contexts [71]. Next, we recruited ten other engineering capstone teams to participate in 90-minute semi-structured interviews; additionally, this set of data also included these teams’ final reports. Between 1 and 5 team members participated in each interview; the unit of analysis for this study was the team. We recruited teams via in-class announcements and emails. We compensated volunteering students for their time during the interview.

We asked participating students to bring visual representations of their capstone projects, such as computer aided design (CAD) drawings, photos, or images in their final reports, to the interview to ground the retrospective questions shown in Table 1. The interview protocol was developed with semi-structured questions to elicit contextual information that influenced their design processes, following the main design stages used in the capstone course. To answer our second research question, participants were asked whether specific factors influenced their design or process. We selected the taxonomy presented by Aranda-Jan et al. [4], which identified nine primary categories for contextual factors based on a literature analysis of medical device design. The research team created a corresponding series of nine cards, each with a contextual factor, definition, and series of examples from Ref. [4], as shown in Fig. 1. These were placed one at a time in front of the participants, with order of presentation varied such that the interviewer could start with the categories that were most familiar to the participant(s). The research team's final interview protocol went through four major iterations and was piloted three times with former mechanical engineering students.

Fig. 1
Set of cards shown to interview participants of contextual factor categories, inspired by taxonomy by Aranda-Jan et al. [4]
Fig. 1
Set of cards shown to interview participants of contextual factor categories, inspired by taxonomy by Aranda-Jan et al. [4]
Close modal
Table 1

Overview of the 90-minute semi-structured interview protocol

Introduction (10 min)
 Study background and participant verbal consent
Project-specific details and warm-up (15 min)
 Walk me through the goals and outcomes of your capstone project
 Can you tell me more about your end user(s)?
 For your project, walk me through how you learned about your end user?
 Did you ever meet with any end users? What about other project stakeholders?
Overview of capstone design stagesProbe for contextual factors based on responses (25 min)
Problem scoping: Can you give me more details about the way you went about understanding the problem at hand?
Requirements development: Walk me through the way in which you developed your design requirements.
Concept development: Walk me through how your team came up with concepts for your design.
Final concept: Can you tell me about one of your key design features? What were the reasons for those choices?
Verification/validation: Walk me through your process for evaluating your concept.
Contextual factor categories: Walkthrough (35 min)
 One by one, let’s go through Aranda-Jan et al.’s contextual factor categories (technological, industrial, institutional, infrastructure, environmental, political, economic, public health, and socio-cultural), so that you can walk me through the contextual factors that you incorporated across your design process that you have not mentioned yet.
Wrap-up (5 min)
Introduction (10 min)
 Study background and participant verbal consent
Project-specific details and warm-up (15 min)
 Walk me through the goals and outcomes of your capstone project
 Can you tell me more about your end user(s)?
 For your project, walk me through how you learned about your end user?
 Did you ever meet with any end users? What about other project stakeholders?
Overview of capstone design stagesProbe for contextual factors based on responses (25 min)
Problem scoping: Can you give me more details about the way you went about understanding the problem at hand?
Requirements development: Walk me through the way in which you developed your design requirements.
Concept development: Walk me through how your team came up with concepts for your design.
Final concept: Can you tell me about one of your key design features? What were the reasons for those choices?
Verification/validation: Walk me through your process for evaluating your concept.
Contextual factor categories: Walkthrough (35 min)
 One by one, let’s go through Aranda-Jan et al.’s contextual factor categories (technological, industrial, institutional, infrastructure, environmental, political, economic, public health, and socio-cultural), so that you can walk me through the contextual factors that you incorporated across your design process that you have not mentioned yet.
Wrap-up (5 min)

The first eight interviews were conducted in person (as initially planned), and the final two were conducted remotely via video conferencing due to the outbreak of the novel coronavirus (COVID-19). The only modification to the interview protocol was the use of a slide deck (with the same content as the printed cards) that was screen-shared one slide at a time instead of the presentation of printed paper cards for each contextual factor.

Interviews were recorded and transcribed by a third-party transcription service. The University's Institutional Review Board determined unregulated status for the use of the first dataset of capstone design final reports (HUM00176110) and exempt status for the second dataset, which included both interview and capstone design final report collection (HUM00172047).

3.3 Data Summary.

This study included data from 20 senior-level capstone engineering teams (19 in mechanical engineering and one in biomedical engineering) from a large university in the United States. The data collected consisted of 20 final reports and transcripts from 10 semi-structured interviews. Eleven teams worked on projects in international contexts, of which 10 teams had at least one member who visited the project site during a global health design program the summer before their design capstone course. The remaining nine teams completed domestic projects in the United States. Table 2 provides a complete list of the dataset, including project type, intended users, sponsor location (international or domestic), discipline, participation in the university's summer global health design program, type of data, and team identifier used for coding (code).

3.4 Data Analysis.

The complete dataset (20 final reports and 10 transcripts) was deductively coded for instances of teams incorporating contextual factors, which were categorized by the taxonomy defined in Fig. 1. Two researchers started by independently coding three randomly selected transcripts and final reports from the dataset and calculating intercoder reliability (ICR), i.e., the total number of agreements for all the categories per document (out of nine possible) divided by the sum of agreements and disagreements. Using a negotiated agreement approach [72], the coders resolved all disagreements by reconciling discrepancies or iterating and clarifying the definitions in the codebook; we present final definitions for each contextual category in our results. The average ICR score was 0.88, which is considered strong [73], and thus, the researchers independently coded the remaining transcripts and final reports. For each coded excerpt, the corresponding design stage of the capstone project was noted; these design stages were classified based on the six primary design stages in the capstone course: problem description/background (which we term “problem scoping” in this study), requirements and specifications, concept generation, concept selection, refinement, and verification and validation. Prompts for these stages were explicitly included in the course design review guidelines. To enable a more nuanced and detailed analysis, we used a reflexive thematic analysis clustering approach [74] to organize excerpts of each primary category into mutually exclusive secondary categories, presented in the results, and identify themes grounded by our research questions. Excerpts within each secondary category were reviewed, and themes were synthesized (e.g., priorities and approaches for incorporating contextual factors, impact on their design processes, challenges, and perceptions) as part of an iterative thematic analysis performed by all study team members.

4 Results

4.1 Design Stages and Approaches Novices Used to Incorporate Contextual Factors.

Our analysis showed that participating teams incorporated 266 contextual factors into their design processes across all major stages in the capstone course, but primarily during the front-end stages of problem scoping and requirements development. We identified more contextual factors in the dataset that included both final reports and interviews (181 contextual factors) than the final report-only dataset (85 contextual factors), indicating that even fairly comprehensive final reports leave out details of how contextual factors affect design processes. Figure 2 illustrates the design stages during which teams incorporated contextual factors and the primary approaches used.

Fig. 2
Summary of the design stages during which participant teams incorporated contextual factors. The numbers on the right represent the number of contextual factors identified during each stage across 20 novice engineering design projects. Text within the bars highlights the primary ways participant teams incorporated factors during the stages.
Fig. 2
Summary of the design stages during which participant teams incorporated contextual factors. The numbers on the right represent the number of contextual factors identified during each stage across 20 novice engineering design projects. Text within the bars highlights the primary ways participant teams incorporated factors during the stages.
Close modal

Participants conducted a variety of methods to collect, interpret, and apply contextual factors throughout their design processes, primarily during early design stages. Some teams went beyond traditional engineering methods, gathering contextual information online from social media (team IB6) and product reviews (team DB3), for example. Since the first stage of the capstone design project was intended to identify the scope of the teams’ design project, instructors in the course encouraged students to collect information from various sources by conducting secondary research, interviewing stakeholders, and observing their design's setting when possible. While gathering information, students were instructed to identify and prioritize relevant data and then synthesize critical information into requirements. During interviews, participants reflected on the contextual factors they determined to be within or outside their project's scope. Some participants were sure of which factors were in or out of their scope; for example, one participant claimed that environmental factors were “outside of the scope of what we were supposed to be designing” (team DB4), and another participant claimed that infrastructural factors “definitely influenced the design” (team IB5). On the other hand, sometimes participants were not so confident; for example, while a participant was reflecting on specific institutional factors, he claimed, “maybe it's important in some context, but maybe it wasn't important at all for where I was.” (team IB1).

Across the participating teams, we identified 99 requirements influenced by contextual factors, at least one from each team. However, many participants described receiving conflicting information from stakeholders about the context and experienced difficulty when developing specifications, mainly related to cost or performance requirements. A participant from team IB1 recalled hearing three very different estimates of the cost requirement from their stakeholders. Although his team chose to formulate a cost requirement that they thought was most reasonable for them to meet, he reflected that they made that decision ad-hoc, not necessarily backed by corroborating information.

Many teams incorporated contextual factors during their middle design stages, including concept generation and selection, to a lesser extent. During concept generation stages, some participants used contextual information or materials while creating early prototypes, such as referring to local anthropometric data (team IB1) and using bamboo “because that's pretty plentiful there” (team IB2). When participants received feedback from stakeholders on their prototypes and early concepts, they often learned of additional relevant contextual factors, for example, institutional procedures for use and maintenance. To accommodate these new contextual factors, participant teams removed concepts from consideration or changed design features. For example, participants narrowed down to “non-disposable solutions because [the institution's] procurement tends to be such a pain point” (team IB5) and changed an alarm feature from a noise signal to a visual signal based on feedback that “the context [is] loud, crowded … where there may be other [people] speaking” (team IR1).

During their verification and validation stages, participant teams verified performance in the use-context by conducting empirical tests (e.g., team IB6 performed experiments to ensure their design could withstand local UV radiation rates) or simulations (e.g., team DR2 created a simulation using CAD to assess the feasibility of their design within their intended context of use, which was a specific manufacturing plant). Some participant teams also collected stakeholder feedback at this stage as a proxy to physical or virtual testing (e.g., team IR1 verified their requirement of “locally available materials” by asking a stakeholder to review their final bill of materials).

4.2 Types of Contextual Factors Incorporated Into Design Processes.

Our analysis categorized half of the contextual factors incorporated into design processes as institutional or technological factors. Contextual factors within industrial, infrastructure, and public health categories were incorporated by most participant teams to a lesser extent. Contextual factors within economic, socio-cultural, and environmental were incorporated the least, and only by some participant teams. We did not identify any incorporation of contextual factors from the political category in our dataset. The subsections below follow the order above, with the most incorporated contextual factors discussed first. Primary and secondary categorizations are presented by frequency in Fig. 3.

Fig. 3
Summary of the primary (nine bolded categories) and secondary categories of contextual factors incorporated across 20 novice engineering design projects
Fig. 3
Summary of the primary (nine bolded categories) and secondary categories of contextual factors incorporated across 20 novice engineering design projects
Close modal

4.2.1 Factors Incorporated by All Participant Teams: Institutional and Technological.

Institutional. Institutional contextual factors, which refer to constraints or norms within the organization or institution of which the artifact must be operational, were the most frequently incorporated by the participant teams (all 20 teams), likely because every participant team met with sponsoring organizations, and their concerns were explicitly raised. For example, lab equipment must function within “the actual, physical space” (team DB4) of intended use, and medical devices “should fit in hospital corridors, hallways, rooms, doorways, and elevators” (team IR2). All the interviewed participant teams indicated that they were specifically instructed to pay attention to institutional needs and requirements, and all the final reports included citations for interviews with institutional stakeholders. Moreover, 46 of the identified 99 context-specific requirements across the 20 teams fell into the institutional category. Everyone interviewed described the value of visiting their project's institutional context. For example, one participant claimed, “there are things that you just can't anticipate or realize without actually seeing it” (team IB6). Notably, our analysis identified 17 participant teams that incorporated existing practices and procedures in various ways across all design stages, e.g., participants made design decisions based on training practices, cleaning procedures, procurement processes, and noise levels in the physical space. Over half of the participant teams incorporated factors based on staff availability, experiences, expertise, and credentials. Interviewed participants acknowledged the importance of “trying to fit it to what best fit them” (team IB5), i.e., designing solutions that adhered to the institution's current space, practices, and resources.

Technological. All 20 participant teams incorporated at least one technological contextual factor, which refers to the context-specific design requirements that drive the performance of the artifact for adequate operability and functionality within its intended use-context. They appeared to have done this because of the required benchmarking process and technical focus of the design course. In our analysis, technological factors did not include all technically driven design decisions; instead, the category emphasized technical considerations specific to the implementation setting. During their required benchmarking analysis amid problem scoping and/or requirements development, most participant teams investigated existing technologies in their use-context. Some interviewed participants commented on how they developed specifications based on the performance of existing solutions in their specific design context. For example, a participant from team DB3 described their process:

We just started benchmarking [comparable solutions] and seeing their typical storage volume and reading the reviews [online] to see if that was enough for the customers [in that context]. So that was how we came up with that [specification]. (Team DB3)

Interviewed participant teams stressed the importance of designing solutions to be compatible within the technical context. They did so by setting requirements for interoperability, working with complementary technology during concept generation, and refining features to perform better with complementary technology. For example, during the second half of their project, team DB4 realized they needed to change their solution's dimensions “when they saw” the other interfacing technologies in the intended use-context; they then quickly made accommodating design changes.

4.2.2 Factors Incorporated by Most Participant Teams: Industrial, Infrastructure, and Public Health.

Industrial. Thirteen participant teams incorporated industrial contextual factors, which refer to technical enterprises required for the artifact's performance and operability within its intended use-context, such as those relating to supply chain and manufacturing. Participant teams working on projects for international contexts described being instructed to consider industrial factors, whereas some teams working on projects for domestic contexts “were actually told not to really think about that” (team DB3). As such, participants on international projects incorporated materials and manufacturing methods applicable to the use-context while developing requirements, generating concept solutions, selecting design features, and refining the design. For example, one requirement claimed that the “device use zero tools that cannot be locally procured within [the context]” (team IB4).

While most participant teams working on projects for international contexts incorporated factors relating to maintenance availability, only one domestic participant team did. Participants in these international teams described the importance of considering their solutions’ longevity and conveyed struggles with incorporating maintenance considerations into design choices. For example, one participant team developed requirements for durability due to lack of maintenance in the context (team IR4), and another selected features that would be “easy to maintain” (team IB2). Participants on these teams relied on conversations with local technicians as they navigated accommodating industrial considerations since many struggled with gathering information about local materials and manufacturing.

Infrastructural. Twelve participant teams incorporated infrastructural factors, which refer to the external factors for functionality and operability within the context's built environment, such as availability of water and electricity and quality of roads and transportation services. These factors primarily influenced requirements and refinement activities. Half of the participant teams working on projects for international contexts included requirements based on the availability of electricity or lack thereof. For example, team IR1's final report claimed, “Electricity is not always the most reliable in low-resource settings, so the [product] should be able to function without it” (team IR1). A few participant teams considered how their product would be transported in its intended context. For example, team DR4 changed dimensions during their refinement stage so their sponsor could fit the final product into a standard U.S. pick-up truck “without renting a larger truck” (team DR4). Many of the incorporated infrastructural factors were gathered while participants were investigating their end users’ needs. For example, participant teams incorporated the materials and design of end users’ homes into concept selection and verification (team DB3) and developed a product that could easily traverse different types of roads and pathways (team IB2).

Public Health. Twelve participant teams incorporated at least one public health factor, which refers to the population's health status and location-specific conditions, health priorities, and concerns that describe the systematic determinants of populations’ health. Public health factors included the local prevalence of disease, anthropometric characteristics (such as average weights and heights), and mortality and morbidity rates, among other context-specific metrics. Expectedly, nearly all the participant teams working on international projects incorporated public health factors (since their projects were global health-themed); only two participant teams working on domestic projects incorporated public health factors. Country-specific body weight and size were researched by eight participant teams, and these data were incorporated into specifications and testing protocols. For some participant teams, when anthropometric data were unavailable in their country, they used proxy data, e.g., team IR2 used data from two countries in southern and eastern Africa for their device intended for use in western Africa. In contrast, team IB2 used anthropometric data from an Asian country for their device intended to be used in Africa.

4.2.3 Factors Incorporated by Only Some Participant Teams: Economic, Environmental, and Socio-cultural.

Economic. Ten participant teams reported incorporating economic factors, primarily in their cost requirements, which refer to context-specific economic capacity, structures, and individual and household attributes, including income level, purchasing power, and tax structures. While participants working on international projects seemed particularly aware and conscious that their product was intended for use in LMICs, they often made broad generalizations that lacked specificity. Five participant teams, all working on international projects, compared the economic situations between high-income countries and LMICs. For example, one final report claimed:

While [these medical devices] are the standard […] within high-income countries, these devices are costly and not easily accessible in low and middle-income countries. (Team IB5)

For these participant teams, there was also a strong emphasis on affordability for their end users, e.g., “the patients at [the hospital] and other low-resource areas need to be able to afford this device; otherwise, the end goal of the design project will be misguided” (team IR4). Notably, one participant team (team IB2) used market data from two other LMICs to estimate their product's final price point when data were unavailable in their context. Two participant teams (teams IB2 and IB6) researched and incorporated the cost of local labor by including their findings into their verification of requirements.

Environmental. Eight participant teams, primarily those with products that needed to function outdoors, reported incorporating environmental factors, which refer to the external conditions that impact the functionality and operability of the artifact within the location-specific natural environment, such as local humidity and temperature in the artifact's use-context. These participant teams incorporated these factors by selecting materials and features that function properly in their environment. For example, participant teams included requirements for durability in high-heat environments and user comfort such that the product “does not cause skin irritation in hot and humid weather” (team IR3). Many of these participant teams refined their solutions during later design stages due to environmental factors. For example, participant teams increased the amount of insulation so that the device could function in freezing conditions (team DR5), omitted bamboo as a potential material because “the [high] humidity would affect it” (team IB2), selected geometries that enabled structural integrity during high winds (team DR5), and tested durability against high ultraviolet rays (team IB6). One participant noted that they did not need to consider environmental factors when their device was intended to function primarily indoors, claiming, “it's probably pretty regulated [inside], I’m assuming. So I don't think that's really a problem” (team DB2).

Socio-cultural. In a varied manner, six participant teams incorporated socio-cultural factors, which refer to the context-specific social and cultural characteristics of stakeholders who interact with the artifact in its use-context. The specific types of factors in this category ranged widely across these teams, including esthetics (teams IB2, IB6, and DB3), education and literacy rates (teams IB2, IR4, and BD4), language (team IB5), stigmas and taboos (team IB2), symbols (team IB5), and religion and cultural tradition (team IB6). Across these participant teams, socio-cultural factors were incorporated during various design stages, for example, including formulating requirements for the use of written instructions and refining product features to accommodate context-specific trends, color preferences, and symbols. Although there was a wide variety of types and applications of socio-cultural factors into design processes, participants made claims that highlighted their awareness of the importance of these factors. For example, a participant who worked on an international project described

We wanted the [product] to blend in with society. So we were looking at fashion and colors and shapes. And we looked a lot at how does this compare to the United States. (Team IB6)

4.2.4 Factors Incorporated by No Teams: Political.

Political. No participant teams reported incorporating political factors into their designs, which refer to the political structures and organization in the use-context. Political factors could include government subsidies, incentives, and localized corruption. Although we specifically asked all interviewed participants about political factors, we could not identify any political factors within our dataset that were incorporated into participant teams’ design processes. Common participant responses included: “I don't think [a political factor] was ever considered” (team DB3) or “I don't know if we necessarily considered [political factors] a whole lot, but if we were doing it for the real deal it would be for sure” (team IB2), acknowledging that political factors matter, despite not being applied to their design process in the course. During interviews, participants showcased an awareness of political factors but noted that they were unsure if or how the factors related to their design project. Notably, compared to all the other contextual factor categories, there was a clear delineation that the political context was likely out of the project's scope. For example, one participant claimed, “We just made the assumption that if [political factors] had any relevance to our projects, we wouldn't have a lot of control over it. At least I would say that's probably the assumption that I made” (team IB6).

4.3 Participant Awareness, Skills, and Challenges.

Although participants demonstrated a strong awareness of the importance of context in engineering design, we identified variations in individual participants and team participant motivations and ability to incorporate contextual factors into their design processes.

4.3.1 Awareness of the Importance of Incorporating Contextual Factors.

Interviewed participants displayed a strong awareness of the importance of engaging with stakeholders to learn about their project's context and described being regularly encouraged to do so by their instructors. Meeting with knowledgeable stakeholders and observing the context were regularly cited as key sources of contextual information. A participant from team IB4 described the importance of learning about the context from stakeholders during the front-end stages of a design process:

[We didn’t want to] put our expectations onto their environment. And so we wanted to ask them what is a problem, or what is a challenge, and not just assume. […] It was something that we worked through early and tried to make sure that we were getting [our stakeholders’] input in the local environment as much as possible. (Team IB4)

In addition to stakeholder engagement, participants in our study emphasized the importance of observing the use-context. For example, a participant from team IB5 shared

You can read about as much of the culture and the context, but I feel like being able to see it and experience it really makes a big difference on how you perceive these problems. (Team IB5)

Although many participants could visit project-related implementation sites, others could not due to travel or schedule constraints. For example, a participant from team DB2 could not join her team members to observe their use-context (a surgical room in a US-based hospital), sharing that she relied on the knowledge of her team members and wished she could have gathered observational data herself. Another participant from team DB1 also shared his frustration with not being able to visit the context or engage with some key stakeholders:

I think that context is very, very important, knowing where it’s going to be, knowing who it’s going to be with, and then getting their feedback on it as well. […] I would have liked to have personally talked to more [stakeholders]. That would have been nice to be able to survey them, show them the ideas, and then get feedback on it. I did the same thing with my [past projects…] I mean, you can only do so much behind a desk at a computer. […] I think [we had] preconceived notions … I really wish that we did have the opportunity to go and see the [context]. (Team DB1)

Additionally, participant teams that worked on projects intended to be implemented directly after the design course were strongly motivated to incorporate a broader range of contextual factors compared to participant teams that worked on projects that aimed to develop only a prototype or initial concept. For example, team DB1 was told that they should not worry about implementation but should focus on creating a functional prototype that would be further developed by others after the course; thus, the team claimed that they did not need to consider some contextual factors, such as those in the industrial category. Furthermore, some participants perceived implementation stages to be outside the scope of their design process, for example, team IB3 claimed that their team did not need to consider certain political factors during their design process:

Level of government involvement just goes into implementation. So for example, FDA approval is something you have to think about, or getting the approval from … But that’s all related to implementation, not design of the device. (Team IB3)

Overall, our interviewed participants showcased an awareness of the importance of incorporating contextual factors. During the interviews, many participants realized and described the potential impact some contextual factors could have on their designs, even though they had never considered them during the course. For example, a participant from team DB2 reflected:

I wish maybe we would’ve gotten more exposure to [contextual factors] in the beginning, so that we could think about all these different aspects […] I think it’s important to think about all of [the contextual factors], even if they might not all be relevant. But, I mean I wouldn’t have thought that industrial [factors] would be relevant to us, but it 100% is. So like, at least being introduced to these and saying, oh good you can rule this one out but knowing that [a contextual factor that exists]. (Team DB2)

4.3.2 Difficulties Prioritizing Contextual Information.

A few interviewed participants felt overwhelmed with the amount of contextual information they needed to understand and apply to their specific design project. For example, a participant from team IB4 described their experience gathering large amounts of contextual information while conducting observations during their trip abroad, stating:

We started just literally taking information like a firehose and writing as much as we could down onto paper. (Team IB4)

Another participant from team IB1 described his frustration with taking copious notes while observing his project's context, unsure which information was important, claiming

Sometimes [I’m] focusing on things that don’t really matter … like why was I taking notes on the color of the walls? (Team IB1)

Although participants identified numerous contextual factors, many had difficulty prioritizing among them. For example, two participants from team IB2 described their challenge in selecting a material that could meet requirements driven by industrial, economic, and infrastructural factors (e.g., affordable and available material that could traverse the potholed terrain). In the end, participants from team IB2 claimed they could not find a material that met all their needs and resorted to selecting a material available in the United States, thus prioritizing the infrastructural factor over the industrial and economic factors. However, they reflected that they were not sure if it would be available, affordable, or practical to manufacture in their intended use-context.

Furthermore, when dealing with multiple contextual factors, some participants demonstrated awareness of constraints they faced in incorporating them and sometimes turned to mentor figures to resolve issues. They reflected on the limitations in their knowledge, time available during the course, or lack of guidance from instructors or sponsors for incorporating all relevant factors into their projects. Many participants recalled relying on their project sponsor or other stakeholders to prioritize information and make final decisions relating to contextual factors, especially when there were competing requirements. For example, a participant from team DB3 described needing to ignore some contextual factors:

We tried to start considering socio-economic status and things like that, and design for environment, but it got kind of jumbled and a little confusing and we didn’t really know how to exactly apply that in the scope of this class. So after talking to our professor and sponsor again, it was clear that they were like, “You know what? Focus on the main three things and don’t try to add too much in there when you’re considering this. (Team DB3)

4.3.3 Identifying Contextual Factors Via Prototypes During Later Design Stages.

Prototypes played a substantial role in helping participant teams identify additional relevant contextual factors during later design stages; participant teams could incorporate this new information into concept selection criteria and iterations during refinement. For example, team DB2 changed its solution's material finish after stakeholders saw the prototype and noted that the bright lights in the use-context would cause too much glare. Team IR5 added a hinged door after their sponsor provided feedback that the type of maintenance available at the institution was incompatible with their current design. Also, a few participant teams described learning additional contextual information when they visited the use-context with their prototypes. For example, even though team DB4 had visited the context early-on, when they introduced their prototype into the use-context, they discovered additional considerations, claiming,

It’s a specific thing to [the context] … there’s a certain level of deck height to it…we learned that after we designed and built this thing … So when we went [to the context and] they showed us … we designed it around that. (Team DB4)

4.3.4 International Versus Domestic Projects: Differences in Experiences.

Overall, participant teams working on international projects incorporated almost twice as many contextual factors on average (17 contextual factors per team) compared to teams working on domestic projects (nine contextual factors per team). Participant teams working on international projects appeared to be more aware of their unfamiliarity with the context and therefore paid more attention to it. Many participants on these teams demonstrated a strong willingness to learn about unfamiliar contexts. Importantly, participants often emphasized that working in LMIC contexts required additional considerations because “the problems are pretty different” (team IB3), regularly using the term “low-resource setting” to describe what they meant by differences in scope and process compared to domestic projects. For example, two participants from team IB2 reflected on feeling like they were gaining additional communication, research, and problem definition skills than participants on domestic projects, insisting that they needed to check their assumptions about the community and partner expectations more often. They claimed,

I think we almost had to lean a bit more on the whole communication with community partners and doing outside research than the [domestic] projects […] because I guess with a company they define the problem and then with our project it’s a bit more like we’re continuously trying to define the problem. (Team IB2)

Moreover, participants working on international projects appeared to come away from their experiences more aware of the potential impact of context on their designs; these participants regularly reflected on their context's impact on design outcomes. For example, a participant from team IB1 alleged that a different context would likely change their design or process, claiming,

I think contextually, for ease of use or adoption, you would either have to frame it differently or it would have to be different. (Team IB1)

On the other hand, only a few participants from domestic projects suggested that some features of their solutions would change if their design brief were based on a different context. It is worth noting that these participants expressed much more uncertainty about the influence of different contexts on their design process. A participant from team DB4, who was designing a device for a university lab, mentioned,

Maybe the design would have changed if [the lab] had different set-ups or in a different lab where they did the procedure differently, but that’s probably a little bit far-reaching. (Team DB4)

4.3.5 Incorporating Quantitative Versus Qualitative Contextual Factors.

Many participant teams experienced difficulty incorporating qualitative contextual factors and more consistently incorporated contextual factors that were easily quantifiable, e.g., local temperature and humidity data (environmental), country-specific anthropometric data (public health), technical specifications of technologies available in the context (technological), cost requirements based on individual data (economic) and institutional financial capacity (institutional), and physical dimensions provided by the sponsoring institution (institutional). Participants described feeling pressured to quantify contextual data as much as possible. For example, a participant from team IB2 recalled their team's experience attempting to quantify a contextual factor regarding a high prevalence of potholes in their intended context, claiming,

I know we went through a whole process of trying to find a pothole depth data … So like when I was there I noticed there’s a lot of potholes there that aren’t really filled in a timely manner or possibly at all … So we were trying to find a way to quantify that to fit in our requirements and specifications, and I think it was hard to find data … I’m not sure if there’s a lot of people specifically measuring potholes in different places of the country. We ended up finding an article that gave us pothole sizes from [a different country in sub-Saharan Africa] and so we were trying to use that as a guideline to say in a lower-resource country this might be the sized pothole you might be dealing with. (Team IB2)

This participant team also described their unsuccessful attempt to include a requirement for their solution to be repairable in the local community, claiming,

That was tough … nobody really has a numerical way to define “local’—I’m actually not sure what we ended up doing with that … it’s very difficult to validate. (Team IB2)

In another example, a participant from team IB6 described their team's struggle to verify if they were meeting their requirement to have an esthetically appealing design, and she described,

I think, it’s just trying to quantify something that’s inherently qualitative is just very challenging … But the ability to tell whether something’s physically attractive or visually appealing sort of thing just seems nearly impossible … [We] heard of Likert scale when it came to that sort of thing, and then [our professor] recommended discrete choice [analysis] … but there should be more ways to gauge whether this is successful or not. (Team IB6)

Overall, many participant teams ignored qualitative contextual factors because they did not have the tools to incorporate them into their design processes. For example, a participant from team IB4 claimed he hoped to consider qualitative cultural factors “on the side” but admitted he was unable to do so, claiming,

Cultural factors or cultural acceptance was an early requirement. We’re like, well, it’s not exactly something in the final thing, but maybe we have this additional thing on the side to address some of these cultural factors. But that didn’t make it too far. (Team IB4)

5 Discussion

5.1 Types of Contextual Factors Incorporated by Novice Engineering Designers.

Our results reveal that novice engineering designers incorporated relatively more performance-related contextual factors, i.e., factors related to the product operation, such as technological and institutional contexts, than socio-economic factors. Moreover, novice engineering designers incorporated quantifiable factors more consistently than qualitative factors, likely because these factors were easily measurable, and the way these factors could be incorporated into their design process was more straightforward. However, our results suggested that participants in our study struggled with synthesizing and applying relevant qualitative contextual factors but recognized that these cannot be ignored completely. Our participants incorporated only some socio-cultural and no political factors, likely due to the qualitative nature of socio-political considerations and their perception of the subjective nature of such factors.

Our findings aligned with prior work that suggests undergraduate engineers in their final year may be more likely to consider relevant technical factors during problem scoping than broader factors [57], but we additionally found that they also heavily incorporated institutional contextual factors. Our findings also highlighted that novice engineering designers incorporated contextual factors not just during problem scoping but across all primary design stages. Arguably, some broader contextual factors are less relevant to design processes, and novice engineering designers may be ignoring these factors to focus on the factors that are more relevant to them. Although our participants displayed awareness and desire to incorporate broader contextual factors, they often lacked the knowledge for how to do so, and they were unsure when these data should be incorporated during their design processes. Participants relied on their instructors and sponsors for advice for incorporating broader information, particularly qualitative factors. However, across our sample, participants received a wide range of feedback and advice. Based on prior findings in the literature, we speculate that their prioritization of technical factors is due to engineering's focus on the technical aspects of problems [75] and lack of tools for contextual analysis [60].

Not every participant team considered infrastructure, industrial, economic, public health, and environmental contextual factors; however, participants displayed patterns of incorporation within each of these factor categories. For example, eight participant teams used quantifiable local health demographics, such as average body sizes, to define specifications, while seven participant teams incorporated the type or availability of electricity in their requirements. Six participant teams included cost requirements based on economic contextual factors, and six participant teams made material choices based on environmental factors (e.g., humidity and temperature). It might be that novice engineering designers can quickly latch on to these more observable and quantifiable contextual factors.

We did not identify any incorporation of political factors, which is likely a reflection of the lack of political emphasis within the engineering field overall—a phenomena that Cech calls the “culture of disengagement” [75] and the “ideology of depoliticization” [76]. These beliefs postulate that engineering work should be “ahistorical and apolitical” [77], with the assumption that design work is “carried out objectively and without bias” [76]. Although engineering scholars increasingly highlight the implicit and explicit political implications of engineering design and technology implementation [49,78,79], the literature suggests that engineering students in the United States perceive politics to be positioned at the periphery of engineering practice [80]. Studies have identified a decrease in students’ interest of broader socio-political considerations over the course of their engineering education [75], which later can decrease their likelihood of engagement in community service during their careers [81].

Overall, participants demonstrated the inclination and ability to obtain broader socio-cultural information during their design processes. However, in addition to experiencing challenges applying this information to their projects, the course structure and methods taught may not have fully supported them in such efforts; some students even used traditionally nonconventional data collection methods (e.g., social media surveys and online product reviews). However, when participants faced a barrier in synthesizing and applying the contextual factor (e.g., in the case of qualitative, more complex contextual factors), some chose not to incorporate the information into their design processes; behaviors that are consistent with prior findings regarding the “culture of disengagement” in engineering education.

5.2 Patterns of Incorporating Contextual Factors in Novice Engineering Design Practice.

Overall, novice engineering designers incorporated various contextual factors across all design stages. We discovered some patterns that led to incorporating more and broader contextual factors, including various motivations, methods, and mindsets.

5.2.1 Motivations.

Participants working on projects in unfamiliar contexts and with imminent implementation opportunities following the completion of the course appeared to be more motivated to incorporate relevant contextual factors into their designs. First, participant teams working on international projects expressed an immediate appreciation for the unfamiliarity of their contexts, were more motivated to learn about them, and incorporated more contextual factors than participant teams working on domestic projects. It may be that “familiarity breeds contempt” and that the exoticness of a foreign site increases the attention paid to context. Our findings suggest that international projects, compared to domestic ones, have greater pedagogical value in ensuring that novice engineering designers have experience attending to a broad range of contextual factors.

Second, we also found that participant teams paid more attention to context when their projects were slated for imminent implementation, compared to participant teams tasked with only an initial prototype. This finding suggests that novice engineering designers understand what it means to incorporate context better than they may explicitly demonstrate in “toy” learning tasks. The pressure of real-world implementation can encourage context to be taken more seriously. Overall, novice engineering designers appeared to attend more to the context in design projects embedded in real-world projects or opportunities for real-world impact.

More research is needed as to ascertain whether such appreciation for context transfers to design in a more familiar or hypothetical setting. If the transfer does indeed occur, projects in unfamiliar sites or with the expectation of real-world impact would be recommended more generally as a way to sensitize novice engineering designers to the importance of context.

5.2.2 Methods.

Our research identified several methods that supported novice engineering designers in identifying and incorporating contextual factors into their designs. These findings occur at a more granular level than previous work:

  1. incorporating contextual factors into requirements and specifications,

  2. observing the context throughout their process,

  3. engaging with stakeholders to collect and synthesize factors,

  4. using crowd-sourced online information, and

  5. using prototypes to identify additional contextual information during later design stages.

Although instructors recommended contextual investigation, formal processes for performing the contextual analysis and incorporating contextual information into capstone design processes have not been developed [26]. Based on our findings, requirements development poses an excellent opportunity to include a formal contextual analysis. For example, in their case study to design diagnostic tests in east Africa, Bengtson et al. [82] recommended that a contextual analysis be incorporated into developing contextual requirements through a target product profile. Furthermore, encouraging novice engineering designers to document and use qualitative information or broaden the types of information that they include in requirements may enable additional contextual information to be included. Some participants in our study creatively incorporated more qualitative and less directly measurable requirements, for example, verifying requirements via interviews with key stakeholders (e.g., verifying their list of materials was available in their use-context) rather than via quantifiable experiments. Indeed, overall guidance for incorporating qualitative contextual factors is minimal [83] and does not lend itself to application within single-semester capstone design courses due to course structure and time constraints. The expressed uncertainty for how to use qualitative information and variation across the participant teams we studied suggests that many novice engineering designers may be missing some critical contextual factors.

Our results indicate that observing the use-context led to greater incorporation of contextual factors; importantly, novice engineering designers recognized the value of observations during design. Instructors in the class encouraged students to visit their design context when possible, consistent with design literature recommendations toward direct observation [40,84]. Interviewed participant teams expressed a variety of benefits from observing the context, including having ad-hoc and informal conversations with individuals. However, it is important to note that many participants claimed to have trouble collecting observational data because they were sometimes unsure what they should be looking for and recording; these findings are not unexpected since qualitative research methods are not commonly taught within the engineering curriculum and existing observation methods and data collection frameworks [8587] are not typically used during capstone design courses. Novice engineering designers may benefit from additional guidance for conducting observations and synthesizing and applying observational data to engineering design processes.

Our findings align with prior work demonstrating that stakeholder interviews expand a designer’s understanding of critical contextual factors [88]. At the university where this study was conducted, instructors emphasized the importance of stakeholder engagement during design processes, an information-gathering practice identified as a distinguishing characteristic of highly ranked engineering programs [89]. Throughout their design processes, instructors encouraged students to meet and interview stakeholders from the project’s sponsoring institution, which likely contributed to the incorporation of institutional contextual factors by all participant teams to some extent. Emphasis on engagement with institutional stakeholders may have also contributed to the disproportionate incorporation of contextual factors into requirements from the institutional category (46 of the identified 99 context-specific requirements) in addition to course structure and time constraints (i.e., these stakeholders were likely readily accessible). Indeed, novice engineering designers can collect more relevant contextual information if they expand the scope of stakeholders in their information-gathering stages. For example, participants from IB2 interviewed a practitioner knowledgeable about the supply chain in their use-context, which informed their material choices. These findings align with prior research that suggests that novice engineering designers gain valuable insights from meeting with experts and stakeholders during design projects, particularly when they have identified prespecified questions and goals for the engagement [68]. However, our participants expressed discomfort when stakeholders provided conflicting perspectives, aligning with literature describing how novice engineering designers often ignore conflicting information [90]. Our findings build on prior work, adding that while novice engineering designers were aware of the value of divergent information, they felt they lacked the ability to reconcile the conflicting perspectives.

We also found that in addition to reviewing academic articles and patents, our participants used nontraditional secondary information sources such as crowd-sourced online resources (i.e., social media and online shopping reviews) to collect additional relevant contextual information. These participants were not explicitly instructed to use these information sources, thereby demonstrating creativity and initiative to collect the contextual information they required using methodologies that were not part of the formal curriculum. Using social media as a source of information has been recommended in the design of information [91] and disaster relief systems [92], and as an information source to improve products based on user preferences [93]. Thus, there may be an opportunity to promote the incorporation of more accessible contextual information sources within student design projects by providing novice engineering designers with tools for synthesizing information available on social media and other crowd-sourced platforms.

Notably, by showing prototypes to stakeholders and bringing prototypes into the intended use-context during later design stages, participants were likely able to identify additional explicit and implicit contextual factors. When prompted with prototypes, stakeholders often recalled other contextual information relevant to the design projects. Moreover, our participants identified additional contextual constraints when they introduced their prototypes into the context during verification stages. Prior work has identified that experienced design engineers “introduce the prototype to the stakeholder in the use environment” to ensure that the design is appropriate for users within their specific context [94]. As such, there is an opportunity to incorporate intentional strategies to identify additional relevant contextual factors during later design stages.

5.2.3 Mindsets.

Participants in our study who demonstrated iterative and open mindsets when it came to their understanding, or lack thereof, of their design context appeared to be more responsive and willing to incorporate contextual factors.

Iteration is a key component of engineering design [95,96]; a designer willing to repeatedly reconsider their understanding of their design context could be said to have an “iterative mindset.” We found that participant teams varied in their iterative mindset with some frequently revisiting contextual information and others tending to follow a near-linear process. Participants’ iterative mindsets and encouragement for iteration from instructors may have led to more incorporation of contextual factors primarily through engagement with stakeholders, course instructors, and relevant experts or by visiting the context. Although most of the contextual factors we identified were applied to decisions during front-end design stages (when instructors emphasized secondary and primary research), some participants intentionally sought additional, often more specific and nuanced, contextual factors during middle and back-end stages, which we hypothesize is due to their willingness to exhibit an iterative mindset. Since design in practice is a very iterative process [97], there is an opportunity to iteratively incorporate contextual factors more intentionally as novice engineering designers progress through capstone design processes (i.e., during concept selection and refinement), aligning with recommendations from the literature to document and reflect on design iterations [98]. For example, throughout design stages, novice engineering designers could be prompted to intentionally engage with stakeholders with prototypes to elicit contextual insights [94,99101] or could engage in a more participatory approach throughout the course, which has been specifically recommended for projects that aim for social impact [102].

Many participants in our study displayed an open mind and humility as it pertained to their knowledge, or lack of knowledge, of their design context, resulting in strong desires to learn throughout their capstone experience. Specifically, participants working in unfamiliar contexts regularly described their goal to be open to questioning their assumptions about their use-context. To do so, many participants regularly engaged with stakeholders not just to collect information but to synthesize and prioritize it. These participants relied on interviews and discussions with experts and stakeholders to provide meaning and contextual perspective to their observations, aligning with prior findings in the literature [103,104]. However, our participants’ evaluation of contextual factors with stakeholders appeared to be ad-hoc and highly dependent on their individual interests and the judgment that stakeholders provided, rather than systematic approaches for identifying and prioritizing the relevance of contextual factors.

5.3 Limitations.

Participant teams in our study likely did not document or recall every instance of information incorporated into their designs. Also, as part of their course, participant teams either attended a lecture by a librarian about university resources and search strategies or complete an asynchronous learning block [105] on this topic and were required to meet with the librarian about their specific information needs prior to the first design review. These activities may have influenced their information collection strategies for obtaining contextual data, which we did not investigate. Furthermore, we used a fixed taxonomy to analyze the types of contextual factors participants considered. Although we did not identify any contextual factors outside of this taxonomy, there may have been additional factor types that were incorporated that we did not ask about and participants did not volunteer. We also did not attempt any quality assessment of the participant projects, so our analysis does not explicitly link with any markers of design quality.

6 Implications

Our findings suggest various ways that novice engineering designers can be encouraged and equipped to incorporate a broader set of contextual factors into their decisions throughout their design processes. First, participants working on projects in international contexts incorporated more contextual factors and felt compelled to do so, even outside the course’s requirements. Thus, including projects based in international (or less familiar) contexts may inherently encourage novice engineering designers to investigate and think critically about what influences their designs. However, formal support structures could assist students to more formally and consistently consider such factors when working on domestic projects or projects with assumed familiarity of context. Next, there is an opportunity to further support novice engineering designers in their intentional consideration of contextual factors during front-end stages. For example, novice engineering designers can be encouraged to investigate a broad range of contextual information via primary and secondary data collection during their problem scoping phases. Then, novice engineering designers could be provided with guidance for including requirements and specifications driven by relevant contextual factors, quantifying subjective information, and applying contextual information to design decisions throughout a design process (particularly when the contextual information cannot be captured as requirements and specifications). Front-end design stages are particularly opportune for investigating and incorporating contextual information into design processes; every participant team that we studied investigated contextual factors during problem scoping and incorporated at least one requirement informed by a contextual factor. However, after requirements were established, participants often received additional contextual information throughout later stages, particularly when engaging with stakeholders for feedback on their design progress. Thus, we recommend that intentional iterative participatory design methods be incorporated to encourage incorporating of these additional contextual factors.

Engaging with stakeholders is critical for incorporating relevant stakeholder and contextual information throughout design processes. Participants in our study incorporated many institutional factors, likely because they were required by course instructors to engage with sponsoring stakeholders. Based on our findings, we posit that participants incorporated fewer contextual factors from categories that were “further removed” from the technology and sponsoring institution when not explicitly required by instructors to engage with broader sets of stakeholders and/or when those contextual factors were more challenging to quantify. Our findings also highlight the various ways in which stakeholders helped novice engineering designers incorporate contextual information. Not only did the stakeholders in our study provide participant teams with contextual information but they also aided participants in synthesizing and prioritizing the information. Participants corroborated observational data and testing results, for example, with stakeholders to understand and prioritize needs.

The US Accreditation Board for Engineering and Technology (ABET) declares that engineering students must gain an ability to “make informed judgments, which must consider the impact of engineering solutions in global, economic, environmental, and societal contexts” [106]. As such, novice engineering designers are being prompted by instructors to consider global, economic, environmental, and societal contexts during their capstone courses. The participants in our study seemed to understand that contextual factors may affect their designs at any stage of their process. Nevertheless, for now, their timing for incorporating contextual information remains ad-hoc, and they would benefit from more support regarding what methods and approaches to use during specific stages of their design process to incorporate contextual factors. Moreover, our findings indicated that novice engineering designers know how to apply contextual information that is straightforward to quantify across various design stages. However, they struggle with including qualitative information, particularly as part of their requirements development and verification testing. Further training and guidance for incorporating qualitative information into requirements development and verification testing may improve the contextual suitability of novice engineering design outcomes.

7 Conclusion

Although incorporating contextual factors into design processes is an essential skill for engineering designers, studies have thus far not investigated novice engineering design practice with respect to the types of contextual factors considered or the design stages during which they are incorporated. Building on an existing contextual factor categorization [4], our study determined 31 secondary categories of contextual factors and characterized how novice engineering design participants incorporated them into their designs and/or design processes. Participants in our study frequently and consistently incorporated contextual factors from institutional and technological categories. However, participants infrequently and consistently incorporated contextual factors from infrastructure, industrial, economic, public health, and environmental categories, while infrequently and inconsistently incorporating factors from the socio-cultural category; no political factors were incorporated. Indeed, participants struggled to incorporate qualitative contextual factors. We suggest that to improve incorporating contextual factors during novice engineering design practice, students should visit their design contexts early and often, engage with a broad range of stakeholders throughout their design processes, and apply qualitative methods during requirements development and verification testing. Ultimately, these findings expand our understanding of context in design and can be leveraged by practicing and novice engineers.

Acknowledgment

The authors acknowledge the University of Michigan Design Science Program, Department of Mechanical Engineering, School of Information, and Rackham Graduate School for their support of this study. The authors would like to thank the students who participated in this study.

Funding Data

This material is based upon work supported by the National Science Foundation under Grant No. 2201981; Funder ID: 10.13039/501100001809. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the authors and do not necessarily reflect the views of the National Science Foundation. Additional funding for this study was provided by the University of Michigan Design Science Program, Department of Mechanical Engineering, School of Information, and Rackham Graduate School.

Conflict of Interest

There are no conflicts of interest.

Data Availability Statement

The datasets generated and supporting the findings of this article are obtainable from the corresponding author upon reasonable request.

Nomenclature

DB =

project based on domestic context; both final report and interview data

DR =

project based on domestic context; final report data only

IB =

project based on international context; both final report and interview data

IR =

project based on international context; final report data only

Appendix

Detailed summary of primary and secondary contextual factor codes, their incorporation in novice engineering design processes and exemplary quotations.

Table 2

Data summary

Data typeSponsor locationDesign projectIntended usersDesign courseGlobal health programCode
ReportInternationalSurgical deviceHospitalMech. Engr.YesIR1
ReportInternationalObstetric deviceHospitalMech. Engr.YesIR2
ReportInternationalRehabilitation deviceHospitalMech. Engr.YesIR3
ReportInternationalRehabilitation deviceHospitalMech. Engr.YesIR4
ReportInternationalTherapeutic deviceHospitalMech. Engr.YesIR5
ReportDomesticVehicle sub-systemUniversity extra-curricular groupMech. Engr.NoDR1
ReportDomesticManufacturing equipmentPrivate companyMech. Engr.NoDR2
ReportDomesticLab equipmentUniversity-based labMech. Engr.NoDR3
ReportDomesticTesting equipmentPrivate companyMech. Engr.NoDR4
ReportDomesticWaste management equipmentAdultsMech. Engr.NoDR5
Report + interviewInternationalObstetric deviceHospitalMech. Engr.YesIB1
Report + interviewInternationalRehabilitation deviceChildrenMech. Engr.YesIB2
Report + interviewInternationalObstetric deviceHospitalMech. Engr.YesIB3
Report + interviewInternationalRehabilitation deviceHospitalMech. Engr.YesIB4
Report + interviewInternationalTherapeutic deviceHospitalMech. Engr.YesIB5
Report + interviewInternationalSensory aidNon-governmental organizationMech. Engr.NoIB6
Report + interviewDomesticOperation equipmentHospitalMech. Engr.NoDB1
Report + interviewDomesticSurgical deviceHospitalBiomed. Engr.NoDB2
Report + interviewDomesticHome applianceAdultsMech. Engr.NoDB3
Report + interviewDomesticLab equipmentUniversity-based labMech. Engr.NoDB4
Data typeSponsor locationDesign projectIntended usersDesign courseGlobal health programCode
ReportInternationalSurgical deviceHospitalMech. Engr.YesIR1
ReportInternationalObstetric deviceHospitalMech. Engr.YesIR2
ReportInternationalRehabilitation deviceHospitalMech. Engr.YesIR3
ReportInternationalRehabilitation deviceHospitalMech. Engr.YesIR4
ReportInternationalTherapeutic deviceHospitalMech. Engr.YesIR5
ReportDomesticVehicle sub-systemUniversity extra-curricular groupMech. Engr.NoDR1
ReportDomesticManufacturing equipmentPrivate companyMech. Engr.NoDR2
ReportDomesticLab equipmentUniversity-based labMech. Engr.NoDR3
ReportDomesticTesting equipmentPrivate companyMech. Engr.NoDR4
ReportDomesticWaste management equipmentAdultsMech. Engr.NoDR5
Report + interviewInternationalObstetric deviceHospitalMech. Engr.YesIB1
Report + interviewInternationalRehabilitation deviceChildrenMech. Engr.YesIB2
Report + interviewInternationalObstetric deviceHospitalMech. Engr.YesIB3
Report + interviewInternationalRehabilitation deviceHospitalMech. Engr.YesIB4
Report + interviewInternationalTherapeutic deviceHospitalMech. Engr.YesIB5
Report + interviewInternationalSensory aidNon-governmental organizationMech. Engr.NoIB6
Report + interviewDomesticOperation equipmentHospitalMech. Engr.NoDB1
Report + interviewDomesticSurgical deviceHospitalBiomed. Engr.NoDB2
Report + interviewDomesticHome applianceAdultsMech. Engr.NoDB3
Report + interviewDomesticLab equipmentUniversity-based labMech. Engr.NoDB4
Table 3

Technological contextual factors

Contextual factor (# of teams)Incorporation in designExamples/excerpts
Available technologies in the context (n = 16)Problem scoping: Investigated technologies available in the context to identify gaps and opportunities for design (IB1, IB2, DB1, IB6, IB3, IB4, IB5, DB2, DB3, IR1, IR2, IR3, IR4, IR5, DR2, DR5)
Requirements development: Included requirements based on performance of available existing solutions (IB4, IB5, DB3, IR1)
“We were heavily instructed and really welcomed to meet up with research faculty at the library … and really take a deep dive into the existing patents that revolve around [this] technology … From that, we were able to just come up with a bunch of different ones that seemed similar or met certain similar [requirements] … I think that really gave us some good insight into some of the shortcomings into the existing technology.” (DB1)
“[This requirement] was just based on the [performance of technologies] that they currently have.” (IB5)
Compatibility with the technical context (n = 8)Problem scoping: Investigated the technological context that the device must be embedded in (DB1, DB2, DB4, IR2, DR1)
Requirements development: Requirements based on technologies the design must work with in context (DB1, IB5, DB2, DB4)
Concept generation: Worked with the complimenting technology during ideation (DB1)
Concept selection: Selected concepts/featured that worked with existing technology in the context (DB1, IB3, IB5, IR2, DR2)
Refinement: Refine features to perform better with complimenting technology (DB1, DB2, DB4, DR2)
Verification/validation: Tested compatibility with physical prototype (DB1) and digital prototype (DR2)
“This design is not compatible with the wide variety of beds in use at [the hospital].” (IB3)
“One major problem we had was that the [tube used with this technology] doesn’t fit in our handle … So we need to change that so things will actually fit inside.” (DB2)
Availability of consumables (n = 4)Problem scoping: Investigated available consumables (IB3)
Requirements development: Consumables must be available locally (DR5)
Concept selection: Selected concepts based on availability of consumables (IB5, IR1)
“The team decided to eliminate all concepts that would require disposable parts/fittings. The team still thinks this is the best approach for low resource settings, but the design is greatly complicated by this decision.” (IB5)
Context-specific standards (n = 3)Problem scoping: Investigated applicable standards available in context (DB3)
Requirements development: Incorporated requirement based on context-specific standard (IR2, DR1)
“We always knew we had to meet that [standard] … So it was definitely an impactful situation, an impactful standard on us the whole entire semester.” (DB3)
Contextual factor (# of teams)Incorporation in designExamples/excerpts
Available technologies in the context (n = 16)Problem scoping: Investigated technologies available in the context to identify gaps and opportunities for design (IB1, IB2, DB1, IB6, IB3, IB4, IB5, DB2, DB3, IR1, IR2, IR3, IR4, IR5, DR2, DR5)
Requirements development: Included requirements based on performance of available existing solutions (IB4, IB5, DB3, IR1)
“We were heavily instructed and really welcomed to meet up with research faculty at the library … and really take a deep dive into the existing patents that revolve around [this] technology … From that, we were able to just come up with a bunch of different ones that seemed similar or met certain similar [requirements] … I think that really gave us some good insight into some of the shortcomings into the existing technology.” (DB1)
“[This requirement] was just based on the [performance of technologies] that they currently have.” (IB5)
Compatibility with the technical context (n = 8)Problem scoping: Investigated the technological context that the device must be embedded in (DB1, DB2, DB4, IR2, DR1)
Requirements development: Requirements based on technologies the design must work with in context (DB1, IB5, DB2, DB4)
Concept generation: Worked with the complimenting technology during ideation (DB1)
Concept selection: Selected concepts/featured that worked with existing technology in the context (DB1, IB3, IB5, IR2, DR2)
Refinement: Refine features to perform better with complimenting technology (DB1, DB2, DB4, DR2)
Verification/validation: Tested compatibility with physical prototype (DB1) and digital prototype (DR2)
“This design is not compatible with the wide variety of beds in use at [the hospital].” (IB3)
“One major problem we had was that the [tube used with this technology] doesn’t fit in our handle … So we need to change that so things will actually fit inside.” (DB2)
Availability of consumables (n = 4)Problem scoping: Investigated available consumables (IB3)
Requirements development: Consumables must be available locally (DR5)
Concept selection: Selected concepts based on availability of consumables (IB5, IR1)
“The team decided to eliminate all concepts that would require disposable parts/fittings. The team still thinks this is the best approach for low resource settings, but the design is greatly complicated by this decision.” (IB5)
Context-specific standards (n = 3)Problem scoping: Investigated applicable standards available in context (DB3)
Requirements development: Incorporated requirement based on context-specific standard (IR2, DR1)
“We always knew we had to meet that [standard] … So it was definitely an impactful situation, an impactful standard on us the whole entire semester.” (DB3)
Table 4

Industrial contextual factors

Contextual factor (# of teams)Incorporation in designExamples/excerpts
Availability of manufacturing (n = 9)Problem scoping: Investigated available manufacturing (IB2)
Requirements development: Requirements that the design must be manufacturable in context (IB2, IB6, IB4, IR3)
Concept selection: Selected design features that were able to be manufactured with available resources (IB2, DR4)
Refinement: Modified component design or material selection for manufacturability in context (IR1, IR2, IR4, IR5)
“We literally doubled our objectives because as a team we were like, ‘How can we expect this to be successful without considering people who were going to be manufacturing it?’” (IB6)
“The level of skilled labor in [the context] is obviously a little different than here, so manufacturing [the components] that are exactly consistent from one to the other is important for that design, but since we knew that it would be local craftsmen working on it … there would be some unreliability of that manufacturing process.” (IB2)
“Specification: device uses zero tools that cannot be locally procured within [the context].” (IB4)
Materials (n = 9)Problem scoping: Investigated available materials (IB2, IB3, IR2)
Requirements development: Requirements that the design must include locally available materials (IB3, IB4, IR3, IR4)
Concept generation: Worked with available materials during ideation (IB2)
Concept selection: Selected concepts that used available materials (IB2, DB4, IR1, DR4)
Refinement: Design changes to accommodate available materials (IB2, IB4, DB4)
Verification/validation: Confirmed material lists with stakeholders in context (IR1, IR3)
“Suitable design materials, for example bamboo, was not within the realm of our realization until discussions with manufacturing professionals familiar with [the context's] resources.” (IB2)
“[The selected concept includes] commercially available heating elements.” (DR4)
“[Stakeholders in context] approved the design and the materials used.” (IR1)
Maintenance (n = 7)Problem scoping: Availability of local skilled labor and individual access to maintenance (IB2)
Requirements development: Requirement for available maintenance (IB2, IB5, IR4, IR5, DR5) and durability based on lack of maintenance (IR4)
Concept generation: Worked with easy-to-repair materials during ideation (IB4)
Concept selection: Selected a concept that was easy to maintain (IB2)
“[For] repairs, just thinking about what the average craftsman would have in his toolkit.” (IB2)
“Requirement: have system be easily repeatable and maintained; Specification: [consumables] available at national retailer.” (DR5)
“I think [availability of maintenance] helped eliminate some of the other [concepts]. I was really interested in doing [another concept], which I think could’ve been a cool idea, but if it gets to the point where it’s super complex, then if it breaks we wouldn’t necessarily have someone that would be able to easily fix it or find the parts to it.” (IB5)
Contextual factor (# of teams)Incorporation in designExamples/excerpts
Availability of manufacturing (n = 9)Problem scoping: Investigated available manufacturing (IB2)
Requirements development: Requirements that the design must be manufacturable in context (IB2, IB6, IB4, IR3)
Concept selection: Selected design features that were able to be manufactured with available resources (IB2, DR4)
Refinement: Modified component design or material selection for manufacturability in context (IR1, IR2, IR4, IR5)
“We literally doubled our objectives because as a team we were like, ‘How can we expect this to be successful without considering people who were going to be manufacturing it?’” (IB6)
“The level of skilled labor in [the context] is obviously a little different than here, so manufacturing [the components] that are exactly consistent from one to the other is important for that design, but since we knew that it would be local craftsmen working on it … there would be some unreliability of that manufacturing process.” (IB2)
“Specification: device uses zero tools that cannot be locally procured within [the context].” (IB4)
Materials (n = 9)Problem scoping: Investigated available materials (IB2, IB3, IR2)
Requirements development: Requirements that the design must include locally available materials (IB3, IB4, IR3, IR4)
Concept generation: Worked with available materials during ideation (IB2)
Concept selection: Selected concepts that used available materials (IB2, DB4, IR1, DR4)
Refinement: Design changes to accommodate available materials (IB2, IB4, DB4)
Verification/validation: Confirmed material lists with stakeholders in context (IR1, IR3)
“Suitable design materials, for example bamboo, was not within the realm of our realization until discussions with manufacturing professionals familiar with [the context's] resources.” (IB2)
“[The selected concept includes] commercially available heating elements.” (DR4)
“[Stakeholders in context] approved the design and the materials used.” (IR1)
Maintenance (n = 7)Problem scoping: Availability of local skilled labor and individual access to maintenance (IB2)
Requirements development: Requirement for available maintenance (IB2, IB5, IR4, IR5, DR5) and durability based on lack of maintenance (IR4)
Concept generation: Worked with easy-to-repair materials during ideation (IB4)
Concept selection: Selected a concept that was easy to maintain (IB2)
“[For] repairs, just thinking about what the average craftsman would have in his toolkit.” (IB2)
“Requirement: have system be easily repeatable and maintained; Specification: [consumables] available at national retailer.” (DR5)
“I think [availability of maintenance] helped eliminate some of the other [concepts]. I was really interested in doing [another concept], which I think could’ve been a cool idea, but if it gets to the point where it’s super complex, then if it breaks we wouldn’t necessarily have someone that would be able to easily fix it or find the parts to it.” (IB5)
Table 5

Infrastructural contextual factors

Contextual factor (# of teams)Incorporation in designExamples/excerpts
Utilities (n = 7)Problem scoping: Investigate the availability of electricity (IB1, IB3)
Requirements development: Included requirement based on electricity availability and/or type of power source (IB1, IB3, IB5, DB4, IR1, IR5)
Refinement: Selected sub-components that complied with the local power source (DB1)
“We didn’t want to have to rely on utilities because utilities are an added expense and they aren’t always reliable.” (IB1)
Transportation (n = 2)Requirements development: Included requirement that the product can fit in common transportation (IB2, DR4)
Refinement: Dimensions adapted to fit into locally available transportation (DR4)
Verification/validation: Interviewed stakeholders from the context to confirm the size would fit on public transport (IB2)
“A commonly used form of transportation in [the context] is a shared taxi. The device must be able to fit between the [user's] knees and the seat in front of them.” (IB2)

“This requirement stems from the need to easily transport the [product to the company in a local pick-up truck] without renting a larger truck.” (DR4)
Road quality (n = 2)Problem scoping: Investigated the quality of roads (IB2, IR4)
Requirements development: Included a requirement related to traversing bumpy roads with potholes (IB2)
Concept selection: Removed concepts that would not traverse on dirt paths (IB2)
Verification/validation: Tested the product on the most bumpy road near the university to simulate the context (IB2)
“So when I was there I noticed there's a lot of potholes there…one of the things that [a stakeholder] really emphasized was stability and being able to walk on the different kinds of terrain” (IB2)
Distance (n = 1)Problem scoping: Investigated the amount of time required for users to get the product (IB6)
Requirements development: Included a requirement that the product must be transferred to the customer within 4 h (IB6)
“People are traveling to come to the center. It’s not just around the corner for most people … We added the requirement of getting it under 4 h which … is still within a working day.” (IB6)
Materials (n = 1)Verification/validation: Tested the product on the two most common flooring materials used in the context (DB3)“Another thing that honestly none of us thought about immediately, but it was made clear pretty early on…So we had to think about all our tests and all of that with carpet underneath [and hardwood].” (DB3)
Housing design (n = 1)Concept selection: Removed concepts from consideration that could not accommodate some common housing designs in this context (DB3)“We had to consider people who maybe lived in the attic and had a V-shaped roof, or lived in the basement of an apartment complex and had a tiled ceiling.” (DB3)
“We shot some ideas down due to thinking of the [context] … we thought about maybe they don’t have a rigid ceiling.” (DB3)
Contextual factor (# of teams)Incorporation in designExamples/excerpts
Utilities (n = 7)Problem scoping: Investigate the availability of electricity (IB1, IB3)
Requirements development: Included requirement based on electricity availability and/or type of power source (IB1, IB3, IB5, DB4, IR1, IR5)
Refinement: Selected sub-components that complied with the local power source (DB1)
“We didn’t want to have to rely on utilities because utilities are an added expense and they aren’t always reliable.” (IB1)
Transportation (n = 2)Requirements development: Included requirement that the product can fit in common transportation (IB2, DR4)
Refinement: Dimensions adapted to fit into locally available transportation (DR4)
Verification/validation: Interviewed stakeholders from the context to confirm the size would fit on public transport (IB2)
“A commonly used form of transportation in [the context] is a shared taxi. The device must be able to fit between the [user's] knees and the seat in front of them.” (IB2)

“This requirement stems from the need to easily transport the [product to the company in a local pick-up truck] without renting a larger truck.” (DR4)
Road quality (n = 2)Problem scoping: Investigated the quality of roads (IB2, IR4)
Requirements development: Included a requirement related to traversing bumpy roads with potholes (IB2)
Concept selection: Removed concepts that would not traverse on dirt paths (IB2)
Verification/validation: Tested the product on the most bumpy road near the university to simulate the context (IB2)
“So when I was there I noticed there's a lot of potholes there…one of the things that [a stakeholder] really emphasized was stability and being able to walk on the different kinds of terrain” (IB2)
Distance (n = 1)Problem scoping: Investigated the amount of time required for users to get the product (IB6)
Requirements development: Included a requirement that the product must be transferred to the customer within 4 h (IB6)
“People are traveling to come to the center. It’s not just around the corner for most people … We added the requirement of getting it under 4 h which … is still within a working day.” (IB6)
Materials (n = 1)Verification/validation: Tested the product on the two most common flooring materials used in the context (DB3)“Another thing that honestly none of us thought about immediately, but it was made clear pretty early on…So we had to think about all our tests and all of that with carpet underneath [and hardwood].” (DB3)
Housing design (n = 1)Concept selection: Removed concepts from consideration that could not accommodate some common housing designs in this context (DB3)“We had to consider people who maybe lived in the attic and had a V-shaped roof, or lived in the basement of an apartment complex and had a tiled ceiling.” (DB3)
“We shot some ideas down due to thinking of the [context] … we thought about maybe they don’t have a rigid ceiling.” (DB3)
Table 6

Environmental contextual factors

Contextual factor (# of teams)Incorporation in designExamples/excerpts
Temperature and humidity (n = 6)Requirements development: Included requirement for durability in high-heat environments (IB2, IB3); included requirement for user comfort with product in hot/humid environment (IR3)
Concept selection: Removed concepts built from materials that could not withstand by high humidity (IB2)
Refinement: Increased the amount of insulation so that the device could function in freezing conditions (DR5); selected materials to withstand high-heat/humidity (IB1, IB6); refined design based on assumption of a controlled (room temperature) environment (DB1)
“Yeah, so that goes into our user reqs and specs, like it being able to withstand the humidity and the temperature there.” (IB3)
Weather (n = 4)Problem scoping: Investigated materials that could withstand local climate (IR2)
Concept selection: Selected a concept with rust-free materials since the product will experience heavy rains (IB2)
Refinement: Selected geometries that enable structural integrity during high winds (DR5); selecting materials that do not degrade in sunlight (IB2)
Verification/validation: Tested durability against ultraviolet rays (IB6)
“A lot of people … they’re going to be in the direct sunlight. So that’s why we wanted to make sure that it was not going to discolor or disform from UV.” (IB6)
Contextual factor (# of teams)Incorporation in designExamples/excerpts
Temperature and humidity (n = 6)Requirements development: Included requirement for durability in high-heat environments (IB2, IB3); included requirement for user comfort with product in hot/humid environment (IR3)
Concept selection: Removed concepts built from materials that could not withstand by high humidity (IB2)
Refinement: Increased the amount of insulation so that the device could function in freezing conditions (DR5); selected materials to withstand high-heat/humidity (IB1, IB6); refined design based on assumption of a controlled (room temperature) environment (DB1)
“Yeah, so that goes into our user reqs and specs, like it being able to withstand the humidity and the temperature there.” (IB3)
Weather (n = 4)Problem scoping: Investigated materials that could withstand local climate (IR2)
Concept selection: Selected a concept with rust-free materials since the product will experience heavy rains (IB2)
Refinement: Selected geometries that enable structural integrity during high winds (DR5); selecting materials that do not degrade in sunlight (IB2)
Verification/validation: Tested durability against ultraviolet rays (IB6)
“A lot of people … they’re going to be in the direct sunlight. So that’s why we wanted to make sure that it was not going to discolor or disform from UV.” (IB6)
Table 7

Institutional contextual factors

Contextual factor (# of teams)Incorporation in designExamples/excerpts
Existing practices and procedures (n = 17)Problem scoping: Investigated the institution's existing solution (IB1, IB2, IB3, IB4, IR3, DR2, DB4), training procedures (IB1, IR1), cleaning procedures (IB1, DB1, DB2), organizational procedures (IB6, DB2)
Requirements development: Included requirements based on training and/or setup time (IB1, IB4), durability based on typical patient load (IB1), durable when cleaned and/or sterilizable (IB3, DB1, DB2, DB3, IB4, IR1, IR2, DR3), able to be transported within institution (IB5, DB4), based on performance or compatibility of existing procedure (IR4, DB4, DR4)
Concept generation: Considered sterilization requirements while ideating (DB1, DB2); used materials already used in the institution (DB4)
Concept selection: Selected concept based on cleanability/sterilizability (IB1, DB1, DB2), existing procedures (IB3, DB4), procurement process (IB5), noise levels in the environment (IR1)
Refinement: Adjusted features to disassemble for sterilization process (DB2, IR5), accommodate noise levels (DB1)
“The [solution] must also be compatible with existing systems for training.” (IB1)
“It’s not going to disintegrate if they use their cleaning chemicals on it.” (IB4)
“One of the requirements was that it should withstand the bleach solution … because that’s their method of sanitizing reusable items.” (IB3)
“Visual signals are more noticeable for users, especially in the context of a loud, crowded simulation center or hospital where there may be other students or instructors speaking.” (IR1)
Institutional resources (n = 11)Problem scoping: Investigated available equipment (IB1) and space (DB4)
Requirements development: Included size requirement based on space available (IB3, IB5, DB4, IR2, IR5, DR2, DR3, DR5); included requirement that does not require equipment that the institution does not use (IB5); included extra safety requirement because the institution lacked circulated air (IB6)
Concept selection: Removed concepts that would not work in the room selected by the institution (IB6)
Refinement: Added features to help keep the product clean without using additional resources not available in the hospital (IB3)
“We couldn’t design a frame that was the size of the room, not that we would have, but those [were the] sorts of restrictions, the actual, physical space of the lab we were going to be in.” (DB4)
Capacity/capability of institutional staff (n = 11)Problem scoping: Investigated the skill level of staff (IB1, IB3, DB2, IR1) and capacity/availability of staff (IB2, IB4)
Requirements development: Included “easy to use” requirements based on training levels (IB1, IB4); included requirement to limit number of staff required (IR4, IR5, DR2); included requirement that the product doesn't need service for 24 h (DR3)
Concept generation: Kept concept generation simple based so that the maintenance staff could easily repair when needed (IB4)
Refinement: Adjusted the design so that anyone could use it without needing to know how to use a computer (IB6)
Verification/validation: Conducted usability testing with non-experts to represent a range of skill levels (IB1)
“They also had a maintenance department … so we wanted to make sure that everything we did could be maintained and fixed by people there.” (IB4)
“But still that takes into the assumption that the technician knows how to operate a computer, let alone a modeling system. Which, to our knowledge and our research would not be the case. And so that’s why we made this change.” (IB6)
Institutional financial capacity (n = 10)Problem scoping: Investigated institution's cost limits (IB1, IR1)
Requirements development: Included requirement for the cost of the product based on the institution's budget (IB1, IB5, IB6, IR1, IR5, DR1, DR2, DR3)
Concept selection: Selected concepts with more/less expensive materials based on budget available (DB2, DB4, IR5, DR4)
“That’d be great if we could use that [material] but it’s thousands of dollars, we don’t have that money [from the institution].” (DB2)
“Requirement: Affordable for hospital administration staff to purchase a [the product].” (IR1)
Contextual factor (# of teams)Incorporation in designExamples/excerpts
Existing practices and procedures (n = 17)Problem scoping: Investigated the institution's existing solution (IB1, IB2, IB3, IB4, IR3, DR2, DB4), training procedures (IB1, IR1), cleaning procedures (IB1, DB1, DB2), organizational procedures (IB6, DB2)
Requirements development: Included requirements based on training and/or setup time (IB1, IB4), durability based on typical patient load (IB1), durable when cleaned and/or sterilizable (IB3, DB1, DB2, DB3, IB4, IR1, IR2, DR3), able to be transported within institution (IB5, DB4), based on performance or compatibility of existing procedure (IR4, DB4, DR4)
Concept generation: Considered sterilization requirements while ideating (DB1, DB2); used materials already used in the institution (DB4)
Concept selection: Selected concept based on cleanability/sterilizability (IB1, DB1, DB2), existing procedures (IB3, DB4), procurement process (IB5), noise levels in the environment (IR1)
Refinement: Adjusted features to disassemble for sterilization process (DB2, IR5), accommodate noise levels (DB1)
“The [solution] must also be compatible with existing systems for training.” (IB1)
“It’s not going to disintegrate if they use their cleaning chemicals on it.” (IB4)
“One of the requirements was that it should withstand the bleach solution … because that’s their method of sanitizing reusable items.” (IB3)
“Visual signals are more noticeable for users, especially in the context of a loud, crowded simulation center or hospital where there may be other students or instructors speaking.” (IR1)
Institutional resources (n = 11)Problem scoping: Investigated available equipment (IB1) and space (DB4)
Requirements development: Included size requirement based on space available (IB3, IB5, DB4, IR2, IR5, DR2, DR3, DR5); included requirement that does not require equipment that the institution does not use (IB5); included extra safety requirement because the institution lacked circulated air (IB6)
Concept selection: Removed concepts that would not work in the room selected by the institution (IB6)
Refinement: Added features to help keep the product clean without using additional resources not available in the hospital (IB3)
“We couldn’t design a frame that was the size of the room, not that we would have, but those [were the] sorts of restrictions, the actual, physical space of the lab we were going to be in.” (DB4)
Capacity/capability of institutional staff (n = 11)Problem scoping: Investigated the skill level of staff (IB1, IB3, DB2, IR1) and capacity/availability of staff (IB2, IB4)
Requirements development: Included “easy to use” requirements based on training levels (IB1, IB4); included requirement to limit number of staff required (IR4, IR5, DR2); included requirement that the product doesn't need service for 24 h (DR3)
Concept generation: Kept concept generation simple based so that the maintenance staff could easily repair when needed (IB4)
Refinement: Adjusted the design so that anyone could use it without needing to know how to use a computer (IB6)
Verification/validation: Conducted usability testing with non-experts to represent a range of skill levels (IB1)
“They also had a maintenance department … so we wanted to make sure that everything we did could be maintained and fixed by people there.” (IB4)
“But still that takes into the assumption that the technician knows how to operate a computer, let alone a modeling system. Which, to our knowledge and our research would not be the case. And so that’s why we made this change.” (IB6)
Institutional financial capacity (n = 10)Problem scoping: Investigated institution's cost limits (IB1, IR1)
Requirements development: Included requirement for the cost of the product based on the institution's budget (IB1, IB5, IB6, IR1, IR5, DR1, DR2, DR3)
Concept selection: Selected concepts with more/less expensive materials based on budget available (DB2, DB4, IR5, DR4)
“That’d be great if we could use that [material] but it’s thousands of dollars, we don’t have that money [from the institution].” (DB2)
“Requirement: Affordable for hospital administration staff to purchase a [the product].” (IR1)
Table 8

Public health contextual factors

Contextual factor (# of teams)Incorporation in designExamples/excerpts
Health demographics (n = 10)Problem scoping: Investigated context-specific health conditions and demographics, e.g., maternal mortality rates (IB1), child weights (IB2, IB5), rates of injury (IB4, DB3), prevalence of specific conditions (IR5)
Requirements development: Used health data to determine limits included in specifications (IB2, IB4, IR2)
Concept generation: Considered local body types/weights while developing concepts (IB1)
Refinement: Used health data to refine product dimensions (DR5, IB6); selected material color based on local skin tones (IR1)
Verification/validation: Assessed the use of the product based on the local health demographics (IB1, DB3); final product represented on models with similar skin tones (IB6)
“This specification was determined by [local] anthropometric data.” (IR2)
“We considered the 99 and 98 percentile of weights, and age range, and all of that [from the context of use].” (DB3)
Local health care (n = 7)Problem scoping: Investigated the local healthcare system broadly (IR3, IB5); investigated distance between facilities (IB2); investigated availability and quality of specific health services (IR1, IR4, IB1, IB5, IB6)
Requirements development: Included an efficacy requirement based on the lack of specific healthcare services needed if the device fails (IB1); included a requirement that the device be portable to transfer between the facilities (IR4)
“The treatment method must [be effective] … this is high-priority in [this country's] hospitals because obtaining [emergency care] is difficult.” (IB1)
Contextual factor (# of teams)Incorporation in designExamples/excerpts
Health demographics (n = 10)Problem scoping: Investigated context-specific health conditions and demographics, e.g., maternal mortality rates (IB1), child weights (IB2, IB5), rates of injury (IB4, DB3), prevalence of specific conditions (IR5)
Requirements development: Used health data to determine limits included in specifications (IB2, IB4, IR2)
Concept generation: Considered local body types/weights while developing concepts (IB1)
Refinement: Used health data to refine product dimensions (DR5, IB6); selected material color based on local skin tones (IR1)
Verification/validation: Assessed the use of the product based on the local health demographics (IB1, DB3); final product represented on models with similar skin tones (IB6)
“This specification was determined by [local] anthropometric data.” (IR2)
“We considered the 99 and 98 percentile of weights, and age range, and all of that [from the context of use].” (DB3)
Local health care (n = 7)Problem scoping: Investigated the local healthcare system broadly (IR3, IB5); investigated distance between facilities (IB2); investigated availability and quality of specific health services (IR1, IR4, IB1, IB5, IB6)
Requirements development: Included an efficacy requirement based on the lack of specific healthcare services needed if the device fails (IB1); included a requirement that the device be portable to transfer between the facilities (IR4)
“The treatment method must [be effective] … this is high-priority in [this country's] hospitals because obtaining [emergency care] is difficult.” (IB1)
Table 9

Economic contextual factors

Contextual factor (# of teams)Incorporation in designExamples/excerpts
Income level (n = 9)Problem scoping: Investigate “affordability” in the context (IB1, IB2, IB3, IB4, IB5, IB6)
Requirements development: Included requirement for the cost of the product based on the affordability by individual users (IB1, IB2, IB6, IB3, IR3, IR4, DR5)
Concept selection: Selected concepts that were reusable so that their end user could afford the product and not be required to purchase replacements (IB5)
“The patients at [the hospital] and other low-resource areas need to be able to afford this device, otherwise the end goal of the design project will be misguided.” (IR4)
Country-level classification (n = 4)Problem scoping: Used the high, middle, and low-income country classifications to compare statistics and information across country economic levels (IB1, IB2, IB5, IR1)
Requirements development: When country-specific data was unavailable, they used data from a country of similar economic classification to inform their requirements development (IB2)
“We were trying to figure out pricing and everything and so we had to use other techniques from seeing similar countries that have a similar economic system and GDP.” (IB2)
Labor market characteristics (n = 2)Verification/validation: Local labor costs included in final cost verification (IB2, IB6)“We considered minimum wage and what [manufacturers] make in relation to minimum wage. So yeah, [this cost] went into our calculations for sure.” (IB2)
“I remember we asked, ‘What did the technician make for pay?’ Things like that because we wanted to take that into labor costs.” (IB6)
Contextual factor (# of teams)Incorporation in designExamples/excerpts
Income level (n = 9)Problem scoping: Investigate “affordability” in the context (IB1, IB2, IB3, IB4, IB5, IB6)
Requirements development: Included requirement for the cost of the product based on the affordability by individual users (IB1, IB2, IB6, IB3, IR3, IR4, DR5)
Concept selection: Selected concepts that were reusable so that their end user could afford the product and not be required to purchase replacements (IB5)
“The patients at [the hospital] and other low-resource areas need to be able to afford this device, otherwise the end goal of the design project will be misguided.” (IR4)
Country-level classification (n = 4)Problem scoping: Used the high, middle, and low-income country classifications to compare statistics and information across country economic levels (IB1, IB2, IB5, IR1)
Requirements development: When country-specific data was unavailable, they used data from a country of similar economic classification to inform their requirements development (IB2)
“We were trying to figure out pricing and everything and so we had to use other techniques from seeing similar countries that have a similar economic system and GDP.” (IB2)
Labor market characteristics (n = 2)Verification/validation: Local labor costs included in final cost verification (IB2, IB6)“We considered minimum wage and what [manufacturers] make in relation to minimum wage. So yeah, [this cost] went into our calculations for sure.” (IB2)
“I remember we asked, ‘What did the technician make for pay?’ Things like that because we wanted to take that into labor costs.” (IB6)
Table 10

Socio-cultural contextual factors

Contextual factor (# of teams)Incorporation in designExamples/excerpts
Education and literacy rates (n = 4)Requirements development: Did not require written instructions or manual (IB2, IR4)
Refinement: Wrote manual for specific education level (DB4)
Verification/validation: Assessed education level of target users, so that their solution would be feasible (DR5)
“We wrote [assembly instructions] for the specific end user we had in mind … They’d probably have to be edited [to accommodate individuals with different education levels].” (DB4)
Esthetics (n = 3)Problem scoping: Read Amazon reviews to assess esthetics and size trends (DB3), conducted surveys in Facebook groups to learn about fashion trends (IB6)
Requirements development: Requirement that device include esthetics and colors common in the context (DB3, IB6)
Refinement: Selected material and color based on esthetic preferences (IB2, IB6)
“From [the Facebook survey] we were able to find out that a lot of people [from that context] had said that bright, vibrant colors are huge over there. Like if you walked around the street everyone was wearing bright colors. And we were like, ‘Okay. How can we find materials and filaments that have vibrant colors that would mimic that? Rather than [black material],’ So it was we were able to find a material that would potentially eliminate the need for finishing, which was important to blending in their society and culture walking around everyday.” (IB6)
Stigmas and taboos (n = 2)Problem scoping: Investigated context-specific stigmas experienced by their end users (IB2)
Concept selection: Selected product names that did not include taboo references (IB6)
Refinement: Avoided choosing colors that represented funerals and death (IB2)
“There's a lot of stigma around disabilities … so we had to keep that in mind … making it fit compact … [not] taking up a bunch of space that would enhance that stigma.” (IB2)
Language (n = 1)Refinement: Programing the device in the local language (IB5)“Everyone at least within the hospital setting is able to speak English, and most people outside of the hospital were able to speak English. We did want to be able to have the device programmable to other languages, that’s just something that we wanted to change eventually.” (IB5)
Symbols (n = 1)Refinement: Removed “stop sign” symbol (IB5)“On our device, we had a stop sign, which wouldn't necessarily be the same there.” (IB5)
Religion and cultural tradition (n = 1)Verification/validation: Since many users read bibles, included testing to improve reading experience (IB6)“We were able to talk with [our project sponsor] and realize that religion is a huge part of a lot of people’s lives in [this context] … they’re at home reading bibles … It definitely made us consider [what it was like to read looking down]. Because it’s, I think when we were looking down, trying to read, we were like, “Well this is annoying. And it’s also something that's really important to the people who are going to be using this [solution …] that was definitely something we considered.” (IB6)
Contextual factor (# of teams)Incorporation in designExamples/excerpts
Education and literacy rates (n = 4)Requirements development: Did not require written instructions or manual (IB2, IR4)
Refinement: Wrote manual for specific education level (DB4)
Verification/validation: Assessed education level of target users, so that their solution would be feasible (DR5)
“We wrote [assembly instructions] for the specific end user we had in mind … They’d probably have to be edited [to accommodate individuals with different education levels].” (DB4)
Esthetics (n = 3)Problem scoping: Read Amazon reviews to assess esthetics and size trends (DB3), conducted surveys in Facebook groups to learn about fashion trends (IB6)
Requirements development: Requirement that device include esthetics and colors common in the context (DB3, IB6)
Refinement: Selected material and color based on esthetic preferences (IB2, IB6)
“From [the Facebook survey] we were able to find out that a lot of people [from that context] had said that bright, vibrant colors are huge over there. Like if you walked around the street everyone was wearing bright colors. And we were like, ‘Okay. How can we find materials and filaments that have vibrant colors that would mimic that? Rather than [black material],’ So it was we were able to find a material that would potentially eliminate the need for finishing, which was important to blending in their society and culture walking around everyday.” (IB6)
Stigmas and taboos (n = 2)Problem scoping: Investigated context-specific stigmas experienced by their end users (IB2)
Concept selection: Selected product names that did not include taboo references (IB6)
Refinement: Avoided choosing colors that represented funerals and death (IB2)
“There's a lot of stigma around disabilities … so we had to keep that in mind … making it fit compact … [not] taking up a bunch of space that would enhance that stigma.” (IB2)
Language (n = 1)Refinement: Programing the device in the local language (IB5)“Everyone at least within the hospital setting is able to speak English, and most people outside of the hospital were able to speak English. We did want to be able to have the device programmable to other languages, that’s just something that we wanted to change eventually.” (IB5)
Symbols (n = 1)Refinement: Removed “stop sign” symbol (IB5)“On our device, we had a stop sign, which wouldn't necessarily be the same there.” (IB5)
Religion and cultural tradition (n = 1)Verification/validation: Since many users read bibles, included testing to improve reading experience (IB6)“We were able to talk with [our project sponsor] and realize that religion is a huge part of a lot of people’s lives in [this context] … they’re at home reading bibles … It definitely made us consider [what it was like to read looking down]. Because it’s, I think when we were looking down, trying to read, we were like, “Well this is annoying. And it’s also something that's really important to the people who are going to be using this [solution …] that was definitely something we considered.” (IB6)

References

1.
Dieter
,
G. E.
, and
Schmidt
,
L. C.
,
2009
,
Engineering Design
,
McGraw-Hill Higher Education
,
Boston, MA
.
2.
Dym
,
C. L.
,
Agogino
,
A. M.
,
Eris
,
O.
,
Frey
,
D. D.
, and
Leifer
,
L. J.
,
2005
, “
Engineering Design Thinking, Teaching, and Learning
,”
J. Eng. Educ.
,
94
(
1
), pp.
103
120
.
3.
Mabogunje
,
A.
,
Sonalkar
,
N.
, and
Leifer
,
L.
,
2016
, “
Design Thinking: A New Foundational Science for Engineering
,”
Int. J. Eng. Educ.
,
32
(
3
), pp.
1540
1556
.
4.
Aranda-Jan
,
C. B.
,
Jagtap
,
S.
, and
Moultrie
,
J.
,
2016
, “
Towards a Framework for Holistic Contextual Design for Low-Resource Settings
,”
Int. J. Des.
,
10
(
3
), p.
21
.
5.
Jagtap
,
S.
,
2019
, “
Design and Poverty: A Review of Contexts, Roles of Poor People, and Methods
,”
Res. Eng. Des.
,
30
(
1
), pp.
41
62
.
6.
Khadilkar
,
P.
,
Somasekhar
,
H. I.
, and
Mani
,
M.
,
2019
, “Technologies to Support the Technologies,”
Rural Technology Development and Delivery
,
S. K.
Saha
, and
M. R.
Ravi
, eds.,
Springer
,
Singapore
, pp.
213
221
.
7.
Wood
,
A. E.
, and
Mattson
,
C. A.
,
2016
, “
Design for the Developing World: Common Pitfalls and How to Avoid Them
,”
ASME J. Mech. Des.
,
138
(
3
), p.
031101
.
8.
Burleson
,
G.
, and
Sharp
,
K.
,
2018
, “
Comparative Study of Maintenance Planning and Failure Modes of Drinking Water Projects: Case Studies From Eastern Uganda
,”
2018 IEEE Global Humanitarian Technology Conference (GHTC)
,
San Jose, CA
,
Oct. 18–21
, IEEE, pp.
1
6
.
9.
Raessler
,
M.
,
2018
, “
The Arsenic Contamination of Drinking and Groundwaters in Bangladesh: Featuring Biogeochemical Aspects and Implications on Public Health
,”
Arch. Environ. Contam. Toxicol.
,
75
(
1
), pp.
1
7
.
10.
Ames
,
M. G.
,
2019
,
The Charisma Machine: The Life, Death, and Legacy of One Laptop per Child
,
MIT Press
,
Cambridge, MA
.
11.
Eteläpelto
,
A.
,
2000
, “
Contextual and Strategic Knowledge in the Acquisition of Design Expertise
,”
Learn. Instr.
,
10
(
2
), pp.
113
136
.
12.
Mazzurco
,
A.
, and
Daniel
,
S.
,
2020
, “
Socio-Technical Thinking of Students and Practitioners in the Context of Humanitarian Engineering
,”
J. Eng. Educ.
,
109
(
2
), pp.
243
261
.
13.
Dugan
,
K. E.
,
Mosyjowski
,
E. A.
,
Daly
,
S. R.
, and
Lattuca
,
L. R.
,
2021
, “
Systems Thinking Assessments in Engineering: A Systematic Literature Review
,”
Syst. Res. Behav. Sci.
,
39
(
4
), pp.
840
866
.
14.
Mosyjowski
,
E. A.
,
von Bischhoffshausen
,
J. E.
,
Lattuca
,
L. R.
, and
Daly
,
S. R.
,
2020
, “
Student and Practitioner Approaches to Systems Thinking: Integrating Technical and Contextual Considerations
,”
Proceedings of the 2020 American Society of Engineering Education Annual Conference & Exposition
,
Virtual
,
June 22–26
.
15.
Johnson
,
K.
,
Leydens
,
J.
,
Erickson
,
J.
,
Boll
,
A.
,
Claussen
,
S.
, and
Moskal
,
B.
,
2019
, “
Sociotechnical Habits of Mind: Initial Survey Results and Their Formative Impact on Sociotechnical Teaching and Learning
,”
2019 ASEE Annual Conference & Exposition Proceedings, ASEE Conferences
,
Tampa, FL
,
June 16–19
, p.
33275
.
16.
Leydens
,
J. A.
, and
Lucena
,
J. C.
,
2017
,
Engineering Justice: Transforming Engineering Education and Practice
,
John Wiley & Sons
,
Hoboken, NJ
.
17.
Sabet Sarvestani
,
A.
, and
Sienko
,
K. H.
,
2018
, “
Medical Device Landscape for Communicable and Noncommunicable Diseases in Low-Income Countries
,”
Glob. Health
,
14
(
1
), p.
65
.
18.
Sabet Sarvestani
,
A.
,
Coulentianos
,
M.
, and
Sienko
,
K. H.
,
2021
, “
Defining and Characterizing Task-Shifting Medical Devices
,”
Glob. Health
,
17
(
1
), p.
60
.
19.
Yannou
,
B.
,
Jankovic
,
M.
,
Leroy
,
Y.
, and
Okudan Kremer
,
G. E.
,
2013
, “
Observations From Radical Innovation Projects Considering the Company Context
,”
ASME J. Mech. Des.
,
135
(
2
), p.
021005
.
20.
Pakravan
,
M. H.
, and
MacCarty
,
N. A.
,
2020
, “
Design for Clean Technology Adoption: Integration of Usage Context, User Behavior, and Technology Performance in Design
,”
ASME J. Mech. Des.
,
142
(
9
), p.
091402
.
21.
Mabey
,
C. S.
,
Mattson
,
C. A.
, and
Dahlin
,
E. C.
,
2021
, “
Assessing Global Needs When Identifying Potential Engineering for Global Development Projects
,”
ASME J. Mech. Des.
,
144
(
3
), p.
031402
.
22.
Christensen
,
S. H.
, and
Ernø-Kjølhede
,
E.
,
2012
, “Socio-Technical Integration in Engineering Education: A Never-Ending Story,”
Engineering, Development and Philosophy: American, Chinese and European Perspectives
,
S. H.
Christensen
,
C.
Mitcham
,
B.
Li
, and
Y.
An
, eds.,
Springer Netherlands
,
Dordrecht
, pp.
197
213
.
23.
Neumeyer
,
X.
,
Chen
,
W.
, and
McKenna
,
A. F.
,
2013
, “
Embedding Context in Teaching Engineering Design
,”
Adv. Eng. Educ.
,
3
(
4
), pp.
1
19
.
24.
Ro
,
H. K.
,
Merson
,
D.
,
Lattuca
,
L. R.
, and
Terenzini
,
P. T.
,
2015
, “
Validity of the Contextual Competence Scale for Engineering Students
,”
J. Eng. Educ.
,
104
(
1
), pp.
35
54
.
25.
Kilgore
,
D.
,
Atman
,
C. J.
,
Yasuhara
,
K.
,
Barker
,
T. J.
, and
Morozov
,
A.
,
2007
, “
Considering Context: A Study of First-Year Engineering Students
,”
J. Eng. Educ.
,
96
(
4
), pp.
321
334
.
26.
Mohedas
,
I.
,
Daly
,
S. R.
, and
Sienko
,
K. H.
,
2015
, “
Requirements Development: Approaches and Behaviors of Novice Designers
,”
ASME J. Mech. Des.
,
137
(
7
), p.
071407
.
27.
Devine-Wright
,
P.
,
Batel
,
S.
,
Aas
,
O.
,
Sovacool
,
B.
,
Labelle
,
M. C.
, and
Ruud
,
A.
,
2017
, “
A Conceptual Framework for Understanding the Social Acceptance of Energy Infrastructure: Insights From Energy Storage
,”
Energy Policy
,
107
, pp.
27
31
.
28.
Urmee
,
T.
, and
Gyamfi
,
S.
,
2014
, “
A Review of Improved Cookstove Technologies and Programs
,”
Renew. Sustain. Energy Rev.
,
33
, pp.
625
635
.
29.
Uddin
,
S. M. N.
,
Muhandiki
,
V. S.
,
Sakai
,
A.
,
Al Mamun
,
A.
, and
Hridi
,
S. M.
,
2014
, “
Socio-Cultural Acceptance of Appropriate Technology: Identifying and Prioritizing Barriers for Widespread Use of the Urine Diversion Toilets in Rural Muslim Communities of Bangladesh
,”
Technol. Soc.
,
38
, pp.
32
39
.
30.
Mac Mahon
,
J.
, and
Gill
,
L. W.
,
2018
, “
Sustainability of Novel Water Treatment Technologies in Developing Countries: Lessons Learned From Research Trials on a Pilot Continuous Flow Solar Water Disinfection System in Rural Kenya
,”
Dev. Eng.
,
3
, pp.
47
59
.
31.
Toyama
,
K.
,
2015
,
Geek Heresy: Rescuing Social Change From the Cult of Technology
,
PublicAffairs
,
New York
.
32.
Walther
,
J.
,
Miller
,
S. E.
, and
Sochacka
,
N. W.
,
2017
, “
A Model of Empathy in Engineering as a Core Skill, Practice Orientation, and Professional Way of Being
,”
J. Eng. Educ.
,
106
(
1
), pp.
123
148
.
33.
Kouprie
,
M.
, and
Visser
,
F. S.
,
2009
, “
A Framework for Empathy in Design: Stepping Into and Out of the User’s Life
,”
J. Eng. Des.
,
20
(
5
), pp.
437
448
.
34.
Kramer
,
J.
,
Agogino
,
A. M.
, and
Roschuni
,
C.
,
2016
, “
Characterizing Competencies for Human-Centered Design
,”
Volume 7: 28th International Conference on Design Theory and Methodology
,
Charlotte, NC
,
Aug. 21–24
, American Society of Mechanical Engineers, p. V007T06A026.
35.
Simonsen
,
J.
, and
Robertson
,
T.
,
2012
,
Routledge International Handbook of Participatory Design
,
Routledge
,
New York
.
36.
Smith
,
R. C.
,
Bossen
,
C.
, and
Kanstrup
,
A. M.
,
2017
, “
Participatory Design in an Era of Participation
,”
CoDesign
,
13
(
2
), pp.
65
69
.
37.
Augstein
,
M.
,
Neumayr
,
T.
,
Pimminger
,
S.
,
Ebner
,
C.
,
Altmann
,
J.
, and
Kurschl
,
W.
,
2018
, “
Contextual Design in Industrial Settings: Experiences and Recommendations
,”
ICEIS 2018 – 20th International Conference on Enterprise Information Systems
,
2
, pp.
429
440
.
38.
Ventura
,
J.
, and
Bichard
,
J.-A.
,
2017
, “
Design Anthropology or Anthropological Design? Towards ‘Social Design’
,”
Int. J. Des. Creat. Innov.
,
5
(
3–4
), pp.
222
234
.
39.
Hammersley
,
M.
,
2006
, “
Ethnography: Problems and Prospects
,”
Ethnogr. Educ.
,
1
(
1
), pp.
3
14
.
40.
Salvador
,
T.
,
Bell
,
G.
, and
Anderson
,
K.
,
1999
, “
Design Ethnography
,”
Des. Manag. J.
,
10
(
4
), pp.
35
41
.
41.
Sandhu
,
J. S.
,
Altankhuyag
,
P.
, and
Amarsaikhan
,
D.
,
2007
, “
Serial Hanging Out: Rapid Ethnographic Needs Assessment in Rural Settings
,”
International Conference on Human-Computer Interaction
,
Beijing, China
,
July 22–27
, pp.
614
623
.
42.
Mohedas
,
I.
,
Sabet Sarvestani
,
A.
,
Daly
,
S. R.
, and
Sienko
,
K. H.
,
2015
, “
Applying Design Ethnography to Product Evaluation: A Case Example of Medical Device in a Low-Resource Setting
,”
International Conference on Engineering Design
,
Milan, Italy
,
July 27–30
, pp.
401
410
.
43.
Wood
,
A. E.
, and
Mattson
,
C. A.
,
2019
, “
Quantifying the Effects of Various Factors on the Utility of Design Ethnography in the Developing World
,”
Res. Eng. Des.
,
30
(
3
), pp.
317
338
.
44.
Mitcham
,
C.
, and
Munoz
,
D.
,
2010
, “
Humanitarian Engineering
,”
Synth. Lect. Eng. Technol. Soc.
,
5
(
1
), pp.
1
87
.
45.
Amrose
,
S.
,
Bilton
,
A. M.
, and
Kramer
,
B.
,
2021
, “
The Future of Development Engineering—Our Vision for the Next Generation of Publications in DevEng
,”
Dev. Eng.
,
6
, p.
100059
.
46.
Thomas
,
E.
,
2020
, “What Is Global Engineering?,”
The Global Engineers: Building a Safe and Equitable World Together
,
E.
Thomas
, ed.,
Springer International Publishing
,
Cham
, pp.
1
19
.
47.
Jagtap
,
S.
,
2019
, “
Key Guidelines for Designing Integrated Solutions to Support Development of Marginalised Societies
,”
J. Cleaner Prod.
,
219
, pp.
148
165
.
48.
Janzer
,
C. L.
, and
Weinstein
,
L. S.
,
2014
, “
Social Design and Neocolonialism
,”
Des. Cult.
,
6
(
3
), pp.
327
343
.
49.
Nieusma
,
D.
, and
Riley
,
D.
,
2010
, “
Designs on Development: Engineering, Globalization, and Social Justice
,”
Eng. Stud.
,
2
(
1
), pp.
29
59
.
50.
Lissenden
,
J.
,
Maley
,
S.
, and
Mehta
,
K.
,
2015
, “
An Era of Appropriate Technology: Evolutions, Oversights and Opportunities
,”
J. Humanit. Eng.
,
3
(
1
), pp.
24
35
.
51.
Burleson
,
G.
,
Sienko
,
K. H.
, and
Toyama
,
K.
,
2020
, “
Incorporating Contextual Factors Into a Design Process: An Analysis of Engineering for Global Development Literature
,”
International Design Engineering Technical Conferences and Computers and Information in Engineering Conference
,
Virtual, Online
,
Aug. 17–19
, American Society of Mechanical Engineers, p. V11BT11A009.
52.
Lawson
,
B.
, and
Dorst
,
K.
,
2013
,
Design Expertise
,
Routledge
,
New York
.
53.
Deininger
,
M.
,
Daly
,
S. R.
,
Sienko
,
K. H.
, and
Lee
,
J. C.
,
2017
, “
Novice Designers’ Use of Prototypes in Engineering Design
,”
Des. Stud.
,
51
, pp.
25
65
.
54.
Loweth
,
R. P.
,
Daly
,
S. R.
,
Hortop
,
A.
,
Strehl
,
E. A.
, and
Sienko
,
K. H.
,
2021
, “
A Comparative Analysis of Information Gathering Meetings Conducted by Novice Design Teams Across Multiple Design Project Stages
,”
ASME J. Mech. Des.
,
143
(
9
), p.
092301
.
55.
Rekonen
,
S.
, and
Hassi
,
L.
,
2018
, “
Impediments for Experimentation in Novice Design Teams
,”
Int. J. Des. Creat. Innov.
,
6
(
3–4
), pp.
235
255
.
56.
Tessmer
,
M.
, and
Wedman
,
J.
,
1995
, “
Context-Sensitive Instructional Design Models: A Response to Design Research, Studies, and Criticism
,”
Perform. Improv. Q.
,
8
(
3
), pp.
38
54
.
57.
Atman
,
C.
,
Yasuhara
,
K.
,
Adams
,
R.
,
Barker
,
T.
,
Turns
,
J.
, and
Rhone
,
E.
,
2008
, “
Breadth in Problem Scoping: A Comparison of Freshman and Senior Engineering Students
,”
Int. J. Eng. Educ.
,
24
(
2
), pp.
234
245
.
58.
Mercer
,
K.
,
Weaver
,
K.
, and
Stables-Kennedy
,
A.
,
2019
, “
Understanding Undergraduate Engineering Student Information Access and Needs: Results from a Scoping Review
,”
2019 ASEE Annual Conference & Exposition
,
Tampa, FL
,
June 16–19
.
59.
Kolko
,
J.
,
2011
,
Exposing the Magic of Design: A Practitioner's Guide to Methods & Theory of Synthesis
,
Oxford University Press
,
New York
.
60.
Gumienny
,
R.
,
Lindberg
,
T.
, and
Meinel
,
C.
,
2011
, “
Exploring the Synthesis of Information in Design Processes—Opening the Black-Box
,”
Proceedings of the 18th International Conference on Engineering Design
,
Copenhagen, Denmark
,
Aug. 15–18
, pp.
446
455
.
61.
Deininger
,
M.
,
Daly
,
S. R.
,
Sienko
,
K. H.
,
Lee
,
J. C.
, and
Kaufmann
,
E. E.
,
2019
, “
Investigating Prototyping Approaches of Ghanaian Novice Designers
,”
Des. Sci.
,
5
(
6
), pp.
1
36
.
62.
Cross
,
N.
,
2004
, “
Expertise in Design: An Overview
,”
Des. Stud.
,
25
(
5
), pp.
427
441
.
63.
Deininger
,
M.
,
Daly
,
S. R.
,
Lee
,
J. C.
,
Seifert
,
C. M.
, and
Sienko
,
K. H.
,
2019
, “
Prototyping for Context: Exploring Stakeholder Feedback Based on Prototype Type, Stakeholder Group and Question Type
,”
Res. Eng. Des.
,
30
(
4
), pp.
453
471
.
64.
Atman
,
C. J.
,
Adams
,
R. S.
,
Cardella
,
M. E.
,
Turns
,
J.
,
Mosborg
,
S.
, and
Saleem
,
J.
,
2007
, “
Engineering Design Processes: A Comparison of Students and Expert Practitioners
,”
J. Eng. Educ.
,
96
(
4
), pp.
359
379
.
65.
Björklund
,
T. A.
,
2013
, “
Initial Mental Representations of Design Problems: Differences Between Experts and Novices
,”
Des. Stud.
,
34
(
2
), pp.
135
160
.
66.
Tracy
,
S. J.
,
2010
, “
Qualitative Quality: Eight ‘Big-Tent’ Criteria for Excellent Qualitative Research
,”
Qual. Inq.
,
16
(
10
), pp.
837
851
.
67.
Morkos
,
B.
,
Joshi
,
S.
, and
Summers
,
J. D.
,
2019
, “
Investigating the Impact of Requirements Elicitation and Evolution on Course Performance in a Pre-Capstone Design Course
,”
J. Eng. Des.
,
30
(
4–5
), pp.
155
179
.
68.
Mohedas
,
I.
,
Daly
,
S. R.
, and
Sienko
,
K. H.
,
2014
, “
Design Ethnography in Capstone Design: Investigating Student Use and Perceptions
,”
Int. J. Eng. Educ.
,
30
(
4
), pp.
888
900
.
69.
Sienko
,
K. H.
,
Young
,
M. R.
,
Effah Kaufmann
,
E.
,
Obed
,
S.
,
Danso
,
K. A.
,
Opare-Addo
,
H. S.
,
Odoi
,
A. T.
,
Turpin
,
C. A.
, and
Konney
,
T.
,
2018
, “
Global Health Design: Clinical Immersion, Opportunity Identification and Definition, and Design Experiences
,”
Int. J. Eng. Educ.
,
34
(
2(B)
), pp.
780
800
.
70.
Hu
,
W.-L.
, and
Reid
,
T.
,
2018
, “
The Effects of Designers’ Contextual Experience on the Ideation Process and Design Outcomes
,”
ASME J. Mech. Des.
,
140
(
10
), p.
101101
.
71.
Burleson
,
G.
,
Herrera
,
S. V. S.
,
Toyama
,
K.
, and
Sienko
,
K. H.
,
2021
, “
Initial Characterization of Novice Engineering Designers’ Consideration of Contextual Factors
,”
International Conference on Engineering Design
,
Gothenburg, Sweden
,
Aug. 16–20
, Cambridge University Press, pp.
1857
1866
.
72.
Garrison
,
D. R.
,
Cleveland-Innes
,
M.
,
Koole
,
M.
, and
Kappelman
,
J.
,
2006
, “
Revisiting Methodological Issues in Transcript Analysis: Negotiated Coding and Reliability
,”
Internet High. Educ.
,
9
(
1
), pp.
1
8
.
73.
Campbell
,
J. L.
,
Quincy
,
C.
,
Osserman
,
J.
, and
Pedersen
,
O. K.
,
2013
, “
Coding In-Depth Semistructured Interviews: Problems of Unitization and Intercoder Reliability and Agreement
,”
Sociol. Methods Res.
,
42
(
3
), pp.
294
320
.
74.
Terry
,
G.
, and
Hayfield
,
N.
,
2020
,
Handbook of Qualitative Research in Education
,
Edward Elgar Publishing
,
Northampton, MA
, pp.
430
441
.
75.
Cech
,
E. A.
,
2014
, “
Culture of Disengagement in Engineering Education?
,”
Sci. Technol. Hum. Values
,
39
(
1
), pp.
42
72
.
76.
Cech
,
E. A.
,
2013
, “The (Mis)Framing of Social Justice: Why Ideologies of Depoliticization and Meritocracy Hinder Engineers’ Ability to Think About Social Injustices,”
Engineering Education for Social Justice: Critical Explorations and Opportunities
,
J.
Lucena
, ed.,
Springer Netherlands
,
Dordrecht
, pp.
67
84
.
77.
Karwat
,
D. M. A.
,
Eagle
,
W. E.
,
Wooldridge
,
M. S.
, and
Princen
,
T. E.
,
2015
, “
Activist Engineering: Changing Engineering Practice by Deploying Praxis
,”
Sci. Eng. Ethics
,
21
(
1
), pp.
227
239
.
78.
Karwat
,
D. M. A.
,
2020
, “
Self-Reflection for Activist Engineering
,”
Sci. Eng. Ethics
,
26
(
3
), pp.
1329
1352
.
79.
Smith
,
J. M.
, and
Smith
,
N. M.
,
2018
, “
Engineering and the Politics of Commensuration in the Mining and Petroleum Industries
,”
Engag. Sci. Technol. Soc.
,
4
, pp.
67
84
.
80.
Morgan
,
D. L.
,
Davis
,
K. B.
, and
López
,
N.
,
2020
, “
Engineering Political Fluency: Identifying Tensions in the Political Identity Development of Engineering Majors
,”
J. Eng. Educ.
,
109
(
1
), pp.
107
124
.
81.
Boucher
,
J. L.
,
Levenda
,
A. M.
,
Morales-Guerrero
,
J.
,
Macias
,
M. M.
, and
Karwat
,
D. M. A.
,
2020
, “
Establishing a Field of Collaboration for Engineers, Scientists, and Community Groups: Incentives, Barriers, and Potential
,”
Earths Future
,
8
(
10
), pp.
1
19
.
82.
Bengtson
,
M.
,
Bharadwaj
,
M.
,
ten Bosch
,
A.
,
Nyakundi
,
H.
,
Matoke-Muhia
,
D.
,
Dekker
,
C.
, and
Diehl
,
J.-C.
,
2020
, “
Matching Development of Point-of-Care Diagnostic Tests to the Local Context: A Case Study of Visceral Leishmaniasis in Kenya and Uganda
,”
Glob. Health Sci. Pract.
,
8
(
3
), pp.
549
565
.
83.
Kelly
,
J. C.
,
Maheut
,
P.
,
Petiot
,
J.-F.
, and
Papalambros
,
P. Y.
,
2011
, “
Incorporating User Shape Preference in Engineering Design Optimisation
,”
J. Eng. Des.
,
22
(
9
), pp.
627
650
.
84.
Cross
,
N.
,
2021
,
Engineering Design Methods: Strategies for Product Design
,
John Wiley & Sons
,
Hoboken, NJ
.
85.
Baker
,
L.
,
2006
, “
Observation: A Complex Research Method
,”
Libr. Trends
,
55
(
1
), pp.
171
189
.
86.
Spradley
,
J. P.
,
1980
,
Participant Observation
,
Waveland Press
,
Long Grove, IL
.
87.
Zenios
,
S.
,
2009
, “Observation and Problem Identification,”
Biodesign: The Process of Innovating Medical Technologies
,
Cambridge University Press Textbooks
,
Cambridge
.
88.
Jagtap
,
S.
, and
Larsson
,
T.
,
2020
,
Designing integrated solutions for resource-limited societies in Research & Education in Design: People & Processes & Products & Philosophy
,
Taylor & Francis
,
London
, pp.
289
296
.
89.
Ward
,
T. A.
,
2013
, “
Common Elements of Capstone Projects in the World’s Top-Ranked Engineering Universities
,”
Eur. J. Eng. Educ.
,
38
(
2
), pp.
211
218
.
90.
Mohedas
,
I.
,
Sienko
,
K. H.
,
Daly
,
S. R.
, and
Cravens
,
G. L.
,
2020
, “
Students’ Perceptions of the Value of Stakeholder Engagement During Engineering Design
,”
J. Eng. Educ.
,
109
(
4
), pp.
760
779
.
91.
McKenna
,
B.
,
Myers
,
M. D.
, and
Newman
,
M.
,
2017
, “
Social Media in Qualitative Research: Challenges and Recommendations
,”
Inf. Organ
,
27
(
2
), pp.
87
99
.
92.
Eilander
,
D.
,
Trambauer
,
P.
,
Wagemaker
,
J.
, and
van Loenen
,
A.
,
2016
, “
Harvesting Social Media for Generation of Near Real-Time Flood Maps
,”
Procedia Eng.
,
154
, pp.
176
183
.
93.
Tuarob
,
S.
, and
Tucker
,
C. S.
,
2014
, “
Discovering Next Generation Product Innovations by Identifying Lead User Preferences Expressed Through Large Scale Social Media Data
,”
International Design Engineering Technical Conferences and Computers and Information in Engineering Conference
,
Buffalo, NY
,
Aug. 17–20
.
94.
Rodriguez-Calero
,
I. B.
,
Coulentianos
,
M. J.
,
Daly
,
S. R.
,
Burridge
,
J.
, and
Sienko
,
K. H.
,
2020
, “
Prototyping Strategies for Stakeholder Engagement During Front-End Design: Design Practitioners’ Approaches in the Medical Device Industry
,”
Des. Stud.
,
71
, p.
100977
.
95.
Schweitzer
,
J.
,
Groeger
,
L.
, and
Sobel
,
L.
,
2016
, “
The Design Thinking Mindset: An Assessment of What We Know and What We See in Practice
,”
J. Des. Busi. Soc.
,
2
(
1
), pp.
71
92
.
96.
Adams
,
R. S.
,
Daly
,
S. R.
,
Mann
,
L. M.
, and
Dall’Alba
,
G.
,
2011
, “
Being a Professional: Three Lenses Into Design Thinking, Acting, and Being
,”
Des. Stud.
,
32
(
6
), pp.
588
607
.
97.
Atman
,
C. J.
,
2019
, “
Design Timelines: Concrete and Sticky Representations of Design Process Expertise
,”
Des. Stud.
,
65
, pp.
125
151
.
98.
Sadokierski
,
Z.
,
2020
, “
Developing Critical Documentation Practices for Design Researchers
,”
Des. Stud.
,
69
, p.
100940
.
99.
Coulentianos
,
M. J.
,
Rodriguez-Calero
,
I.
,
Daly
,
S. R.
, and
Sienko
,
K. H.
,
2020
, “
Stakeholder Engagement With Prototypes During Front-End Medical Device Design: Who Is Engaged With What Prototype?
Proceedings of the 2020 Design of Medical Devices Conference. 2020 Design of Medical Devices Conference
,
Minneapolis, MN
,
Apr. 6–9
.
100.
Coulentianos
,
M. J.
,
Rodriguez-Calero
,
I.
,
Daly
,
S. R.
,
Burridge
,
J.
, and
Sienko
,
K. H.
,
2022
, “
Stakeholders, Prototypes, and Settings of Front-End Medical Device Design Activities
,”
ASME J. Med. Dev.
,
16
(
3
), p.
031010
.
101.
Coulentianos
,
M. J.
,
Rodriguez-Calero
,
I.
,
Daly
,
S. R.
, and
Sienko
,
K. H.
,
2020
, “
Global Health Front-End Medical Device Design: The Use of Prototypes to Engage Stakeholders
,”
Dev. Eng.
,
5
, p.
100055
.
102.
Smith
,
R. C.
, and
Iversen
,
O. S.
,
2018
, “
Participatory Design for Sustainable Social Change
,”
Des. Stud.
,
59
, pp.
9
36
.
103.
Loweth
,
R. P.
,
Daly
,
S. R.
,
Liu
,
J.
, and
Sienko
,
K. H.
,
2020
, “
Assessing Needs in a Cross-Cultural Design Project: Student Perspectives and Challenges
,”
Int. J. Eng. Educ.
,
36
(
2
), pp.
712
731
.
104.
Mohedas
,
I.
,
Daly
,
S. R.
, and
Sienko
,
K. H.
,
2016
, “
Use of Skill Acquisition Theory to Understand Novice to Expert Development in Design Ethnography
,”
Int. J. Eng. Educ.
,
32
(
3(B)
), pp.
1364
1371
.
105.
Young
,
M. R.
,
Daly
,
S. R.
,
Hoffman
,
S. L.
,
Sienko
,
K. H.
, and
Gilleran
,
M. A.
,
2017
, “
Assessment of a Novel Learning Block Model for Engineering Design Skill Development: A Case Example for Engineering Design Interviewing
,”
2017 ASEE Annual Conference & Exposition
,
Columbus, OH
,
June 25–28
.
106.
2020
,
ABET Requirements
, Accreditation Board for Engineering and Technology.