CHAPTER 4
INFORMATION-RICH ENGINEERING DESIGN
David Radcliffe, Purdue University
Learning Objectives
So that you can implement a robust, informed approach to teaching design to students, upon reading this chapter you should be able to
•List and describe the seven essential activities of engineering design used to frame this book
•List and describe the major information-seeking/creating activity associated with each of the seven elemental design activities
•Characterize the seven major information-seeking/creating activities associated with each of the elemental design activities in terms of variety and depth of information required
•Outline the implications for mapping potentially helpful information literacy interventions in engineering design courses
INTRODUCTION
The review of the nature of engineering design in Chapter 1 revealed a many-faceted, contingent, sociotechnical endeavor that is difficult to define, capture, and characterize in a simple manner. While recognizing the complex, emergent nature of engineering design and the diversity of perspectives, for the purposes of this handbook we have distilled from the analysis in Chapter 1 seven elemental activities that are part of any engineering design project. These are not intended to be a linear prescribed set of actions in an engineering design project. On the contrary, most of these activities occur at multiple times across any project, perhaps at different scales and at different levels of detail. For instance, one of the seven activities involves organizing a project team. While this happens initially at the beginning of a project, inevitably there are changes in the composition of the team in terms of personnel and roles related to changes in emphasis and disciplinary expertise as a design project unfolds. In that way aspects of team formation can occur at multiple points throughout a project.
These seven elemental activities are not another model of the engineering design process. They are offered simply as a convenient device for organizing the material in this handbook— a placeholder for whichever conception or model of design a particular educator or academic tradition prefers to use when introducing students to engineering design—and are used to focus attention on the different types of information-related activities that engineering students should master. The intention is that the ideas around information literacy pertinent to each of the seven design activities can be readily mapped back by the reader to any particular model of engineering design.
ELEMENTAL ENGINEERING DESIGN ACTIVITIES
Of the seven elemental engineering design activities considered in this framework, five reflect the recurring ideas from the descriptive and prescriptive models: clarify the task, synthesize many possible solutions, select the most suitable solution, refine the preferred solution, and communicate the solution to inform and persuade the stakeholders. The other two activities acknowledge the social dimension of design: organize the team, and throughout the design project continuously reflect upon and improve processes. These activities are represented in Table 4.1.
TABLE 4.1Summary of Elemental Engineering Design Activities
| Design Activity | Example Tasks | |
Improve Design Work Processes Reflect on and analyze what is working and what needs improvements throughout the project Use a disciplined modes of reflection to capture lessons learned |
||
| Organize Your Team | Select/change team members to achieve a diversity of knowledge, skills, and qualities Agree on a code of conduct and active modes of intra-team communication Build/renew team cohesion including a shared understanding of team dynamics Adopt team maintenance tools and process improvement schedule Establish information strategy, including capture, storage, and use Define team member roles, reporting, and review processes Review and improve processes throughout the project |
|
| Clarify the Task | Analyze the brief and any other initiating documents Speak with client, potential users, and other key stakeholders; ask questions Identify additional sources of information that will establish the wider context Estimate the order of magnitude of things associated with the project Develop a list of possible risks and opportunities Determine the scope of the work to be done in relation to the wider context List the requirements and constraints for the product/system/process Articulate the specific design criteria/measures of success |
|
| Synthesize Possibilities | Explore the prior art in the widest sense of the term Investigate similar and quite different operational contexts for ideas Gather information for existing artifacts, literature, experts, observation Develop as many concepts and combinations of concepts as possible Test ideas and improve initial concepts to learn more about the tasks Refine scope of work; relax constraints |
|
| Select Solution | Select the most promising concepts from the many options Flesh out (embody) preferred concept(s) and analyze these to understand performance Conduct a design review with client based on this analysis and gain feedback |
|
| Refine Solution | Visualize/model the manufacture, installation, operation, and maintenance Estimate cost structure for whole of life cost Refine risk and opportunity analysis |
|
| Communicate Effectively with all Stakeholders | Identify and stay in regular communication with key stakeholders who need to be heard, informed, or persuaded at any time during design process Get to know and appreciate their perspective and hence their information needs |
|
These activities cover the product development process up to the point where the proposed solution is documented such that it can be made and implemented. Of course, the complete life cycle of a new product, system, or service includes the subsequent processes of manufacture, installation, commissioning, operations, maintenance, updating as technologies change, retirement from operation, and reuse or recycling of the component elements (McDonough & Braungart, 2002). The whole life cycle also includes such things as the training of users or operators or other service or support staff and provision of necessary support infrastructure and spare parts.
Decisions made in these early stages of the product realization process shape the subsequent or downstream life stages, including such things as the whole of life cost of the product, system, or service being designed and its overall sustainability. Thus, the earlier relevant information is introduced, the larger its impact on the entire product life cycle; hence the critical importance of integrating information literacy (broadly defined) as early as possible into the design process and blending it into the education of engineering students as they learn to think as engineering designers.
INFORMATION-RICH ENGINERING DESIGN(I-RED) MODEL
During engineering design, existing information is used and new information is generated. In this handbook the shorthand term information-seeking/creating is used to capture this idea. Figure 4.1 outlines the seven information-seeking/creating activities associated with each elemental design activity.
FIGURE 4.1Information-seeking activities corresponding to design activities (Table 4.1 and Figure 4.2).
Organize Team: Develop Knowledge Management Strategy
In forming and/or modifying a design team for a particular project or phase of a project, the goal is to gather the most appropriate range of disciplinary backgrounds with sufficient levels of knowledge and experience and complementary personal attributes and professional skills. Factors that influence team performance include the range of technical knowledge and skills, temperaments, work styles (e.g., starters versus finishers, big-picture versus detail-oriented people), organizational and leadership skills, and oral and written communication skills.
From an information-seeking/creating perspective, the primary objective in organizing the team is to develop a strategy for organizing and managing information. It is imperative that the strategy and the metadata structures and tools to be used for knowledge management throughout the project be carefully thought through before the project work commences. This is an upfront investment that can pay significant dividends later in the project in terms of effort saved by not wasting time locating project-critical information, ensuring that ideas and information from an early phase of the project are not forgotten by a later stage, and expediting and making the intermediate and final communications and documentation of project information much more efficient and effective.
One set of skills often overlooked when considering a knowledge management strategy is the level of information literacy of the members. By including team formation as part of the I-RED model, attention is focused on the need to establish a core capability amongst the members to be able to identify, locate, gather, analyze, synthesize, and share information (information seeking) within the team and with other stakeholders. The information literacy of the team sets a foundational baseline in terms of the ability of team members to seek and share information effectively, which in turn is a key determinant of the overall effectiveness of the design work they undertake.
Clarify Task: Provide Context
The team’s purpose in clarifying the task is to create a coherent and cogent description of purpose and scope of the design need or opportunity before them. This includes establishing a set of criteria by which the outcome will be judged by the client or user and the other stakeholders more generally. The client might give an initial need statement, such as, “I need a water purification system for a community of 2,000 people.” From that brief statement, the team must determine what specific objectives the client may have, quantify and clarify the specific requirements, and determine the constraints or opportunities, including the type and amount of resources available for the solution. Much of this phase involves working with clients to better understand their expectations. Sapp Nelson (2009) found that the library science technique of reference interviewing can facilitate better elicitation of client requirements. Clients and/or users often state their need in terms of a solution. The design team has to unpack this to identify the underlying need that must be satisfied.
This design activity centers on gathering preliminary information on the broad context of the design task. In the case of the water purification system example, this might include exploring the different types of purification systems, specific health risks of unclean water, and the local cultural, economic, and political environment of the stakeholders. Seeking out such information can help the team generate pertinent questions for the client and other stakeholders to help them articulate objectives they didn’t realize they had and to surface constraints or conditions that will limit or bound the possible solution space. These questions are an instance of information creation. If there are regulations or other legal requirements—for example, clean water standards—then those are constraints on any solution.
Information seeking during these activities centers on general sources of information, such as encyclopedias, trade magazines, or handbooks, which can give an overview of the major technologies being used to solve the problem. Codes and regulations provide guidance on legal constraints. When teaching the informational component of this phase, focusing on the initiation stage of the Information Search Process (ISP) is the most important (Kuhlthau, 2004). This is the phase when students will need to determine what information they know and what information they still need to find. Often with novices, “they don’t know what they don’t know,” so they have difficulty articulating the need for information. Providing students with some structure for asking questions can facilitate their moving beyond an “ignorance is bliss” phase and get them to engage with what they don’t know.
Synthesize Solutions: Investigate Prior Work
During this design activity the team consolidates and prioritizes a list of design requirements uncovered during task clarification and they explore potential design solutions that could meet those assembled needs and any constraints. This is a very creative phase, involving brainstorming and other activities focused on idea generation and the synthesis of possible solutions. As such there is a considerable amount of new information generated that has to be organized and managed lest good ideas get lost. A valuable trigger for this is to explore the prior art, solutions to similar problems that others have designed, and other technologies that might have novel applications to this problem. In order to enlarge the range of potential options to the fullest extent possible, an eclectic range of information types and sources need to be consulted. While the patent literature might be the most obvious source of information on specific technologies, at this phase of the process, where the emphasis is on developing a large number of possibilities, a more efficient way to investigate prior art might be to peruse the popular literature for reports of other solutions, including material provided by engineering firms, nonprofits, or other organizations that have worked on similar problems.
As part of creating options, the design team needs to consider the whole life cycle of potential solutions. This can include considerations of how to build it, how it will be used after fabrication, how it will be maintained, and what will happen when it reaches the end of its life cycle (repurposing, reuse, or recycling, for example).
Select Solution: Assess Technologies and Approaches
This design activity is where conceptual design solutions are evaluated to determine which solution will finally be selected for detailed development and implementation. This can involve selecting a short list of two or three prospective concepts from a larger initial set of ideas and approaches. The final selection of the most suitable concept usually requires that the two or three prospective concepts be fleshed out (embodied) in the form of basic configurations that can be evaluated— for instance, as a computer model to determine whether these preliminary design concepts are feasible and practical. Often this is a hands-on phase of design, during which the team makes simple or more sophisticated prototypes and conduct tests to see if they meet the design specifications. So as to facilitate testing of the ideas, an overall system might be decomposed into a series of subsystems that can be evaluated. In that case, the inputs and outputs of each subsystem will have to be determined to ensure compatibility and interoperability. Again there is a considerable amount of information generated during this design activity.
For this phase, standard testing processes, laboratory and experimental procedures, and information about appropriate simulation/modeling software could all be needed. This enables the team to determine whether a particular model is appropriate for the use case of the design problem, and whether, for example, the results can be extrapolated from a model to the full scale. Additionally, the management of new data and information assembled and created during prototyping and testing needs to be carried out appropriately. As Carlson, Fosmire, Miller, and Sapp Nelson (2011) note, data information literacy is a robust new area for librarians to apply (and teach) information management skills to the curation of data.
Refine Solution: Assemble Detailed Technical Information
The focus in refining the solution is on developing and documenting an increasingly detailed description of precisely what the product, system, or service will be like. This is an information-intensive activity wherein the selected preliminary design is turned into something that can actually be made. For example, the actual materials or standard components to be used are selected to ensure that they all meet the relevant codes and regulations for performance. Questions such as will pieces fit together, can the component be serviced without taking apart the entire artifact, and can the output of one stage of the artifact be used as an input in the next stage are all important to resolve. Such considerations apply not only to hardware but also to software. For example, writing computer code for a software program involves the construction of modules and objects, many of which may come from preexisting standard libraries. As a result, it is very important that the output of an object is in a format and with appropriate units that can be used in a subsequent routine.
For this design activity, handbooks, product catalogs, and component specifications are all important to make sure that the result is practical and achievable. Patents will shed light on the more cutting edge technologies that could be licensed for use in the project.
Communicate: Distill and Translate Project Knowledge
The completed description of the product, system, or service needs to be communicated to those who will make it, install it, operate it, maintain it, update it, and even dismantle and recycle components of it. The amount of information necessary to describe all these facets of even a relatively simple product is substantial. For a large system the quantum is enormous. The nature and the format of the information that is required for all the stakeholders is significantly different than the core technical information necessary to define the product, system, or service that was designed. New information based on this core technical data must be generated in order to interpret the core description to particular audiences. For instance, much of the information in a user manual is not developed explicitly as part of the creation of the core technical description. The user manual draws on this core description and many explicit and some implicit assumptions that went into a variety of design decisions made throughout the project. The relevant information has to be distilled and then translated into a form and a format that makes it easily accessible to the user. The same applies for the additional information needed to guide the manufacture, assembly, installation, operation, and maintenance of the product, system, or service.
This process actually takes place as part of each of the forgoing design activities and not simply at the completion of detailed design. By communicating ideas and partial details and seeking feedback from the relevant stakeholders throughout the entire project, the design team can much more effectively manage expectations and identify potential problems early and remedy them before too much time or resources have been expended on an idea or a detail that will ultimately not succeed.
Thus the design team should capture the information found and generated during each design activity, including any computer models and modeling data, tests plans and data, mock-ups, functional prototypes, and the like. It is especially important at this point that information is well documented. Others will be using the information presented in this section, so they need to know where information exists, for example, on the safety codes for operation, or the material composition of components for potential recycling. The most recent and complete information about supplier information, codes met, availability of replacement parts, or authorized maintenance all are important in the final documentation.
Reflect: Organize and Document Lessons Learned
Throughout all the design activities the team must strive to improve their processes of working to be more holistic, more effective, and more efficient. Central to this; is continuously improving their knowledge management processes and being disciplined and diligent in staying up to date with their information-seeking activities.
During the clarification of the task many types of information are gathered, and it is often difficult to know with any certainty which ones are going to be particularly useful later in the project. Time spent organizing and curating early information, much of which may turn out not to be important, can prove to be wasted once the direction and scope of the project becomes clearer. Equally, not capturing and describing this early information could prove very costly later. There is no simple solution to this dilemma; each project has a unique set of problems of this type. One effective approach is to regularly use the knowledge management strategy developed as part of organizing the team and to learn from that experience. The system should be periodically reviewed and improved as the problematic issues around information handling in the particular project reveal themselves.
Taken together, the series of elemental design activities and corresponding informationseeking activities comprise the I-RED model, depicted in Figure 4.2
Figure 4.2Information-Rich Engineering Design (I-RED) model.
PROMPTING QUESTIONS FOR INFORMATION-SEEKING ACTIVITIES
Each of the information-seeking/creating activities is characterized by a series of prompting questions, as shown in Table 4.2. This aligns with the notion of design as a question-asking process (Eris & Leifer, 2003). Pilerot and Hiort af Ornäs (2006) follow a similar approach in formulating guiding questions from not only a process- but also a product-oriented perspective. At a macro-level the overall trend in information seeking/creating follows the ISP stages. Within each information-seeking activity corresponding to an engineering design activity, the ISP moves from exploration within uncertainty toward a focus on more pertinent information that defines the later part the activity. As a project proceeds, the members of the design team tend to follow those stages described by Kuhlthau (2004)—that is, they go from uncertainty, to optimism, to confusion and doubt, which gives way to greater clarity and a sense of direction leading to, hopefully, satisfaction and accomplishment.
TABLE 4.2Example Prompting Questions for Each Information-Seeking Activity
| Information-Seeking Activity | Example Prompting Questions |
| Develop knowledge management strategy | What is the level of specialization and variety of technical and other knowledge across the team members? What is their level of proficiency in information seeking and critical evaluation? What additional information-seeking skills are required? How might additional information skills be best developed? How will they develop and implement communication and documentation policies and infrastructure? |
| Establish the context | What are the historical, social, cultural, political, geographical, and economic contexts of the problem? Who are the stakeholders? Who will use this product, system, or service throughout its life cycle—from the cradle to the grave? What are the most important requirements or functions for various stakeholders? What is absolutely necessary (needs) and what is discretionary (wants)? What are the measures of success from the perspective of all stakeholder groups? What codes or regulations does the end system/product have to comply with? |
| Investigate prior work | What approaches are possible to address this type of problem? What examples of solutions exist for this type of problem? What existing products, systems, or processes tackle similar needs or opportunities? What technologies might be used to tackle this need or opportunity? |
| Assess technologies and methods | How do the technologies scale from a prototype to full-scale implementation? How would different specifications of performance be tested? Are there relevant standards for conducting tests of materials or components? What tools would help in designing a full-scale model? What modeling or design software do professionals use in this field? What benchmarking information is available for competing products? How do proposed new solutions compare to existing ones in terms of performance, user desirability, financial viability, or other indicators of success? How can the quality of externally provided information be assessed? How do the technologies work at a deep level? What are the inherent strengths and limitations of the technologies? What is required to create, operate, and maintain these technologies? |
| Integrate technical details | What properties does a component have and what does it need to have to work properly within the system? What components need to be fabricated, and what properties do they need to have to work with the rest of the system? What components already exist that can be used as part of the solution? What are the standard inputs/outputs for the systems or subsystems (e.g., appropriate interfaces, size of conduits for moving materials)? |
| Distill and translate project knowledge | Is the documentation prepared and presented in a form and style most appropriate to the future user of that information? What are the most important ideas and details to present to particular stakeholder groups? Why? How can this best be done? |
| Improve knowledge management processes | What new information was generated and how important or valuable is it? Has all the pertinent information gathered/created and used in the design process been fully documented and cataloged, including calculations, models, graphic images, tables, and other non-textual information? Are all stages of the product/system/process life cycle adequately documented? |
MAPPING I-RED ACTIVITIES TO INFORMATION SPACE
The six pairs of engineering activities and information-seeking/creating activities at the core of the I-RED model can be located in an information space with orthogonal axes for the variety of knowledge domains and the level of specialization in a given domain. This is illustrated in Figure 4.3.
FIGURE 4.3 Mapping Information-Rich Engineering Design (I-RED) activities.
The location of each activity bubble indicates the relative breadth and depth of the types of information sought/created in the corresponding design activity. The engineering design activity of reflection on processes and the corresponding information-seeking/creating support activity of managing information and documenting learnings occur throughout all other activities. This is depicted in Figure 4.3 as a substrate (the blue ellipse) to indicate that these are pervasive activities that underpin all the others and also links them. The arrows between activities indicate that information is passed on from one activity to another.
By its location in the information space, the organize team/develop knowledge management strategy activities draw on a reasonable diversity of knowledge domains and an intermediate depth of specialization. However, the activities around clarifying the task/providing context by necessity draw upon a very diverse range of knowledge domains, although the depth of knowledge in each is relatively shallow, at least initially. Knowledge of the relevant context increases as the concepts are developed, selected, and detailed. Seeking information around prior work to support the synthesis of many possible solution concepts is more focused in terms of the variety of knowledge domains but correspondingly deeper in terms of the level of specialization. This is so because the task clarification process has reduced the scope of possibilities.
This trend of there being fewer knowledge domains yet more depth of knowledge and specialization of information type continues through the selection of suitable solutions by assessing various approaches and technologies and refining the preferred solution through gathering together substantial amounts of relatively specialized technical information.
However, in order to communicate the large amount of information that defines the final product, system, or service that was designed back to a variety of stakeholders, including the client and/or user, this information has to be distilled and translated into forms that are suitable for a wide range of people who think, work, and live in a diverse range of knowledge domains. Thus, this set of activities is shown at the top right of the information space, indicating that it involves in-depth and specialized information that must be understood in quite different knowledge domains.
APPLICATION OF THE I-RED MODEL
The I-RED model provides a descriptive rather than prescriptive approach to identifying how and when information-seeking/creating activities and training in information literacy can be integrated into the engineering design process. Both the informational and engineering design components are described as generally and generically as possible so that the model can be applied to a wide range of engineering disciplines. The purpose is to step outside of the jargon of both library science and engineering design to enable practitioners on both sides to talk directly and productively about student and project needs. The motivating factor of the model is for students to be able to determine at each stage what information they need at that time to move the project forward and how they can acquire and use that information. Instead of requiring students to do a literature review at the beginning or end of a design project, this model provides guidance for information gathering activities that can continue throughout the life of the project. This should provide students with the ability to take an integrated approach that will enhance the richness of the design of the final artifact.
This model captures the idea that as a learning process design creates knowledge as well as consumes it. Thus the members of the design team contribute to the body of knowledge. In industry this new knowledge would likely appear in a corporate intranet or knowledge management system. Historically, such new knowledge has been poorly managed in student design project teams, in part due to the lack of easy to learn and use knowledge management systems that scale to projects that may last one semester and involve a team of only five or six students. However, with the advent of large scale, lengthy student-led projects— for example, vehicle projects or service projects that extend over multiple years, during which the membership of a team might change every semester or year—much more effective knowledge management systems are needed.
The type and scope of information sought and generated in engineering design activities is very broad. Design information is not limited to documents such as books and catalogs, whether in physical or electronic form. It also comprises still and moving images; multidimensional datasets, including product and geographical information; the spoken word; and physical and virtual artifacts. The sources for and modes of gathering, capturing, analyzing/interpreting, storing, and sharing this eclectic range of information is enormous and ever changing. This has critical implications for both the development of information literacy skills in students and the work of university librarians who support design projects in engineering schools.
SUMMARY
The I-RED model combines conceptions of the design process and information literacy to create a logical framework for integrating the development and use of information skills into engineering design course work. This model also draws on my experience of teaching engineering design over many years in both the United States and Australia, including numerous collaborations with librarians to embed instruction on information literacy within the design curriculum.
With this conceptual model under our belt, the next question is how to implement these principles. The rest of this handbook investigates the main information activities corresponding to the general steps of an engineering design process model. The I-RED model is not expected to replace whatever engineering design model you may be currently teaching your students. Rather, I-RED can be integrated into your preferred models. The following chapters provide examples of activities that can be easily incorporated in a design course, with the rationale for why these information steps are important and necessary, and the resources to carry out the instruction.
REFERENCES
Carlson, J., Fosmire, M., Miller, C. C., & Sapp Nelson, M. (2011). Determining data information literacy needs: A study of students and research faculty. Portal: Libraries and the Academy, 11(2): 629–658. Retrieved from http://muse.jhu.edu/journals/portal_libraries_and_the_academy/v011/11.2.carlson.pdf
Eris, O., & Leifer, L. (2003). Facilitating product development knowledge acquisition: Interaction between the expert and the team. International Journal of Engineering Education, 19(1), 142–152.
Kuhlthau, C. C. (2004). Seeking meaning: A process approach to library and information services (2nd ed.). Westport, CT: Libraries Unlimited.
McDonough, W., & Braungart, M. (2002). Cradle to cradle: Remaking the way we make things. New York: North Point Press.
Pilerot, O., & Hiort af Ornäs, V. (2006, August). Design for information literacy: Towards embedded information literacy education for product design engineering students. Paper presented at Creating Knowledge IV, Copenhagen, Denmark. Retrieved from http://www.ck-iv.dk/papers/PilerotHiort%20Design%20
for%20information%20literacy.pdf
Sapp Nelson, M. (2009). Teaching interview skills to undergraduate engineers: An emerging area of library instruction. Issues in Science & Technology Librarianship, 58. http://dx.doi.org/10.5062/F4ZK5DMK