The engineering design process is a structured, step-by-step method that engineers use to solve problems by designing, building, and improving solutions. Unlike the scientific method, which seeks to understand how the world works, the engineering design process starts with a specific human need and ends with a working solution that meets it. The process is iterative, meaning engineers cycle back through steps as they learn what works and what doesn’t.
The Core Steps
While different organizations frame the steps slightly differently, NASA’s model captures the essential flow that most versions share:
- Identify the problem. Define exactly what needs to be solved and for whom.
- Brainstorm solutions. Generate as many possible approaches as you can without judging them yet.
- Select a design. Evaluate the options and choose the most promising one.
- Build a model or prototype. Create a physical or digital version of the design.
- Test and evaluate. Put the prototype through its paces to see if it actually solves the problem.
- Share or redesign. If the solution works, communicate it. If not, cycle back to building and testing until it does.
These steps look linear on paper, but in practice engineers move back and forth between them constantly. Test results reveal flaws that send you back to brainstorming. A prototype might expose a problem you didn’t originally identify. This looping quality is what makes the process powerful: each pass through the cycle produces a better solution than the last.
Defining the Problem With Criteria and Constraints
The first step is deceptively difficult. A vague problem leads to a vague solution, so engineers break the problem down into two categories: criteria (what the design must do) and constraints (the limits it must work within).
Consider a simple example: designing a baby gate to keep young children from climbing stairs. The criteria, or requirements, might include that the gate adjusts to fit openings of various widths, supports a child’s weight up to 30 pounds, can’t be opened by children under age 5, and allows adults to open it hands-free. These describe what success looks like.
The constraints define the boundaries. The gate might need to cost less than a certain price, weigh no more than 15 pounds, be designed within six months, and meet both U.S. and European child safety regulations. Constraints force trade-offs. A stronger gate might exceed the weight limit. A fancier locking mechanism might blow the budget. Balancing criteria against constraints is one of the most challenging parts of engineering, and it starts before anyone sketches a single design.
From Ideas to Prototypes
Once a team selects a design direction, they build a prototype to test it. Prototypes range widely in how polished they are, and choosing the right level of detail matters. A low-fidelity prototype might be a cardboard model, a rough sketch, or a basic wireframe. It’s fast and cheap, built to test a core concept rather than fine details. A high-fidelity prototype looks and behaves much closer to the final product. It has working parts, realistic materials, or functional software that responds to user actions.
Low-fidelity prototypes are useful early on because they’re disposable. If the concept is wrong, you haven’t wasted weeks of work. High-fidelity prototypes come later, when you need to test specific performance, usability, or durability. People interacting with a realistic prototype behave more naturally than they do with a rough sketch, which gives engineers better data about how the design will perform in the real world.
Testing, Feedback, and Redesign
Testing generates the information that drives improvement. Engineers run calculations, simulations, and physical tests, then use the results to adjust the emerging design. This feedback loop is the engine of the entire process. A bridge model tested in a wind tunnel might reveal unexpected vibration at certain speeds. A software prototype tested with real users might show that a menu structure confuses people. Each round of testing produces knowledge that didn’t exist before, and that knowledge reshapes the design.
This cycle doesn’t end when a product ships. Data gathered from products already in use feeds back into the next generation of designs. User feedback, field performance data, and even software updates to existing products all close the loop between real-world use and future improvement.
How It Differs From the Scientific Method
People often confuse the engineering design process with the scientific method because both involve testing and iteration. The distinction is in the goal. A scientist asks a question about how something works and designs experiments to answer it. An engineer identifies a specific need and creates something to meet it. Scientists produce knowledge; engineers produce solutions.
The starting points differ too. The scientific method begins with a question (“Why does this happen?”) and aims for a testable explanation. The engineering design process begins with a problem (“Who needs what, and why?”) and aims for a functional product, system, or environment. If your goal is to understand a phenomenon, you use the scientific method. If your goal is to invent something that solves a problem, you follow the engineering design process.
Scaling Up: The V-Model for Complex Systems
For large, complex systems like highway infrastructure or spacecraft, the basic design process gets expanded into something called the V-model. Imagine the letter V. On the left side, you move downward from a broad user-level view of the system to increasingly detailed specifications. The whole system gets broken into subsystems, and those subsystems get broken into individual components. At each level, the requirements become more specific.
At the bottom of the V, the actual hardware and software get built. Then on the right side, you move upward, integrating the components back together and verifying at each level that they meet the requirements defined on the corresponding left side. The final step at the top right is validation: measuring whether the completed system actually meets the user’s original needs. The V-model ensures that every piece of a complex system traces back to a real requirement and gets tested against it.
Anticipating Failure Before It Happens
Engineers don’t just test what works. They systematically think about what could go wrong. One common technique examines every individual component of a system to identify the different ways it could fail and what each failure would mean for the whole system. Teams score each potential failure on three scales: how severe the consequences would be, how frequently it’s likely to happen, and how easy it is to detect before it causes harm. Multiplying those three scores produces a risk priority number that tells engineers where to focus their improvement efforts first.
This kind of structured failure analysis is used across industries, from manufacturing to healthcare, because it catches problems that intuition alone would miss. A component that fails rarely but catastrophically might rank higher than one that fails often but harmlessly.
Why Documentation Matters
Throughout the entire process, engineers maintain detailed records in a design notebook. This isn’t optional housekeeping. An engineering notebook is considered a legal document that can serve as proof of invention for patent claims. Every entry is dated, written in ink (for paper notebooks), and recorded in a bound volume where pages can’t be added or removed. Engineers are expected to record directly in the notebook rather than copying notes from elsewhere later.
A well-kept notebook contains sketches and drawings, design requirements and constraints, interview notes, meeting notes, contact information for relevant professionals, and questions or concerns about the project. It’s a chronological record of every decision and discovery, which means anyone can retrace the team’s reasoning months or years later. For digital notebooks, engineers embed links, videos, and documents directly, often with password protection to preserve the integrity of the record.