Engineering Design Process

The engineering design process is a series of steps that engineers follow when they are trying to solve a problem and design a solution for something; it is a methodical approach to problem solving. There is no single universally accepted design process, and most engineers have their own twist for how the process works. The process generally starts with a problem and ends with a solution, but the middle steps can vary.

One common characteristic of most design processes is that they are iterative and designers may have to go back to previous steps in the process and/or repeat the entire process over and over again until they reach a minimally viable solution.

The engineering design process outlined in this article is not the only correct version of the process, it is just one example. It should provide a good starting point for students to explore the engineering process.

A simple design process may only include a few steps as shown below.

Another design process example is Project Lead The Way's Gateway Design Process.

Steps of the Engineering Design Process

For this article, we'll consider a design process that matches what Judges look for when interviewing teams and reviewing their engineering notebooks at REC Foundation competitions.

Identify the Challenge & Set Goals

This is sometimes referred to as “Ask” or “Define.” Identifying the challenge should always be the first step that is addressed in the design process. 

For the first iteration of the design process, the team's notebook should include a very brief description of the overall game challenge and break it down into smaller challenges that must be accomplished for success. Best practice is to list questions that need to be answered through research or testing, for example:

• What is the most effective strategy for playing the game?
• What are the ways to score points?
• How fast does the robot need to move?
• How can the robot pick up the scoring objects?
• How many scoring objects does the robot need to hold?

Through this process, teams should come up with a list of features they might want in their robot, and lists of the game's requirements and constraints. For instance, if a challenge requires a robot to stack objects as high as possible, the team might decide they want their robot to be tall. However, the game manual may have a constraint on how tall the robot can be at any given time. All of these criteria should be explored and understood before moving on to the brainstorming phase.

For later cycles of the design process, this step might be to identify something on the robot that isn't working as well as expected or needed and to describe what a good solution would include. For example, a challenge might be that "The robot arm needs to be able to reach higher to score the ball," and a goal to accomplish the challenge might be "The bottom of the claw has to be able able to reach up to 16" when holding a ball." Constraints for this challenge may overlap larger constraints from the game, for example, size and vertical expansion limits.

Brainstorm & Diagram

Good brainstorming starts with a shared understanding of the problem, including all requirements and constraints. Without understanding the problem, time may be wasted on irrelevant ideas that do not satisfy the basic problem at hand. During brainstorming, it's also important to avoid judging each other’s ideas. This can stifle the creative process and discourage team members from participating.

If it becomes clear that members of the team do not fully understand the problem, the team should start over at the first step of the process (i.e., “Identify the problem” or “Ask”).

During brainstorming, students may also want to investigate challenges from the real world that are similar to the one posed by the game. They can also look to see if any other robotics competitions have utilized similar challenges in the past. Brainstorming includes gathering data from other sources to help students create a successful solution.

Promising solutions should be documented in the team's notebook, including labeled drawings or pictures. If the team gets ideas from other sources, those sources should be clearly identified in the notebook.

Choose a Solution & Make a Plan

Once brainstorming has been completed and several ideas have been generated, teams should objectively evaluate each idea. The goal is to find the best solution for the team, regardless of the source. A table might help teams consider and compare the merits of each idea in relation to specific design desires and constraints. In the example below, each criteria is evaluated on a 0-5 point scale where 0 does not meet and 5 exceeds expectations. Because “Idea 4” has the highest overall score, it would be the objective choice.

The team should document this process in the notebook, and explain how and why they choose their solution. They should also fully describe the solution in their engineering notebook, including a plan for how they'll build it. For advanced teams, this plan may include creating CAD models or detailed assembly drawings.

Build & Program

This is where teams will spend most of their time, and when prototypes and final robots and programs are created. Builds—both for code and for robots—generally start off as basic designs and evolve as details are added in later cycles of the design process. Students should take detailed notes in their notebook while building & coding, recording what they see, trying to figure out why some things work better than others, and then creating additional prototypes or programs to test new ideas. Gathering data, and recording it in the notebook, is an important part of building and coding.

Test the Solution

During this step, students will test what they've built or programmed to see what works, what doesn't, and what can be improved. Testing procedures should be well-documented in the notebook, and should include all measurable results. The main goal of this step is to decide whether the build or code meets the challenge and performs as expected and needed.

Repeat the Design Process

What happens when something doesn't work in testing? Students analyze the problem to identify the new challenge it presents, and they start a new cycle of the design process!

Not all design process cycles will need all steps, and some may jump from step to step or repeat a step multiple times before moving on to the next one. Design teams shouldn't be afraid of going backwards in the design process. The ultimate goal is to create the best design possible by improving it over and over again. Design cycles will probably overlap, too, especially between robot subsystems and code. Teams should do their best to identify which design process step(s) they're working in as they make entries in the notebook.

So how does a team decide when their robot is done?  Simple: the team needs to set a schedule, and then stick to it. This schedule will vary greatly from team to team depending on their circumstances. If a team has six weeks to design and build their robot before the first competition, they should come up with some sort of schedule for this time period. Some teams will plan out each and every step in their build process while others will just do a quick overview.

The schedule is not always set in stone; ultimately the only fixed dates are the project start date and the robot completion deadline (usually the date of a competition). Everything else is likely to shift as the process unfolds.