Design Approaches

This page contains a compilation of product development approaches. This work has been described in the following publications:

  1. Vance, J., Giambalvo, J., and Hoffenson, S. (2017), “Navigating the common approaches to product development,” 21st International Conference on Engineering Design, Vancouver, Canada, 21-25 August.
  2. Giambalvo, J., Vance, J., and Hoffenson, S. (2017), “Toward a decision support tool for selecting engineering design methodologies,” ASEE Annual Conference & Exposition, Columbus, Ohio, 25-28 June.
  3. Stewart, S., Giambalvo, J., Vance, J., Faludi, J., and Hoffenson, S. (2020). "A Product Development Approach Advisor for Navigating Common Design Methods, Processes, and Environments," Designs, Vol. 4, No. 1, Paper no. 4.

In the first paper (though it was presented later than the second, the original submission was months earlier), we reviewed the common approaches to design and selected fourteen that appeared to be the most relevant, identified key distinguishing criteria among the approaches, and developed a visualization framework for navigating these design approaches. In the second paper, we developed a decision support tool for helping people decide which approach is best for their product development needs. The third paper discusses the refined development and validation of this decision support system. This decision support tool is online at

Engineering Design

Engineering design is one of the most commonly taught mechanical engineering design methodologies, especially within the academic domain (Dominick et al., 2001). There are many different representations of the engineering design process, and in its simplest form it can be represented by the iterative “design-build-test” cycle. This process was developed in order to provide a structured and easily-replicable method to solving a large variety of engineering problems. Although variations in definition exist, similar core phases typically exist in a more detailed engineering design method, such as the one shown below: need identification, research, synthesis of alternatives, analysis, assembly, testing, communication of results, and redesign (Massachusetts Dept. of Education, 2006). Furthermore, this approach is highly iterative, and in many instances, certain phases are required to be repeated multiple times before they are deemed to be complete. This particular approach can be applied to a large variety of engineering projects. However, because of its universal nature, it is not always the best approach for many specialized projects.

Engineering design process (Massachusetts Dept. of Education, 2006)

Design Thinking

Design thinking is a problem-solving environment that was developed primarily by Stanford University’s Institute of Design and IDEO during the early 1990s in an effort to highlight the human element that is present within design (Brown & Wyatt, 2010). This environment was developed based on an analysis of how products are practically used and the waste that occurs as a result of over-designing. The general approach decomposes the design process into three high-level phases: “inspiration”, which involves problem identification, “ideation”, which involves the generation of broad solutions, and “implementation”, in which a product is manufactured and released (Brown, 2009). Furthermore, design thinking suggests that the thought process that occurs during a design process is split between “divergent" and "convergent” thinking during concept generation and selection and “analysis" and "synthesis” during human pattern recognition. This environment adds value by incorporating an emotional element to design, and thus generates a product that is more favorable to consumers and less wasteful. However, design thinking is limited as it is relatively open-ended in scope and provides a relatively small amount of guidance to users.

Design thinking framework (Hildenbrand & Wiele, 2013)

Decision-Based Design

Decision-based design (DBD) is a relatively recent approach that focuses on the human decision making process and how it applies to the design process. This perspective was introduced by Hazelrigg in 1998, and it is taught with an emphasis on considering customer preferences and the business case when making design decisions (Wassenaar & Chen, 2003). Furthermore, this approach highlights the necessity of conducting consistent economic modeling at each decision point throughout a design process (Hazelrigg, 1998). This perspective considers profit as the main driving factor for any development project, and therefore any decision made at any point in the design process must consider the relative impact on total profit. The advantages of DBD are its quantitative approach to customer satisfaction and added business value during product development; however, it has not caught on widely in industry due to its multi-disciplinary nature and difficulties in practical implementation.

Decision-based design framework (Wassenaar & Chen, 2003)

Systems Thinking

Systems thinking is a design environment that was originally developed at MIT in 1956 and has since been expanded upon by a variety of academic and industry figures (Checkland, 1981). Much like design thinking, systems thinking encourages designers to approach a given problem from a holistic perspective. This approach was promoted as a means for designers to frame a project from a perspective that mainly considers the interactions of the given product with other outside systems, such as the environment and peripheral attachments. Unlike the typical design process ideology, which primarily analyzes the individual constituents of a product, systems thinking encourages the analysis of the product from an expanded viewpoint to the primary and secondary systems affected by it. This environment thus aids in decision making for complex projects that contain multiple actors, or for projects which failed to be effectively solved via traditional methodologies. Like design thinking, systems thinking offers little guidance, and therefore it is less suitable when applied to simpler, more established project scenarios.

Systems thinking continuum (Stave & Hopper, 2007)

Axiomatic Design

Axiomatic design is a systems engineering methodology that is taught to help designers understand how customer needs are properly transformed into functional requirements. This approach is commonly followed using matrix mathematics. Overall, the process follows entities that are contained within four design domains: customer, functional, physical, and process (Martin & Kar, 2002). These four domains are intrinsically connected, as any consideration made in one domain directly maps to the following domain. This mapping occurs in practice via matrix mathematics between design parameters and functional requirements, and it can be performed for projects of varying scope (Suh, 2001). Due to the calculated nature of this approach, it provides absolute responses, and thus is useful for eliminating unnecessary design considerations.

Axiomatic Design (Suh, 2001)

"Vee" Model

The "Vee" model is a commonly taught systems engineering approach for the design of complex products. This approach was first introduced by the German and U.S. militaries in the 1980s, and has since been adopted for use in commercial and academic applications (Forsberg & Mooz, 1991). The model is depicted as having two separate prongs, which can be referred to as the “decomposition and definition” stream and the “integration and verification” stream. This approach is comprised of a variety of phases which include: defining user requirements, generating system concepts and validation plans, developing performance specifications and verification plans, subsystem and component decomposition, subsystem assembly and verification, system validation, and system operation and maintenance planning. Although the Vee model was not developed to be entirely iterative, each of the steps present within the decomposition and definition stream need to cross-verify or validate against corresponding steps in the integration and verification stream before the process is considered complete. The high level of consideration of decomposition and verification within this approach makes it most suitable for projects with multiple sub-teams and high complexity.

Systems engineering "Vee" model (Esfahbod, 2013)

Value-Driven Design

Value-driven design (VDD) is a design approach that was created by the American Institute for Aeronautics (AIAA) that centers on the value of a project and its components (Collopy, 2001). As it is taught, this perspective aims to optimize the attributes of a system to achieve the highest possible value to stakeholders. Generally, this approach considers mainly the objective functions of a system in a mathematical analysis, which typically contains fewer parameters and dimensioning than design functions. The application of design functions in such an analysis would likely over-complicate the result, leading to poor correlation between design objectives and an optimized final product. This simplified approach does yield a single “score” to an analyzed design, and thus proves useful within some industrial applications. There are drawbacks to using this approach, however, as the omission of performance requirements within this model may lead to an incomplete design.

Value-driven design process (Van Tyne, 2016)

Waterfall Model

Perhaps the most simplistic design formalism is the waterfall model, which is frequently applied to software development. This process was introduced by Royce in 1970, and it was defined as having six or seven sequential phases, as shown below, beginning with the establishment of requirements and culminating in an operations plan (Royce, 1970). Although the waterfall model has evolved in the past few decades, the original phased decomposition remains as the main framework to the process. Due to the well-defined nature of this process and its ease of implementation with clear-cut milestones, it has often been used within the industry. However, the application of this approach could prove disadvantageous, as it does not prescribe any feedback loops and encourages compartmentalized design, thereby supporting little to no iteration throughout the development process.

Waterfall approach (Feher, 2013)

Spiral Model

The spiral model is another highly iterative systems design approach, and it was first developed by Boehm, a software engineer, in 1986 (Boehm, 1988). This approach shares similarities with the waterfall model, and both are extremely common in software engineering applications. The spiral model differs from the other approaches, however, as risk is the main driving consideration for design decisions. This model is applied through a series of iterative stages, and the development process can be altered or stopped completely as a result of a risk assessment at any point in the process. Though it is possible to implement this type of frequent assessment of risk with many of the other methods, the spiral model is the only approach that explicitly requires risk assessment through a series of iterative loops. Even though this consideration of risk can help to ensure a more complete project delivery, it may lead to additional delays throughout the development process.

Spiral model (Boehm, 1988)

Agile Development

Agile development is an approach introduced in 1999 by a team of software engineers in an effort to create a lightweight development methodology for rapid development and deployment (Reich et al., 1999). It has since been enhanced by a variety of developers, but maintains the same main four values in the design process: continuous collaboration, consistent delivery of working prototypes, sufficient collaboration with customers, and timely response to change or challenges (Cohen et al., 2003). This approach encourages a flexible and iterative design process, in order to allow for adaptability at points in which a decision is to be made. Furthermore, unlike other processes, agile design promotes integrated testing throughout the development phase, as opposed to the traditional method of performing testing separately. Agile design proves to be beneficial in fast-paced industries as it allows for quick creation or alteration of a project. This approach does have drawbacks, however, as it has limited application to projects that are complex in scope.

Agile development cycle (Feher, 2013)

Total Quality Management

Total quality management (TQM) is a management environment for product development, which was initially developed in the late 1970s in the United States in an effort to match the high level of quality production by Japanese manufacturing (Porter & Parker, 1993). This mindset was adapted and formalized by the U.S. Navy in 1984, and later developed by various national and international standard-setting organizations. Overall, this approach aims to improve customer satisfaction through constant enhancement of the way in which design and manufacturing processes are managed. In order for this approach to be fully effective, a solidified design process and/or manufacturing plan for a given project must be established, to which improvements are made. Furthermore, all actors present in an organization, ranging from designers to manufacturers to managers, are expected to adopt this mindset in order to achieve full effectiveness. This high-level approach has been further expanded upon and adapted into more detail-oriented design approaches, such as six sigma and lean manufacturing.

Total Quality Management (TQM) framework (Zekry, 2013)

Theory of Constraints

The theory of constraints (ToC) was developed by Goldratt, a business analyst, in 1984, and it is taught as a management perspective which focuses on the identification of a single limiting factor in a design or production process (Perez, 1997). Following this identification, a scientific approach is followed to alter each particular process in an effort to either improve or eliminate this constraint (Goldratt, 1999). The approach is designed to be iterative, as new constraints are prone to arise throughout the duration of a design or manufacturing process. This perspective can be applied to a variety of projects of differing scopes, as each is bound to contain an ineffective element. ToC does have its limitations, however, as its application is most effective when a top-level constraint can be identified, which is often a difficult task in practice.

Theory of constraints steps (Vorne Industries Inc., 2017)

Six Sigma

Six sigma is a methodical approach to manufacturing that aims to optimize the quality of the product of manufacturing processes. Six sigma was introduced by engineers at Motorola in 1985, and has since been adopted by a number of large corporations (Linderman et al., 2003). This approach is taught with a main emphasis on reducing the variability present within a manufacturing process, which helps to remove causes of product defects (Harry, 1998). Additionally, this perspective is applied to a particular company’s employee base to ensure the proper assignment of personnel. The application of six sigma adds value to a company by reducing the waste that is produced during manufacturing. Some limitations exist, however, as this ideology is most effective when applied to a fully developed manufacturing methodology.

Six sigma process (Wesleyan College, 2017)

Lean Manufacturing

Lean manufacturing is an approach to design of manufacturing methods that values the elimination of waste within assembly processes. This perspective was developed from the Toyota Production System (TPS) in the early 1990s, and it is still widely implemented in industry (Bangert, 2016). This approach proves useful for industrial applications, as it encourages the development of more efficient processes that produce the same (or better) results as existing methods (Shah, 2003). Thus, the approach is centered on the identification of the most and least valuable elements of a particular manufacturing process, in an effort to cut costs wherever possible. Benefits to using this approach include enhanced customer relations and lowered overall manufacturing costs. Much like six sigma, this approach is also limited, as it works best when applied to processes that are fully defined and already nearing completion.

Lean innovation model (Lean Analytics Association, 2017)


Scrum is a software development life cycle method rooted in agile principles. Developed in the late 1900s in response to a need for greater software development productivity, and named after the rugby formation, this method focuses on managing product development through incremental product deliveries (Pham, 2011). Development is broken down into iterative “sprints” that focus on taking a small group of tasks from definition to potentially deliverable product in a short period of time (Bhuvaneswari & Prabaharan, 2013). The scrum methodology consists of multiple sprints in which new work is selected from the product backlog until product development is complete. Scrum does not prescribe specific technical practices for completion of work within a sprint, but rather a set of managerial practices that enhance the efficiency of the method. Following the basis of its agile principles, this method is most effective with a small, unified team but is beneficial in its adaptability to changing requirements through constant feedback between sprints (Arora & Arora, 2016).

Scrum development model (Ciecholewski, 2016)

Extreme Programming

Extreme programming (XP) is a software development method that, similar to scrum, focuses on the delivery of small increments of functionality (Munassar & Govardhan, 2010). Extreme Programming typically follows agile principles, and extends them by prescribing technical practices. Such practices include, but are not limited to: continuous code improvement, user involvement, task prioritization, and Test Driven Development (Munassar & Govardhan, 2010). The implementation of specific practices classifies Extreme Programming as a design method by helping designers determine how they will perform design tasks, while still allowing for flexibility and changing design requirements (Beck & Andres, 2004). The focus on practices in extreme programming may cause challenges in its implementation. Without familiarity with the fundamental principles of extreme programming practices, this method may lead to incomplete or inefficient design.

Extreme Programming (Wells, 2013)


  1. Arora, R., & Arora, N., “Analysis of SDLC Models”, International Journal of Current Engineering and Technology, Vol.6, No.1, 2016, pp. 268-272.
  2. Bangert, M., “Respect Your People”, Quality, Vol. 55, No 13, 2016, pp. 36.
  3. Beck, K. and Andres, C., Extreme Programming Explained: Embrace Change (2nd Edition), Addison-Wesley Professional, Boston, 2004.
  4. Boehm, B.W., “A spiral model of software development and enhancement”, Computer, Vol. 21, No. 5, 1988, pp. 61-72.
  5. Brown, T., Change By Design, HarperCollins, New York, 2009.
  6. Brown, T. and J. Wyatt, “Design Thinking for Social Innovation”, Development Outreach, Vol. 12, No. 1, 2010, pp. 29-43.
  7. Bhuvaneswari, T., & Prabaharan, S., “A Survey on Software Development Life Cycle Models”, International Journal of Computer Science and Mobile Computing, Vol. 2, No. 5, 2013, pp. 262-267.
  8. Checkland, P., Systems Thinking. Systems Practice, Wiley, Chichester, NY, 1981.
  9. Ciecholewski, J., "How to set up dual-track scrum in Jira", Devbridge Group, 2016,
  10. Cohen, D., M. Lindvall, and P. Costa, “Agile software development”, DACS SOAR Report, Vol. 11, 2003.
  11. Collopy, P., “Economic-Based Distributed Optimal Design”, AIAA Space 2001 Conference and Exposition, AIAA, Albuquerque, NM, 2001.
  12. Dominick, P.G., J.T. Demel, W.M. Lawbaugh, R.J. Freuler, G.L. Kinzel and E. Fromm, Tools and tactics of design. Wiley, New York, 2001, pp. 14-35.
  13. Esfahbod, B. “Vee model for systems engineering process”. [online] Wikimedia Commons. 2013.
  14. Feher, D., "What are the pros and cons of the waterfall and agile/scrum project management approach?", Quora, 2013,
  15. Forsberg, K. and H. Mooz, “The relationship of system engineering to the project cycle”, INCOSE International Symposium, Vol. 1, No. 1, 1991, pp. 57-65.
  16. Goldratt, E.M., Theory of Constraints, North River Press, Great Barrington, MA, 1999.
  17. Harry, M. J., “Six sigma: A breakthrough strategy for profitability”, Quality Progress, Vol 31, No.5, 1998, pp. 60-64.
  18. Hazelrigg, G.A., “A framework for decision-based engineering design”, Journal of Mechanical Design, Vol. 120, No. 4, 1998, pp. 653-658.
  19. Hildenbrand, T. and C. Wiele, The road to innovation: Design thinking and lean development at SAP, 2013,
  20. Lean Analytics Association, "Best practices discovery project 2015", retrieved 2017 from
  21. Linderman, K., R. Schroeder, S. Zaheer and A.S. Choo, “Six Sigma: a goal-theoretic perspective”, Journal of Operations Management, Vol. 21, 2003, pp. 193-203.
  22. Martin, S.G. and A.K. Kar, “Axiomatic design for the development of enterprise level e-commerce strategies”, International Conference on Axiomatic Design, Cambridge, MA, June 10-11, 2002, Massachusetts Institute of Technology, Cambridge, USA, pp. 10-11.
  23. Massachusetts Department of Education, Massachusetts Science and Technology/Engineering Curriculum Framework., Massachusetts Department of Education, Malden, MA, 2006.
  24. Munassar, N. and Govardhan, A., “A Comparison Between Five Models Of Software Engineering”, International Journal of Computer Science Issues, Vol. 7, No. 5, 2010, pp. 94-101.
  25. Perez, J., “ToC for world class global supply chain management”, Computers and Industrial Engineering, Vol. 33, 1997, pp. 289-293.
  26. Pham A., Scrum in Action: Agile Software Project Management and Development, Cengage Learning, Boston, 2011.
  27. Porter, L. J. and A. J. Parker, “Total quality management—the critical success factors”, Total Quality Management, Vol. 4, No. 1, 1993, pp. 13–22.
  28. Reich, Y., S. Konda, E. Subrahmanian, D. Cunningham, A. Dutoit, R. Patrick, M. Thomas and A.W. Westerberg, “Building Agility for Developing Agile Design Information Systems”, Research in Engineering Design, Vol 11, No. 2, 1999, pp. 67-83.
  29. Royce, W.W., “Managing the development of large software systems”, IEEE WESCON, Vol. 26, No. 8, 1970, pp. 328-338.
  30. Shah, R., “Lean manufacturing: context, practice bundles, and performance”, Journal of Operations Management, Vol. 21, No.2, 2003, pp. 129–149.
  31. Stave, K. and M. Hopper, "What constitutes systems thinking? A proposed taxonomy", In Proceedings of the 25th International Conference of the System Dynamics Society, 2007.
  32. Suh, N.P., Axiomatic Design: Advances and Application, Oxford University Press, New York, 2001.
  33. Van Tyne, S., "Value-driven design to value-centered design", 2016,
  34. Vorne Industries Inc., "What is the theory of constraints?", retrieved 2017 from
  35. Wassenaar, H.J. and W. Chen, “An approach to decision-based design with discrete choice analysis for demand modeling”, Journal of Mechanical Design, Vol. 125 No. 3, 2003, pp. 490-497.
  36. Wells, D., "Extreme Programming: A gentle introduction", 2013, retrieved 2018 from
  37. Wesleyan College, "Six Sigma at Wesleyan", retrieved 2017 from
  38. Zekry, W., "Total Quality Management (Part 3)", 2013,