Poll: How much does your team use the Engineering Design Process?

I’m working at trying to convince my team to increase the amount we are using the engineering design process when building our robots so I was wondering how much other teams use this process.

  • All the time
  • A lot
  • A little bit
  • Sometimes
  • Once in a while
  • Never

0 voters

Which one?


Can you define * the * engineering process?


Are you talking about this one (only because this is the one always shown to PLTW classes)? I feel like this mostly comes naturally in most seasons just with the nature of FRC.


I marked “all the time” since we use an engineering process all the time. It’s not entirely the same as the engineering design processes I use as work or that I learned in college; every mentor came in with a different understanding of “the engineering design process”, so it’s been a few years of melding them together & adapting it to our team’s specific needs. Agree with the other posters, I would love to hear what engineering design process you have in mind (unless the question was more general, “do you use a defined process” vs just winging it?)



1 Like

I’m trying to get a sense of how many teams like use the process and actually follow it like the way it’s intended.

1 Like

Fairly often we switch steps 3 & 4 – that is we develop prototype(s) before (fully) developing a solution.


the trick to the EDP is whenever you don’t think you’re doing the EDP, you’re doing the EDP.


I’ll be completely honest – I think this question is rather pointless. The engineering design process describes a general set of steps to solve a problem, but I’d say every team (and everyone trying to build anything in general) figures out what problem they want to solve, brainstorms ideas, builds and tests the idea, and iterates on it. The amount of time spent on each step varies, but that’s the general flow of … building anything really.


When I work (with students or not), I follow a process that resembles:

  1. Develop requirements
  2. Physical prototyping to understand the problem requirements
  3. If not confident in understanding of the problem, GOTO 1.
  4. Design solution
  5. Virtual evaluation of solution
  6. Physical production of solution
  7. Evaluate solution
  8. Requirements not met? GOTO 4.
  9. Erratic behavior detected? GOTO 1.

You notice that there’s clearly two stages … And they’re nebulous. Flexibility is important

Instructions unclear

  1. Built an awesome robot
  2. Made CAD drawings
  3. Read the rules
  4. Rebuild
  5. Developed requirements
  6. Rebuild
  7. Install code
  8. Copy 148

Seems pretty straight forward


… Alot alot…


(Pardon the broken links we moved from old google sites to new google sites and I haven’t had the time to fix everything yet)


I see. I think you may be too hung up on the particular process represented by that diagram and “the way it’s intended to be used”. Engineering practices aren’t handed down by God, they’re just methods that some engineers found useful enough to write down. If you opened ten intro to engineering textbooks they’d probably all describe slightly different steps… there’s nothing more valid about your diagram than, say, one that puts brainstorming before research.

Agreeing with heatblast016, I think pretty much every team follows a workflow of understanding the challenge, brainstorming, building, testing, and iterating. For some teams this looks like building ten different shooter prototypes, testing them, and then selecting a design; for some teams it looks like choosing one shooter design concept and iterating prototypes until it’s good enough to slap on the robot; for some teams it looks like CADing up the whole robot, machining & building it, testing it, and then making improvements on the comp bot directly until the end of the season. These are all valid engineering design processes, each with their own strengths and weaknesses.

What I’m trying to get at is that if you’re unhappy with your team’s particular process, an appeal to authority (“this is how it’s supposed to be done” or “this is how 77% of people on CD do it”) isn’t going to be effective. You need to figure out why your team doesn’t want to do it your way, and address their concerns. You haven’t said what part of your process your team doesn’t like doing, but as some examples - maybe they don’t want to iterate because by the time the robot is built they’re all exhausted and stressed out and just want to take a break until competition. Maybe they don’t want to test because they don’t really understand how to do it rigorously enough to be useful. Maybe they don’t want to do research before brainstorming because to them, brainstorming from a blank slate is more fun than just looking up how 254 shot balls in 2016. Maybe they’re following a pretty rigorous and well-thought-out process already, and you’re mistaken in thinking that following that particular diagram exactly would be an improvement. These are just some hypotheticals, but the point is, approach this problem on your team the same way you would an engineering problem, and start by understanding the problem.


Absolutely agree. This was just one example of an engineering design process. If I spent time investing into each and every single different engineering design process, I would never be able to get through them all.

I’m aware of some of my team’s weaknesses within the engineering design process and I’m working on fixing them internally. So far, my plan on developing multiple trainings and teaching younger passionate students has been quite effective and I will continue to move forward with this. Even though I’m working on the Game Design Challenge, I have a role as a media lead, and I’m still a programmer for my team, this is my most important project for this year by far.

I set this poll up for two reasons:

  1. I was just curious to the extent to which other teams follow/don’t follow the engineering design process
  2. By setting up a poll like this, it makes other people think about the engineering design process and hopefully if another team isn’t the best at following the engineering design process, it gets them to think more about it
1 Like

Absolutely, I don’t think it’s necessary to investigate every possible engineering design process. But it may be hard to get meaningful results from your survey, if you’re just asking how many teams use one particular version of the process - there are probably tons of teams who use a very similar process, but not that exact one.

On my team (and in my job), I like to do as much brainstorming as I can before I start researching - once you see an example of how one team or company did something, it can occupy a lot of space in your mind and make it harder to think of other possibilities. So usually we do a long session of brainstorming, then send everyone home to start doing research, and do some more brainstorming at the next meeting feeding off any ideas they found in their research (rather than just research -> brainstorming).

I also feel like there’s a key step missing from the diagram you posted - the decision step. In brainstorming you come up with lots of design concepts, and eventually you need to narrow it down to one. Sometimes you narrow it all the way down to one concept right after brainstorming. Other times you carry 6 or 7 concepts all the way through the steps, iterating prototypes of all of them, and don’t make the decision of which one to launch until you’ve gotten all of them working pretty well. A lot of times it’s somewhere in between. I’ve seen my team’s designs improve greatly as we’ve shifted from “design the whole robot, then build it, and hope it works” to a process of building lots of prototypes first, so I think where you put “make a decision” in you process has a much bigger impact than whether you follow all the other steps exactly as the diagram shows.

I also consider some of our decision-making processes a crucial part of our team’s engineering design process. We use weighted decision matrices religiously, and have been working on incorporating FMEAs as well. These types of tools are less big-picture than what your diagram is trying to capture, but can be extremely impactful.

I guess what I’m trying to get at is that you’re still talking about the extent to which teams follow THE engineering process (which I take to mean YOUR engineering process), but there are lots of variations that are just as valid and useful for creating successful designs.

It would probably not be too difficult to find a bunch of teams that “follow the same Engineering Design Process” yet get very different results. One of the factors that affects the quality of the end result is the quality of the implementation of the EDP. For instance, I have seen teams test a shooter and are satisfied when they can get the ball in the goal once, under ideal conditions, whereas other teams will measure the percentage of the shots that go in the goal over a statistically significant number of trials from different positions.



Y’all are protoyping stuff?



At work, our engineering design process looks like:

  1. Scientists give us a problem
  2. Tell the scientists the technology doesn’t exist yet
  3. Scientists complain for a while and then give us a slightly easier problem
  4. Design the spacecraft
  5. Define requirements
  6. Redesign the spacecraft
  7. Ask Congress for money
  8. Congress gives us less money than we asked for
  9. Reduce the requirements
  10. Redesign the spacecraft
  11. Cut contracts to build the instruments
  12. Find a critical problem in your mission profile
  13. Redesign the spacecraft
  14. Find out that someone in the building next door accidentally found a solution to the critical problem 5 years ago while working on something completely different
  15. Un-redesign the spacecraft
  16. Instruments are overweight
  17. Redesign the spacecraft
  18. Begin I&T campaign
  19. Instruments are late
  20. Start working 3 shifts to make up schedule
  21. ???
  22. Launch