Engineering Design Process

The engineering design process is a series of steps that engineers follow to find a solution to a
problem.

Let’s pay attention to the highlighted parts of what defines the engineering design process:
1. it is a process;
2. Its goal is to find a solution;
3. The solution is for a specific problem.

There are several similar ways

to defining the steps in an
engineering design process.
They are similar in nature and
the process flow but differ in
how activities are referred to
as. For the one shown above,
we have Empathize,
Define, Ideate, Prototype,
and Test. I’d like to refer to each of these as a step in which several tasks/activities are
involved.

The engineering design process is a process that takes multiple steps with each step closely
related to others; and all steps are essential to reaching the goal of finding a solution to a
problem. An engineer may not be responsible for each and every one of the steps in this
process, however, in practice. For example, as a design engineer in an engineering solution
company (e.g. GoEngineer, Tomorrow-lab, etc.), you may not need to define what the problem
is since your customer will likely come to you with well-defined problems. Or once the defined
solution has been reached, the prototyping of this solution may be carried out by someone else
on the team, or a different department of the company, or even an entirely different partner
organization.

Empathize. The engineering design process typically “starts” with a step here we refer
to as “empathize”. In this step as an engineering designer you take steps to communicate with
your users (users of your solution, or those who the “problem” you are developing a solution
for is affecting). The key is to capture what pain points/issues/irritations they have within a
certain context. Note that at this point you don’t know what the problem is yet. (And very
importantly, don’t jump to the point of a thinking about a solution since we don’t know what
problem it is yet). The whole purpose of steps/activities/actions you take in this phase is for
you to be able to define the problem. In other design process models this step can also be
called “ask”, “question”, etc. As you can see though, regardless of what this step is called, the
first thing that kicks off the design process is for an engineer to understand, from the user’s
perspective”, what issues they are experiencing.

Define. Once you understand what your customer’s pain points are, or what they are
experiencing that is an issue. It’s time to use all the information and data that you’ve collected
and what the actual problem is that you are trying to solve. This is critical and can often steer
the entire project into a wrong direction. Let’s consider this example here: suppose you are
visiting your granddad at his house and he tells you that he’s had to drink water from the lab as
opposed to water from the dozens of bottles of filtered water your dad has been sending him;
and it is annoying. Now the engineer inside you wants to go into problem solving mode and
start looking into other brands of filtered bottle water that tests better, and subsequently order
a dozen for him to solve his problem. This makes sense in your mind because it’s a
straightforward and simple solution to your grandfather’s problem. But does it, really?
Let’s say for some reason you hold off on pulling out your smartphone and get on Amazon to
search for “best tasting bottled water”, you decide to as a few more questions. In that process
you discover that your grandfather has not been able to open any of his bottled water because
the arthritis in his fingers does not allow him to put enough his strength into his hand to twist
open a bottle cap without excruciating pain. At this point you realize that the engineer inside
you is actually solving a completely different problem than what you initially thought. What
you thought the problem was initially was that the bottle water did not taste good and
therefore the solution is to find another brand. However, once you have spent time actually
gather information from your grandfather (the user) through Empathize/Ask, the actual
problem is that he’s not physically able to open the bottles. It’s a relatively simple example
here, but the underlying concept/logic applies to scenarios of all complexity!

Ideate. This is the “fun” part of the process where your creativity and inner Tony Stark
gets to shine. In the ideation step you generate concepts/ideas of how you can solve the
problem identified and defined in the previous step. There are several ways or form this can
take place. There isn’t really a right or wrong way to generate ideas. The key is to produce
ideas, as many as possible, and then have a process to evaluate and eliminate those that are
not feasible. In our “grandfather’s water bottle” example, some ideas may sounds like: “a robot
that opens the water bottle for you”, “a device to reduce force required to open a water
bottle”, “a different kind of water bottle cap that is easy to open”, “a device that can extract
water from a bottle without opening it”, etc. They are all ideas, but at this stage let’s not try to
determine whether each one of them is a good idea or a bad one.

Prototype. This next step is where you translate the concept of your solution into the
solution for the first time for the purpose of testing it’s intended functions. This step here of
course will look quite different for different type of solutions/problems you are trying to solve.
For example, if the solution is a piece of software, then the prototype that gets created can be a
screen shot of the user interface of the software, or actual C++ code that does what the
software is design to do, or even just power point slides of what the software output is. In
another scenario, the prototype can be a 3D printed physical part, a machined aluminum
bracket, a mockup circuit board in a vacuum cleaner. In all cases, a prototype is produced for
the purpose of testing a functionality. It can be really any form, as long as it’s able to be used to
test for a functionality.
And of course between ideate and prototype, there can be (and in most cases there is) multiple
iterations to create prototypes based on various ideas/concepts that you came up with in the
ideation stage. It is also partially through this process you eliminate ideas that are just not
feasible. In our previous water bottle cap example, between “a robot that opens the water
bottle for you” and “a device to reduce force required to open a water bottle”, in the
prototyping stage you will probably conclude fairly quickly that between a robot and a hand-
held device there are large differences in feasibility, and lean one way versus the other.

Test. This is the step where you put your prototype to the test and see just how much Tony
Stark you have in you. Keep in mind that the testing is a specific to a functionality or an
objective. It allows you to validate your solution at the functional level. For example, in our
water bottle cap example, let’s say the device is like a clamping device with a level for the user
to use mechanical advantage to open the bottle cap. Your prototype would actually be the
device that needs to do what it’s supposed to do – allow your grandfather to open a bottle of
water without hurting the joints in his finger/hand. If the prototype device dose not do what
it’s supposed to do. For example, it does allow your granddad to open a bottle of water, but he
still needs to exert too much force and therefore cause pain in his hand. You then go back to
your prototype step and perhaps create essentially the same device, but this time with longer
lever and greater mechanical advantage. And you test again to see if that reduces the force
required, and eliminate the pain. You iterate and repeat until the test results are satisfactory
and the function of your solution is validated.
At this point, we have a functioning design. It is the beginning of a whole other sets of activities
and tasks to move into other aspect of the entire design process (for example, aesthetics,
ergonomics, cost of material, cost of production, competitions, etc.).