Engineering Design Process Steps

---

Why This Matters

The engineering design process isn't just a checklist—it's the fundamental framework that separates random tinkering from systematic problem-solving. You're being tested on your ability to recognize which phase of the process addresses specific challenges, why iteration matters, and how constraints shape every decision from start to finish. Understanding this process means understanding how engineers think, which is exactly what your course assessments will evaluate.

Each step builds on the previous one, but here's the key insight: the process is cyclical, not linear. Real engineering projects loop back through steps constantly as new information emerges. Don't just memorize the order—know what each step accomplishes and when you'd need to return to an earlier phase. That conceptual understanding is what separates strong exam responses from surface-level answers.

---

Problem Framing: Where Every Design Begins

Before you can solve anything, you need to understand exactly what you're solving. These initial steps establish the boundaries and possibilities for your entire project. Poor problem definition is the leading cause of failed engineering projects.

Define the Problem

• Problem statements must be specific and measurable—vague goals like "make it better" give you nothing to design toward or test against
• Constraints and criteria establish your design boundaries; constraints are non-negotiable limits, while criteria are goals you optimize for
• Stakeholder needs drive the entire process—engineering exists to solve human problems, so understanding users is foundational

Research and Gather Information

• Background research prevents reinventing the wheel—existing solutions, patents, and technical literature inform what's been tried and what works
• Data collection includes technical specifications, material properties, cost factors, and environmental conditions relevant to your problem
• Stakeholder engagement reveals requirements that aren't obvious from the problem statement alone; interviews and surveys capture real-world needs

---

Ideation: Generating and Selecting Solutions

This is where creativity meets critical thinking. You need to generate many possibilities before narrowing to one—divergent thinking followed by convergent thinking. Jumping straight to a single solution is one of the most common engineering mistakes.

Brainstorm Potential Solutions

• Quantity over quality initially—the goal is generating as many ideas as possible without filtering; judgment kills creativity in this phase
• Structured techniques like mind mapping, SCAMPER, or brainwriting help teams move beyond obvious solutions to innovative approaches
• Diverse perspectives strengthen brainstorming; different backgrounds and expertise areas produce more varied and robust solution sets

Select the Best Solution

• Decision matrices (weighted scoring) provide objective comparison by rating each solution against your criteria and constraints
• Feasibility analysis evaluates whether solutions can actually be built given your resources, timeline, and technical capabilities
• Trade-off decisions are inevitable—no solution is perfect, so selection means choosing which criteria matter most

---

Prototyping and Testing: Making Ideas Real

Ideas on paper mean nothing until they're built and tested. This phase transforms concepts into physical (or digital) reality and reveals whether your solution actually works. The prototype's purpose is to learn, not to impress.

Create a Prototype

• Prototypes are learning tools, not final products—they should be quick and cheap enough that you're willing to change or discard them
• Fidelity levels range from low (cardboard mockups, sketches) to high (functional models); match fidelity to what you need to test
• Focus on key features that address your core problem; don't waste resources on details that won't affect your testing

Test and Evaluate the Prototype

• Controlled testing isolates variables so you know why something works or fails, not just that it does
• User testing reveals usability issues that engineers often miss; real users interact with designs in unexpected ways
• Documentation of all results—including failures—creates the evidence base for your next iteration and final communication

---

Iteration and Communication: Completing the Cycle

Engineering is never "one and done." The best designs emerge from multiple cycles of refinement, and even the best solution is worthless if you can't communicate it effectively to others.

Refine and Optimize the Design

• Iteration is not failure—returning to earlier steps based on test results is exactly how the process is supposed to work
• Optimization balances competing factors like performance, cost, manufacturability, and sustainability; improving one often affects others
• Multiple cycles typically produce better results; plan for at least 2-3 iterations in any serious design project

Communicate the Final Solution

• Technical documentation includes specifications, drawings, assembly instructions, and testing data—everything someone needs to reproduce your work
• Visual communication through diagrams, CAD renderings, and physical models makes complex ideas accessible to non-technical stakeholders
• Persuasive presentation connects your solution back to the original problem and demonstrates how it meets criteria and constraints

---

Quick Reference Table

---

Self-Check Questions

1. A team builds a prototype and discovers it doesn't meet one of their key constraints. Which earlier step should they return to, and why might they need to go back even further than prototyping?

2. Compare and contrast the mindset required for brainstorming versus solution selection. Why is it problematic to combine these steps?

3. Which two steps both involve stakeholder engagement, and how does the purpose of that engagement differ between them?

4. An engineering team presents a final solution but can't explain how it addresses the original problem statement. Which steps in the process did they likely rush or skip?

5. If an FRQ describes a product that works perfectly in lab testing but fails when real users try it, which phase of the process was inadequate, and what should the team have done differently?