Teaching Front End Engineering Design (FEED)

Richard Devon & Kathryn Jablokow

Penn State University

Abstract
In this paper, we reshape the design process for teaching into two fundamental stages:
developing the problem and developing the solution. Each of these is followed by a design
review. In this manner, we address the fundamental tendency of novice designers, and some
experts, to rush not only into the solution stage but to a specific solution. We assume that
engineers know how to develop solutions, but they may be less careful in developing the right
understanding of the problem. Luckily, the design process is characterized by an inverted
relationship between decisions and costs. As the design process goes forward, the process costs
rise, but decisions become arguably less important - if never unimportant. So, problem
development is when we are making the most important decisions and spending less, usually far
less, than later on. We can afford to do problem development well, just as we cannot afford to
slight it.

We characterize problem development as Front End Engineering Design (FEED). It begins with
some sort of trigger, which may, in fact, not be a problem at all but an opportunity or a neat idea
or invention. It ends with a set of design objectives that have target specifications. We currently
have eight categories of activities in FEED: an account of the initial trigger, design
characterization, team management, market assessment and benchmarking, user needs
assessment, product exploration, a development plan, and the target specifications. We expect
others who adopt FEED to modify it according to their own views, as we probably will in the
future also.

This process is then assessed through an early design review to make sure it was done well. It is
then followed by the familiar solution development stage, and that is followed by a critical
design review. Throughout these stages, we use a new concept of design validation to show the
way in which both the design process and the product ideas are continually subject to validation
and ultimately to testing, manufacture, use, and disposal. This is aimed at teaching design as a
thoughtful reflective process.

Much of what we discuss here will appear familiar, but the restructuring is new and should be
effective in design education. We reference popular design texts to help highlight the
distinctiveness of our approach. Other new ideas presented in this paper include the trigger
concept, design characterization, design validation, and managing risk through Design for NOT
X. FEED is also a venue for innovative design. Users, and lead users in particular, can provide
many ideas for new products both of needs and technologies. The use of Design for X and
NOTX expands the imagination with respect to possible venues, uses, and risks of the type of
product being considered. And benchmarking new products and breakthroughs in relevant
technologies may provide completely new ideas. (Our students do this by organizing RSS feeds
from carefully selected sites in Google Reader.) Only being creative in the solution development
stage means missing a lot of opportunities, and possibly some of the best.

This paper is intended to provide an anchor for future papers on these topics. Examples of
student work will be provided based on two years of the first author using and developing the
approach.

A. Introduction: The Case for FEED

There are several reasons why teaching FEED is a good idea. These include the tendency of
novice designers to focus almost exclusively on solution development, the return on investment
gained by spending more time on problem development, and the ease with which the FEED-
Solution (F-S) approach can be taught to students.

1. Design Maturation. Novice designers often neglect problem development, becoming fixated
on particular solution concepts that are later found to be unsatisfactory.5 Even then, novice
designers may continue to hold on to their early ideas and try to “design out” their flaws instead
of starting over with a new design concept and/or returning to the problem definition to make
sure they have understood it correctly - as an expert designer is more likely to do.

At the same time, other studies in design education have shown that a systematic approach to the
early stages of design can be helpful to students,20 as long as it is not too rigid. Fricke12 reports
that a “flexible-methodical procedure” is the best option, in which successful designers ask
questions that explore the structure of the problem, search actively for information, critically
check and prioritize requirements, and return to clarifying the problem when first solution
concepts fail, rather than pursuing those early concepts in depth.

Atman, et al., studied design maturation in students and found that seniors design with less time
spent on problem development and more time on solution development (developing alternatives)
than first year students do.3 This apparent counter example to our claims seems to indicate that
stressing solution development over problem development is learned behavior. The authors even
refer to novices “getting stuck” on problem definition.3 In our experience, we do not see that.
However, they refer to Cross & Cross’s 1998 clinical protocol study of two professional
designers, in which they document their “...careful framing of the problem, [which] has begun to
receive attention in other studies as well. Some researchers discuss this as task clarification,
specification, and problem analysis.”6

Design educators, too, often use the language of task clarification,24 although we find it overly
narrow and only corresponding to some of the things we advocate in product exploration.
Atman, et al.,3 use the term “problem scoping.” Despite their concern with novices spending too
much time on the scoping stage, their data really show that both novices (first year) and experts
(seniors) spend over 80% of their time on scoping (done less by the seniors) and “modeling”
(roughly design embodiment of a found solution and done more by the seniors) and little on any
other categorized activity, such as gathering information or idea generation. Nevertheless, this
literature review by Atman, et al.,3 indicates that professionals see problem development as an
important activity, which raises a question about their apparent view that maturation means
spending less time on problem development. They are simply presuming that the data represent
maturation, which is an inductive rather than deductive conclusion unsupported by studies of
professional designers.

In another view, Ahmed’s series of studies of design maturation among working engineers
(descriptive design) found, for example, that analogous reasoning becomes much more
sophisticated in experienced designers since novices work with far less experience and technical
knowledge.1,2 Experts used analogies a lot for analysis and evaluation, whereas novices
primarily used them for generating concepts and a cognitive “safe haven.” [All analogies were
used only in conceptual design and none in detail design and only one was transferred from a
different knowledge domain] Expertise does bring habits of mind, however, and Ahmed does
not compare differences in creativity, which might not always be as one sided.

Further, Ahmed’s focus, and that of the research she reviews, is on solution development and not
on problem development, where different types of maturation may be evident, not the least of
which would be doing it thoroughly. And in an earlier study with Wallace and Blessing,2 Ahmed
noted that: “The majority of studies of novices and experienced designers were found to focus
upon differences in external activities, such as time spent gathering information, rather than
problem solving activities.” So, the emphasis on solution development is, for her, a necessary
corrective to these studies, which are typically of very small numbers of professional designers.
Yet in design education (prescriptive design), it is hard to argue for this corrective.3, 4, 23 Given
that our interest in FEED was prompted by the rise of consulting services in FEED in industry, it
is possible that there is a disconnect between teaching design and practicing it. Our experience
obviously has led us to this conclusion and the brief review of popular design textbooks below
supports this. In Ahmed’s defense, well taught innovative design that is informed by what is
happening in industry (good and bad) is certainly an appropriate service to provide, but not at the
expense of problem development.11

2. Improved Return on Investment (RoI). There is evidence that spending more time on front
end engineering leads to more projects getting finished on time. This means that FEED improves
the RoI curve (moving it up and to the left), and FEED consultants argue exactly that. It is
widely understood that designs are shaped most by conceptual design processes, where the most
important decisions are made. That is, when least is being spent early in the design process,
most is being decided. The National Research Council has estimated that at least 70% of the
costs of product development, manufacture, and use are determined in the early stages of
design.16 The same rationale applies to the other human costs and benefits of the design.

A number of companies, most publicly Rolls-Royce and Ford, have conducted studies to
evaluate the expense of design changes at various points in the design process. The
overwhelming conclusion has been that the expense increases by several orders of magnitude as
a design moves through its various development stages; it is far cheaper to make changes at the
conceptual stage than during the production phase.7 As another example, systems engineering
effort is typically concentrated in the early stages of design, and the graph below indicates its
value in reducing cost overruns.15

Figure 1. Illustrating FEED in Systems Engineering

A good example of FEED is Emerson Process Management.10 They aim to provide the plan for
the project process and provide cost estimates within 10%, plus typically bringing the timeline
forward of the traditional cost–break even curve, thus saving money. They also provide the
design services, but FEED is the initial problem development process that sets the project scope,
identifies the stakeholders, and which assesses risks to, and benefits of, the project. Emerson
explicitly uses an interdisciplinary team to do this. Our use of the term FEED derives from
Emerson’s use of it, although we have changed the meaning to emphasize design more and
economics less.
In addition, Innotec14 argues that “Around 80% of the entire costs are defined in the early
planning phase of an industrial plant construction project, the so-called Front End Engineering &
Design (FEED) phase. Decisions that are made at the start of this FEED phase influence
subsequent design tasks and largely determine the usability, performance, and cost-effectiveness
of a plant or unit. These in turn have a direct effect on the safety and environmental compatibility
of the plant or unit in subsequent operation.”

3. An Approachable Process Model. The two-step FEED-Solution (F-S) design process model
is simple for students to understand, and as such, it is very likely to improve student learning. In
Figure 2, we show the F-S model for the case of market pull. Since the market is the driver of
this process, we refer to it as market driven. This is distinct from the case in which an invention
(technology push), a spin-off (from say R&D), or public policy is the driver. None of the
referenced engineering design texts teach this F-S model, few treat anything like FEED as a
coherent stage-based set of activities, none teach design validation, and few even cover design
reviews.

Figure 2. The FEED-Solution (F-S) Model of the Design Process (Market Pull)

B. Two Key Features of the FEED-Solution (F-S) Model

The F-S model is very clear about the design process having an input (the trigger), a process, and
an output (the design proposal). This is important when communicating the design to clients
and partners, as well as to instructors. Before explaining how FEED is being implemented at
Penn State, we will provide a few more details on two key features of the model, namely, the
trigger and the design validation step.

1. The Trigger. By highlighting the input to the design process as the trigger, we want to de-
emphasize the degree to which the design process is focused on simply addressing a problem and
draw attention to the variety of ways in which it can begin. None of the referenced design texts
unpack the way the design process begins with this much analysis; most simply generalize this
stage as “problem identification.” Unpacking the beginning of the process makes the next stage
of FEED easier to do, as it diffuses the rush to solutions by not assuming the situation to be a
problem in need of a fix. The trigger may not be a problem at all - it could be an opportunity or a
neat idea or an invention. It is also sometimes just someone’s “pet idea”.

Figure 3 depicts some of the variety which occurs at the onset of the design process. More focus
on the trigger might usefully lead to new research, so we can learn even more about it.

Figure 3. Triggers of the Design Process

2. Design Validation. When teaching the F-S model, we propose using a new (summer 2010)
concept of design validation for both justifying the process through design reviews, and for
justifying the design concepts being developed and ultimately being realized and used. Design
validation has a lot of advantages for making the students reflect on and justify what they do, and
this can be stressed throughout when reviewing student work. It is also important in the final
design proposal that the teams provide, as part of the output from the design process, a
justification for the design as a communication to the client and ultimately to the users. Design
process validation means using design reviews. Our model uses two formal reviews, discussed
below, one after each stage.

C. Implementing FEED
We are certain that instructors who adopt the F-S model will populate FEED in different ways.
Here, we will discuss how we are currently implementing FEED at Penn State University as an
illustration; please note that over the two years of its use, it has been modified each semester. We
begin with Team Management, in which the students form teams and establish the logistics of
communication and collaboration through the following activities:

Team Management Activities

1. Form teams: Students introduce themselves with personal information (e.g., intended major,
home town, interests, special skills), establish communication channels, and set up a
collaborative team site (using Google Apps).
2. Timeline management: Students use a tool such as a Gantt Chart to schedule the work to be
done in terms of the major tasks. This schedule will change during the project, but they are
required to get started on it as soon as possible.
3. Work breakdown structure (WBS): Students assign tasks (who will do what by when) by
adapting the Gantt chart. This structure will change as they proceed; they must document and
date changes as they occur.
4. Project risk assessment: Students are asked to assess the risks to their project, not the risks
associated with the use and disposal stages of the product being designed.
5. Design documentation (file recording and sharing plan): Students create a table for the files
and sites created, and with whom they should be shared. Specifying the sharing protocol is a
good idea in general, although it was the direct result of teaching design using Google Apps
(by the first author) where sharing has many options.
6. Progress log: Students create a Word document and enter short weekly reports describing
their progress, including: what was done; what was not done; what changes occurred and
whether the timeline and/or work breakdown structure were modified; the objectives for the
next week; and reflections on any problems, challenges, and/or opportunities - i.e., what have
they learned about the design process?

The Project Plan

Most design texts, and possibly most design educators, use a single and presumably definitive
diagram of the design process, yet none are the same. Moreover each design process is shaped
by the problem that is addressed so we should teach variability of the design process with only a
simple framework as a base, such as the F-S model or something like that of Cross who uses a
similar model based on problem and solution development but has them co-evolving.

It is not easy for students to plan a design project in their first design course, because it is
something they have never done before. And it gets harder when they realize there is no one
template that works for all design processes. Yet they must do it. The F-S model gives them a
simple framework. They may use a Gantt chart for the time line and the FEED elements may be
shown concurrently at first with a reasoned realignment occurring as they progress. Their
progress log is both a record and a means of managing iteration/problems in the process. At least
they always have a certain end date to their projects. They should further learn to anticipate
prototype testing, manufacturing and marketing, and the need to develop a mission statement that
guides the process. And thinking about the use and disposal stages is appropriate in planning

Initial Trigger Analysis and Design Characterization

After the team management activities have been initiated, students are asked to consider the
initial trigger for the design problem, which includes a draft problem statement and initial design
characterization. This problem statement will change as they work through FEED, but when
FEED is complete, they will have identified the problem or opportunity they will address in
Solution Development. This trigger analysis also includes questions about the client(s) and
stakeholder(s), for example: Where did this idea come from? With whom will the team
communicate throughout the design project, and how? What reports will be generated (e.g., early
design review, critical design review, final report)? Students are also asked to identify if the
project is an entrepreneurial activity, in which anyone on the team may be the client. A first
characterization of the design is also required here. This characterization involves the problem
statement and Design for X, where the X’s represent the thematic objectives of the design (e.g.,
sustainability, durability, maintainability, etc.) - all of which will be revisited during product
exploration.

Benchmarking and Market Assessment

In this stage, students perform benchmarking and market assessments through searches on the
web. In particular, they gather market data and technology trends for the best available products
on the market, the technologies used, and for any disruptive technologies that might erode their
market share. For architectural products, they focus on current and prospective trends, working
to identify the state-of-the-art (and what may lie at its edges) for the domain in which they are
working. They are also encouraged to establish RSS feeds that alert them to new products or
developments in the appropriate technologies, that is a tool for continuous benchmarking.

User/Customer Needs Assessment

Students must also consider the current and potential users of their designs. For example: what
are the needs and ideas of the proposed users? Are there different cultures or subcultures
involved? Students are encouraged to create surveys and to collect data from friends and family
about the design space in which they are working. They can also document user behavior - for
example, by using a flip cam to record some illustrative examples of people using (or struggling
with) related products.

Product Exploration
With an initial problem definition in mind, students are asked to explore their product
understanding through functional analysis, another iteration of Design for X considerations, risk
assessment (Design4NOTX), scenario planning and design, and by taking a systems view. A
useful tool for this exploration is mind mapping (to create a conceptual representation of the
project), which can be done collectively using free web-based collaborative tools like
Mindmeister or FreeMind.

Functional analysis is a fairly well-documented activity (see, e.g., Cross5) in which students are
asked to consider the functional requirements of the technology, as well as how those
requirements map onto user needs and behavior. In taking a systems view, students consider both
internal and external systems integration - that is, they explore the systems that will be integrated
within their design, as well as the systems into which their design may be integrated, both in use
and/or disposal. In addition, students explore whether systems and resources exist for global
supply chains and for the planning, design, testing, and manufacturing/construction/authoring of
their designs.

Next, we move to a second iteration of Design for X (D4X), now with a better understanding of
the market, the customers’ needs, and design functionality in mind; the key questions still
revolve around the main objectives for the design. The flip side of this analysis - product risk
assessment, or Design for NOT X (D4NOTX) - is also highly important; that is, students need to
consider any conceivable unintended consequences, uncertainties, and other unknowns. A good
way to do this is to review the Xs that are not salient but may be clues to hidden problems, to
make manifest that which is latent. In addition, students are asked to develop plausible scenarios
that explore how the type of product they are designing interacts and impacts the user
environment and socioeconomic context in which it is produced and used, by extrapolating from
existing trends. An analysis of the current constraints on the product and its development are
included.

Quantification and Specifications of Needs

Finally, with all of these perspectives, materials, and information gathered, students develop a
mission statement for their design effort, as well as quantifiable target product specifications.
This output serves as the input for Solution Development, which follows the Early Design
Review (see Figure 2).
We follow Ulrich and Eppinger for this stage of the design process. They state that for
technology intensive products, the specifications should be established at least twice. Target
specifications are set “immediately after identifying customer needs,” which for us is at the end
of FEED. They are reset later for the final design when a final product concept has been
selected, which will probably have a set of trade-offs that map imperfectly onto the target
specifications. [pp. 73-4] The main thrust of this stage is to convert user needs that are often
subjective and vague to metrics that allow a product to be designed with a predictable
performance and which may be manufactured.

Early & Critical Design Reviews

Design process validation means using design reviews. Our model uses two formal reviews, one
after each stage. Informally, there are many ways reviews may be triggered, such as a change of
team personnel or project resources, or the continuous benchmarking that reveals new
competition or a new advantageous technology.

Each review is of the design process, as distinct from a stage-gate review that looks at the whole
project or a review of the design proposal per se. The early design review should be a
documented team meeting in which the team reviews what has been done to date, and all reflect
on whether anything was missed or anything new requires attention. The critical design review
accomplishes the same aims for the solution development process. It is often used after a detailed
design has been completed, and this is very desirable, but, in a first design course, we want to
stress learning the design process.

Student Use of FEED

Here are the subpage listings for FEED from several teams from Spring 2010. These show a lot
of time spent on FEED with many different activities listed. They also show some variation in
topics covered, which needs to be addressed, such as a required check off list/table in the EDR.
There was also some variability in whether topics which we view as FEED here were included in
FEED on their websites or as a later menu entry. However, our view of FEED has evolved and
has several new elements (the trigger, and target specifications) and a different organization
(product exploration).

Team 1: 13 elements, no EDR but a good reflection statement for the whole project
FEED: Problem Statement, Client [null page], Mission Statement, Product Risk Assessment,
Project Risk Assessment, Market Assessment and Benchmarking, Progress Log, Stakeholders,
Timeline, WBS

Immediately followed by User Centered Design (survey), Product Dissection, Design for X, and
Weighted Objectives

Team 2: 14 elements + EDR

FEED: Problem Statement, Design the Design Process, Gantt Chart/ Work Breakdown Structure,
Market Assessment and Benchmarking, Mind Map, Mission Statement, Needs Analysis, Product
Risk Assessment, Progress Log, Stakeholders

Immediately followed by User Centered Design (survey), Organizing Objectives (mindmap),

Design for X, Product Dissection, and an Early Design Review (EDR)

Team 5: 12 elements + EDR

FEED: Problem Statement, Market Assessment, Mind Map, Mission Statement, Product Risk
Assessment, Progress Log, Project Risk Assessment, Work Breakdown Chart

Followed by: User Centered Design (survey), Product Dissection, Design for X, Objectives Tree,
and an EDR.

These are typical examples. One atypical example was a four person team that collapsed to 2
people. They overcompensated and had about 20 elements in FEED - all in one long list in the
menu, with no design reviews and an unclear solution development stage as they ran out of time.
This extreme case, which was kindly assessed, showed the need to manage time well even when
you just have two major stages, but there is no question that FEED is the longest stage in the F-S
model and in the future we will monitor time spent on each stage. FEED is also, we believe, the
stage that lower division students can do best.

In sum, this is a work in progress, but a core set of activities have emerged which constitute the
largest part of the design project for the students. It is followed by a fairly conventional solution
development stage (rdg: Chapter 5 of Ulrich & Eppinger), where they learn about innovative
design, deploy several innovative methods selected from mycoted.com, and use concept testing
with the user base. However, FEED has also provided them with a rich store of ideas, usually in
the form of design objectives.

A Limited Review of Design Texts

At this point, we will briefly review a selection of design texts and discuss how their different
approaches relate to FEED. The first author has used Ulrich & Eppinger’s Product Design &
Development21 since the late 1990s, and he currently teaches with the text and the F-S model.
The basic structure of the book has remained remarkably durable. It is roughly correct to see the
first five chapters (through Chapter Five: Product Specifications) as comparable to FEED. After
which the treatment goes to solution development in the same way. However, the F-S model is
much more focused on teaching design (prescriptive design) and less on describing design in
industry (descriptive design) than the text. So, they complement each other, and it is a very
comfortable mix. Notably, this text, like most others, does not cover formal design reviews (they
use reflection a lot). Instead, it is focused on commercial products, sees customers rather than
users, and only uses systems thinking for assessing system resources for product design and
development. Topics like D4X, life cycle assessment, and scenario planning and design are not
in its lexicon - nor in that of many other texts - but it provides a highly teachable road map for
product design and development.
In Cross’s 4th edition (2008) of Engineering Design Methods,5 he provides an interesting
comparison between descriptive and prescriptive models for design before presenting what he
calls an “integrative model” that attempts to capture the best features of both. In particular, Cross
recommends more of a “co-evolution” of problem and solution together, which - while it does
not correspond directly to FEED - does place extra emphasis on problem understanding before
solution generation begins. This perspective is then supported by five chapters devoted to
identifying opportunities, clarifying objectives, functional analysis, and performance
specifications. Although the focus on formal design reviews is not as well developed, the second
author has found this text to be very useful in the design classroom when supplemented by
additional FEED concepts.

The text that perhaps most helped to chart the path of design education in recent decades is
Engineering Design by Pahl and Beitz (translated by Wallace and Blessing).18 The original
German edition was published in 1977 and the first English edition in 1984. It has evolved
considerably in the fairly recent 3rd edition, particularly in Design for X coverage. However, its
500+ pages are almost completely dedicated to problem solving rather than to problem
development. Likewise, Dym and Little,9 who published their 3rd edition in 2009, present one
fairly solid chapter on problem development before moving directly to generating solutions
(albeit conceptual solutions to start), although they do return to discuss project management and
Design for X later in the book.

Dieter’s text8 has almost 800 pages, but only one chapter on problem development and one on
teamwork. Its approach is otherwise similar to Ulrich & Eppinger,21 as are many other U.S.
design texts. Dieter includes two good chapters on materials, which is a topic too often absent in
design texts but also found in Ogot & Kremer17, although that has very little on problem
development. Ullman22 has two chapters on problem development focused on project planning
and customer needs, rather like Dieter. Voland’s chapter on developing the problem uses
unconventional but interesting methods, such as situational analysis, Why-Why, and Duncker
diagrams.24 Pugh’s text was ground-breaking in several ways, including Design for X and his
still prescient proposal to link design to R&D.19 However, his famous interest in graphically
depicting the design process culminated in his spiral model and a 6-stage process, neither of
which go beyond market assessment for problem development.

Summary and Conclusions

The FEED model presented here has been formulated to shift greater focus onto problem
understanding and development, where some of the most important decisions are made at the
same time that process costs are lower. There are other reasons for spending extra time on
problem development as well, including the more effective use of the entire creative process and
improved return on investment. In the end, the additional effort represents time well spent, as
 developing a great solution to the “wrong” problem is just as wasteful and frustrating as failing
to solve the “right” problem from the start.

References
1. Ahmed, S., and Christensen, B. T. (2008). 'Use of analogies by novice and experienced design engineers'. Proc.
2008 ASME International Design Engineering Technical Conferences/Computers & Information in
Engineering Conference, Paper no. DETC2008/DTM-49293, New York, USA.
2. Ahmed, S., Wallace, K.M., and Blessing, L.T.M. (2003). 'Understanding the differences between how novice
and experienced designers approach design tasks'. Research in Engineering Design, 14 (1), 1-11.
3. Atman, C. J., Cardella, M. E., Turns, J., and Adams, R. S. (2005). "Comparing Freshmen and Senior
Engineering Design Processes: An In Depth Follow-up Study," Design Studies, 26(4), 325-357.
4. Aurisicchio, M., Ahmed, S., and Wallace, K. M. (2007). 'Questions as a tool to design'. Proc. 2007 ASME
Conference on Design Theory and Methodology, Las Vegas, USA.
5. Cross, N. (2008). Engineering Design Methods (4th ed.). Hoboken, NJ: John Wiley & Sons, Inc.
6. Cross, N and Clayburn Cross, A (1998) Expertise in engineering design, Research in Engineering Design Vol
10 No 3 pp 141-149.
7. Design Engineering, 13 June 2003.
8. Dieter, G. E. (2009). Engineering Design. New York: McGraw-Hill.
9. Dym, C. L. and Little, P. (2009). Engineering Design: A Project-Based Introduction (3rd ed.). Hoboken, NJ:
John Wiley & Sons, Inc.
10. Emerson, 9/25/2010 http://www2.emersonprocess.com/en-US/
11. Eris, O. (2004). Effective Inquiry for Innovative Engineering Design: From Basic Principles to Applications.
Norwell, MA: Kluwer Academic Publishers.
12. Fricke, G. (1996). “Successful individual approaches in engineering design”. Research in Engineering Design,
8, 151-165.
13. Innotec FEED, 9/25/2010, http://www.innotec.com/feed.html?&L=1.
14. Moody, J.A., Chapman, W.L., Van Voorhees, F.D., and Bahill, A. T. (1997). Metrics and Case Studies for
Evaluating Engineering Designs. New York: Prentice Hall.
15. National Research Council (1991). Improving Engineering Design: Designing for Competitive Advantage.
Washington, DC: National Academy Press.
16. Ogot, M. and Kremer, G. (2004). Engineering Design: A Practical Guide. Pittsburgh, PA: Togo Press.
17. Pahl, G., and Beitz, W. (1996). Engineering Design: A Systematic Approach. New York: Springer.
18. Pugh, S. (1991). Total Design: Integrated Methods for Successful Product Engineering. New York: Addison-
Wesley.
19. Radcliffe, D. and Lee, T.Y. (1989). Design methods used by undergraduate engineering students. Design
Studies, 10(4), 199-207.
20. Ulrich, K. T. and Eppinger, Karl T. (2008). Product Design and Development. New York: McGraw-Hill.
21. Ullman, D. G. (2003). The Mechanical Design Process. New York: McGraw-Hill.
22. Daniëlle Verstegen; Yvonne Barnard; Albert Pilot. Instructional Design by Novice Designers: Two Empirical
Studies. Journal of Interactive Learning Research; 2008; 19, 2; ProQuest Education Journals, p351.
23. Voland, G. (1999). Engineering by Design. New York: Addison-Wesley.

View publication stats