Design Process

This week, we talk about the design process and relate it to professional work

Creators and Guests

Producer

Michael Crocco

Engineer and Educator. AI in Engineering innovator.

What is Ctrl+Alt+Engineer?

A podcast for mechanical engineers beginning their studies in Design.

[MUSIC PLAYING]

Hi, everyone.

Welcome back.

I'm Kathy Kekoff.

I'm a mechanical engineer,
predominantly out

of the defense industry.

My background is in testing,
in particular

for things like the F-111 and the F-18.

I'm joined today by--

Michael Crocco.

Hi, everybody.

I'm also a mechanical engineer.

At least I spent a lot of
time doing that.

And now I work in education.

Yeah.

Which is where we both kind of met
and brought this together.

This is episode two of our podcast
on mechanical design,

I guess, is a general topic.

And we haven't named it yet.

So you'll probably see titles
on this one.

But this is the first time.

It's coming.

It's getting there.

There's a lot happening at the moment.

But we thought we'd take the time to
come and talk to you today

about the design process.

So we wanted to talk to begin
with sort of what is it?

Because most people think that
design just sort

of happens.

And that's a falsehood.

That is complete and utter junk.

As an engineer, you usually have to
sit down and think about it.

And it takes some time.

So Mike, do you want to talk me through
what kind of design

process you've used?

Sure.

I mean, I know we teach a design
process here in Design 1

and a number of different units
at the university.

It is-- it's like a microcosm of design,

I guess is one way to put it.

It's not truncated.

Well, it is truncated.

But it's also abridged, I suppose,
compared to industry.

So in industry, I guess, just
to give everybody

a forewarning of what it's like, Kathy
and I were talking earlier

about when I was working at Honda,

the ideation phase, for example,
was many, many months long

and involved a lot of people and
a lot of actual issuing

of drawings and approvals
and the rest of it.

And Bedford's enforcing.

But ideation isn't just you sit down

and you think about it for a minute.

There's a whole range of things that

happen in and around ideation.

So it's that ideation phase.

But what we're talking about is
that that ideation phase

is where the ideas for the
design are laid down,

so where that problem's really explored.

We did, for example, many, many
months, sometimes years,

of just research into different areas

that might be applied on
a vehicle later on.

And so then we had a foundation of we've

done all this research into could
this work on this platform

and what's optimal and that
kind of thing.

And so you've got all this
feeder information.

At university, obviously, you've
got 12 weeks, if that,

possibly 9 or 10 realistically
to initiate and complete

a design.

And so it's very different.

But you still come up with ideas.

You still compete those ideas.

You still use the other people in
your group or colleagues

or whatever it is to compare.

You should still do some modeling.

You should still do some calculation.

This is something that's
sometimes missing.

But it's a really important part of this.

I like to say something around
the lines of every change

relates to a decision.

And I don't know if everybody's
necessarily

making a conscious decision every time

that they choose a design direction,

set up a specification or things that

seem like inconsequential decisions.

They should be meaningful decisions

based on engineering logic as opposed
to emotive or intuitive.

It's the first idea we came up with
or the loudest person

in the group said it.

But that's all OK, I would say.

People are going to make these mistakes
and feel that out.

But part of the purpose of this
podcast, I think,

is to explain, to relate one's
university experience

and think forward to what you're
going to do in industry.

Absolutely.

And that was one of the biggest
drivers of this

was that we try really, really
hard as educators

to bring as much authenticity
into our classes

as we can possibly bring.

But it's still not going to be authentic
because the time--

it's literally a very, very, very tight,
short turnaround time.

Yes, you might be taking four
or five classes.

They might take you between four
and six hours of contact

a week.

Most universities would say you have

to take what you're spending in class,

double it outside of class time to
be putting enough effort

and energy into what you're
trying to learn.

But that's still kind of false because
these things become

people's entire jobs.

So you might have different platforms

or you might have different parts

of that particular platform that you're
working on at any one

time, but you spend hours and hours

thinking about these things.

I think back to my first design
job at a university,

again, to relate to my Honda experience.

And that whole design process was
completely alien to me,

to be honest.

I had never had any real forecast.

During my university time, we'd
done design projects,

but I didn't really know what that
was going to look like.

And we just kind of hit the ground

and were expected to run.

And I'll be honest, it was
very difficult to do.

So yes, again, to explain
the purpose of this,

I think it would have been great
at that time for me

to have some forewarning, really,
and some forecasting

of what was to come.

Absolutely.

And even for myself, I went to--

I'm a graduate of Swinburne University

here in Melbourne, Australia, which

is where we're coming to you from.

We're not coming here to
you from Swinburne,

but I am a Swinburne graduate.

We're coming to you from
Monash University.

But during my design units--

and I did--

I think I did three or four design units

across my degree, a five-year degree.

Nobody talked to us about
the design process.

Nobody talked about, where do you start?

What do you have to think about?

What actually is design?

What is the basis of this?

And this is why I like to talk
about design process.

And this is why I like to give my
students a design process.

So we touched on ideation.

And I know that you'll cover
this in class

and that kind of thing.

But what do we want to look at in
terms of the other phases

and relate those, maybe draw some
comparisons between what

is done in the classroom
and what's actually

expected in the industry?

So the first stage, like we said,
we'd start to ideate.

And in the next stage--

yeah, I know.

Look at me that way.

In the next phase, what you start to do

is that that's when you start to
think about you really

pulling that problem apart.

So what are the parts of that problem?

What are the specifications
and requirements

that you need to make this happen?

So what is the problem telling you?

Because a lot of times, you're given
an ill-defined problem.

You might be given a half-baked
conversation.

You might have two sentences in an email.

It might be a three-page email that
only has two sentences that

are actually relevant.

Or you have people who don't really

know what they're looking
for, telling you

this is what they want, when in actual
fact, they don't know

what they want necessarily.

Interesting thing I'd add there.

Yes, it is true.

You'll encounter a lot of
open-ended things,

poorly specified design problems.

But also, you might encounter
very overly defined,

very constrained.

And often, a lot of graduates
find themselves

in that position where they have a
very, very clear directive.

I think that what's offered generally,

I think at university, is somewhere
in between.

It's not open-ended as much as it's

choose your own adventure sometimes
and use a path.

But it's also not generally
strained to the point

where there's only one clear solution,
which is actually

what you might find working your
first job in industry,

not universally.

But I think that's somewhat common.

Yeah.

And I mean, one of the standards
that I was really

familiar with as an undergrad, one
of the things that I did

was that we did an environmental
test program for an FA-18

and an F-111.

And the F-111 in particular had to comply

to a particular military standard.

And this thing was absolutely rigid.

This is how rain will be developed.

So it gave you, this is what
it has to be tested to.

This is what you have to make.

This thing will make raindrops of--

it was 1.5 mil in diameter.

So it was that kind of yurri constraint.

Not 3 millimeter diameter.

Not 3 millimeter.

You cannot have it that--

oh my goodness.

And it had yurri.

And then it was kind of a
little disastrous

because in the process of manufacturing

this particular tank-- and it was.

It was a tank that had dimples
in the bottom.

And then each dimple had to
have a hole drilled

in the base of it.

They decided to make it out of aluminum.

Then we had cracking of the aluminum

because it hadn't been heat
treated after.

So there was all these things that
we didn't anticipate

in the design of that.

So while the design of what we had
to do was very specific,

we were allowed to upscale it to
fit the particular rig

that we had that we needed to have
all of our equipment put

into.

But there are a whole range of problems

that we came up against that weren't
necessarily done there.

So it was very rigid as to how
we had to have it done

and what we had to show to the Air Force.

But then when there were problems
encountered,

we still had to fix it.

I think you're striking on an
interesting point that

becomes apparent later in your
career, I guess,

is that need for and the
demand of know-how.

Like the human knowledge, human-held
knowledge,

let's say, around what can
actually go wrong.

You can imagine a lot of these things,
but not all of them.

And you need that experience.

And so you're talking about
that relationship

between testing and design, which I think

is something we're going to get
into in a future episode,

probably.

Absolutely.

But I guess I'm struck by--

it's a really interesting book
I read back when I was--

before I started University
about the engineer who

started Ballard.

And he was the guy as a Canadian
exploration company.

He started-- are you familiar
with NEMO, the Deep Sea

Submersible, that first one?

Like we're talking in the 80s, right?

Absolutely.

Last century.

Back when I was a kid, they designed
that entire thing

just through thought experiments.

So he and one other person sat
on his porch or something

of that nature.

And they figured the whole thing out,

worked through all the possible.

But they were adept, experienced
engineers

who had experienced a bunch
of different things

in a bunch of different environments

and all that kind of things, were
familiar with somewhat

submersibles.

And they were able to imagine
everything and design

everything.

And it was successful, right?

Because the budget they were
on didn't mean

they could build no test mules.

They couldn't do any prototyping at all.

They just had to figure it all out.

Now, that's a very specialized
capability.

What am I getting at?

That was pre-Gen AI, pre-internet.

FEA was not available to them.

They was all hand calcs at that time.

Well, we don't--

Again, that's a budget thing.

FEA existed at that point, but that
wasn't available to them.

So was it over-designed?

Sure.

Was it ugly?

Absolutely.

Could have been more optimized?

Of course it could have.

But they went through that.

We're talking about reliability.

Design for reliability, essentially,
is all it was.

There's a basic performance
characteristic,

was get to 600,000 meters
or whatever it was,

but don't fail.

Be able to recover that vessel.

And so in a sense, it was a very
simple design project.

But anyway, what's my point?

It's illustrative of you do design,
you do testing,

build up skills as an engineer.

And that's, in part, what you have
to offer the world, right?

Absolutely.

Is developing that expertise,
developing that--

I've talked a number of times, and
I won't use the same term

we always use, necessarily, but something

like the way the engineers look
at the world, right?

Or the way they look at a problem.

Or they will look at anything.

Can I give you a term for that
that I like to use?

Lots of young engineers go,
but I'm not intuitive.

It's like, yeah, intuitive doesn't exist.

Intuitive engineers don't
necessarily exist.

It just means that they've been around
for a really, really,

really long time.

So they've seen a lot of
different things.

So this is the thing, fast track
to becoming that,

is looking at different things,
being open to new ideas

and experiences, and sort of opening
your eyes to the world.

Like there's a lot that happens.

Everything you touch, being engineered,
touched by an engineer.

Yeah, right.

Touched by an engineer.

People often don't think about that.

People, honestly, genuinely do
not think about that.

They turn around and go, no,
that can't be tight.

That's not engineering.

That's an industrial designer did that.

Well, they may have had a hand in it.

I'm not saying they did.

But to manufacture that
thing quite often,

well, definitely, every single
time, have an engineer.

I mean, as you're saying that,
I think of a chef, right?

They can get a feel for ingredients,

they'll invent a new dish or whatever,

or just know what to do in
a given circumstance.

They can look at things and understand

that it's not going well and make
adjustments and things

like that.

That comes from that whatever 10,000
hours of experience

that he often hears spoken about.

I think engineering is the same, except
it's more deterministic.

And we can actually document
that process.

And you can actually teach that
process to somebody.

And yeah, they have to build
up the experience,

pass on that knowledge in a
way that is different.

It's different from showing somebody
how to sculpt,

or how to paint, or how to cook.

It's engineering, and we can
define the process.

And you and I have heard arguments

that these processes cannot
necessarily be taught,

and that they have to be experienced.

Well, it's important that
you experience them,

but they can be taught.

And that's one of the interesting,
unique aspects,

I think, of the determinism
of the profession.

I think it's also interesting,
because when people say

that that can't be taught, they also

say what you're teaching
is too restrictive.

It doesn't actually allow for--

Creativity.

Whereas in actual fact--

jinx-- in actual fact, it's that--

not rigor, but that discipline
of recording

what you're doing that helps give
you that 10,000 hours.

So there's an old--

I want to explain that just a smidgey.

Sure, we should.

There is an adage that to become
a master at something,

you need to spend 10,000 hours in
practice of that thing.

When you think about, say, here at
this particular university,

four subjects a semester, times
12 hours a week,

which is what you're supposed to do--

You're not on the order of
magnitude of 10,000.

You're nowhere near.

You're 50 hours a semester, times
by four semesters.

So you get into the hundreds,
but not the thousands,

and certainly not the tens of thousands.

And it's OK.

It's OK to not have all of
the answers either.

This is the other thing.

This is why we have connections
and networks,

and this is why Mike and I speak
a lot, because it's like,

what do you think of this?

How do you think about this?

And again, it's that documentation
process

that an engineer goes through
that's really important

and really valuable.

So we've talked about ideation, and we've

talked about some relation to industry

and those sorts of things.

What else do we want to talk
about, I guess,

about the design process?

We've alluded to testing.

I have alluded to testing.

We're not going to--

I don't think we're going
to get into that.

No, we won't.

That's a later thing.

So what I wanted to--

so there's a lot of design
processes out there.

Oh, yeah, OK.

Like a road process.

So I teach one, Yurio, which talks--

it's an acronym called OFRS, which

stands for Objective, Functions, Factors,
Effects, Requirements,

and Specifications.

Thanks.

I never remember what they are.

Hey, I thought I did really well there.

Pretty nice.

I think that there are a lot of
different opportunities

within that sort of particular space,

and you'll find that there's a
lot of different ones.

But one of the big things about that

is that once you sort of
get to a design--

so once you've gone through ideation,
specifications,

so what's actually required, and you

start to get into the creativity side
of things where you really

need to have an actual artifact,
usually a set of drawings,

then you build either part
of it or lots of it,

and you work out does it work
or doesn't work.

And I think that's the big thing.

So that's kind of where test fits,

but we're not going to take that in.

That's a whole other topic
amongst itself.

But once you've sort of got
those things down,

it's like, does it work, doesn't
it work, what happens next?

Well, so OFRS, though, is focused
on kind of getting a start.

Yeah?

Yeah, absolutely.

And I guess to me, it's useful--

I mean, it's extremely useful.

It's useful for getting a method
of judgment of compared

prototypes or something like that, right?

Absolutely.

I just wanted to set that up that
it's the initial stage.

It's true to--

Yeah, problem and get some ideas,
judge those ideas,

and then know kind of where
you need to set off.

That's funny, because I would actually

say that OFRS stops at that
before you sort of get

to solutions.

I would suggest that we then
take it another step

beyond that in our particular classes,

and we say right now that you've really
explored that problem,

you're really comfortable with what
that problem's asking of you,

then start to think about how those
different functions can

work and what mechanisms and what
things can actually

make those functions happen.

So yeah, I mean, I guess that's
what I mean to highlight,

is it's an initial process, right?

And the strange thing is, again,
to relate to industry,

I think that you spend 95% of your
time, or I don't know,

some majority of time not in
that stage, right?

So that's often, again, for a graduate,

it's often been decided beforehand
by somebody else,

or that type of thing.

And then so OFRS is good, great for in
the classroom and things like that,

but then you have to make that
transition away, right?

And so I guess I try to imagine what
most people think design is.

Most students, I don't think, are going to
think that that's part of it, right?

So that's introduced, OK, here's a method
of judgment, and so on.

But what are they thinking?

Are they thinking that it's the part where
you sit down in a CAD terminal

and you start to make the shapes?

I think that's what people
think design is.

And I would suggest that that's
really far down the line.

And that's what I want to
point out, right?

Is that that's the CAD stuff, right?

Yeah, that's just a tool.

And again, something we'll talk
about in the future,

who knows how long we'll actually
be doing CAD?

It's maybe-- what shall I say?

The world is on change.

The world is really changing
at the moment.

I'm going to be not so bold and
say that in 10 years,

it's unlikely that we'll be doing that.

Correct.

We'll be doing it still in five,
quite possibly very likely.

And anyway, all the skills that you learn
are still going to be transferable.

So my point is, there's the
creation of geometry.

But for example, I'm still of an
age where we learned CAD,

but I also like drafting.

Yeah, so did I.

Did you?

You know what else I did is we wrote our
own software to make CAD happen, right?

Oh, we didn't do that.

Non-parametric.

That was in Fortran.

Oh.

It's a tiny little program.

No one's heard our call Fortran.

Anyway, point is, OK, so we've
got this initial stage.

We've got this later stage of doing CAD.

And what's in the middle?

Ah, so this is the thing.

Because I would suggest that CAD is just
a communication of what your design is.

It's not the design.

It's just a representation.

And for engineers, it's better than
putting it into a billion words

because we don't seem to do
that quite so well.

Not to say that we don't write reports,
et cetera, et cetera.

But for us, that really in-depth communication
of what we're thinking

all comes out of drawing.

I would suggest that the design is the
calculations of where do you start,

the integration and the interactions that
each of those shapes and things have

with each other and the world
that they're in.

This is where we get to effectively
its modeling, right?

And you'll hear CAD modeling.

And sure, that's a later thing.

But there's this stage of modeling and
be it mathematical or, you know,

well, I mean, it's all mathematical,
right?

Everything. It's mathematics defines
everything here.

But, you know, there's figuring out
kinematics, figuring out

all these kinds of things, strength
and durability.

We can go through the big list.

There's a huge list.

But it's too long to do here.

So what do we say?

I mean, I guess I mean to talk about
these are the phases, right?

And you shouldn't shortchange yourself
by not doing them all. Right?

Absolutely. And sometimes we see the best
way to get started is to make a mockup.

Sure. That's that's common, at least,
you know, in universities.

But it's not really the way
things are done.

You'll find it's also known as fiddle
around and find out,

which is not always the most engineering
way to do things. Yeah.

Well, trial by fire is is.

You know, it's not the way
things are done.

It was the way things used to be done.

But that's not what we have.
We have modern tools.

We have more capability, a better
understanding of the physics

and and material science and mathematics
behind it all.

And we have a lot of tools
at our fingertips now

that we didn't necessarily used to have.

I guess I think back to like, you know,
automotive development in, say,

the 1940s or 50s, right?

That was very heavily based on.

Well, do a bunch of design
as much as you can.

But we know early on we're going to have
to build something, right?

Yeah, we're going to have
to build something.

We're going to have to crash it.

We don't know how it's going to crash it,
drive it, do everything else.

Absolutely. You still have
to do those things.

But the modern automotive design cycle
has shortened to some fraction

of what it used to be, meaning
like 10th or a fifth.

It's probably what it used to be compared
to, you know, say 50, 60 years ago.

And you have all these tools
at your fingertips.

You don't build until you absolutely
have to, because, you know,

it's expensive.

You know, $10 million, $15
million per, right?

That's where it starts.

If you're talking about a military aircraft,
you're talking about $150 million

for the first one.

They get less expensive as
you bought them all.

As do cars.

As you bought them all.

I think military aircraft now are, I mean,
you're talking final production

costs levels now.

I mean, that's all that much
more expensive.

But development is so much
more expensive.

So billions of dollars to
do these things.

And so you can't do that anymore because,
you know, we've progressed.

But what we leverage from those times when
people did actually build it really

early and test it really thoroughly beforehand
is that they were really good

at documenting that data.

Right.

And this is the thing was that they knew
that in this particular simulation,

if you've got a vehicle of this particular
weight with this kind of material

and you did this particular thing to it,
then this is how it's going to react.

So therefore they started to learn
from those things.

So, yes, it's looking at the failure modes,
but it's also stopping and thinking

about what's happening there and how do
we learn from that rather than going,

well, that didn't work.

We're not doing that again.

So let me just say, I guess I'm not saying
that at university, we shouldn't be

doing that trial and error stuff.

No, of course not.

Right.

I think we should strive to, or students should
strive to, if they want to benefit

the most, just strive to cover as
many bases as they can.

We want them to try to model and understand
what their limitations are,

where they run up against, I don't
know how to do this anymore,

and so I need to do something.

Right.

Because that's effectively
what happens in

industry is you model as much as you can,

and then you realize that there's a disconnect
and you can't go any further,

and you need to do a test.

And so you commission parts and commission
a test and gather the information

and build a body of knowledge.

So we want students to think about
it that way at least, right?

Instead of just defaulting to, well, like,
you know, I'm going to have to build

everything, well, try first.

Understand what the limits of
your understanding are.

And as you go through your academic career,
understand that those limits are going

to increase, right?

That you're going to get better and better
at the maths, you're going to get better

and better at the simulation and the hand
calculation, things like that.

And so keep doing that, right?

Because it's that process.

Honey, we're blending the design and
the learning process here now.

And it's, you know, by going through an appropriate
process for learning design,

you're going to actually build that
design aptitude, right?

Of course.

And the other thing, too,
I think that it's

important to recognize that
the other units

that you would do as a student.

So, you know, if you're doing a very,

like, what's considered to
be a technical unit,

say you're learning thermodynamics or fluid
dynamics or vibration or controls

or any of those things, the first thing that
someone will say to you is, right,

once you've got your problem, write down

what you know and what you're
trying to find,

your free body diagram, and then start
to look at your calculations.

If you approach design absolutely in that
so that it's a bunch of smaller problems

that you have to find an answer to and
you do those hand calculations,

it's not a waste of time.

It's definitely not a waste of time.

Even if you only get to the
point where you

can mathematically model that
particular problem

or having, then that's still
advantageous.

You know, you don't have to have specific
sizes or endpoints in mind.

Sometimes it's just the variables and how

they're going to interact
with each other.

Cool.

I forgot to start the timer, so I don't
know where our time is,

but it feels like we're getting
near the end of it.

Is there anything else we want
to discuss today?

And we've lost it completely.

So, you know, "bullets for the win."

Yeah.

Inside joke.

So, what I wanted to say, I think,
before we sort of wrap up,

is that this is iterative.

You don't have to have all the answers.

Filling around and finding out is
still a good way to go,

but try and put some rigor into it.

Try just pulling all the information out

from your other units and your
other experience.

Keep your eyes open.

Keep your ears open.

Look at what things are happening
in and around you.

Look at what is happening in the world, because
we are in a definite state of flux

and change at the moment.

It's really exciting.

And, you know, read widely.

Like, I remember what that book
is that I was describing.

It's called "Ship of Gold in
the Deep Blue Sea."

Because Enemo was originally
built to go and

find some pirate gold or something
like that.

That was the actual original mission.

You know, look at those
other sources too,

because there's a lot to be learned about

watching people talking about
their process,

like we have here, but there's more
detailed accounts of that

that are richer than what we've been
able to touch on today.

Absolutely.

So thank you very much for joining us.

We are currently in the Design
and Build Studios

in the bottom of the Allen Finkel building
of technology and design.

I'll get it right one week.

But thanks so much for your time today,

Mike, and thanks for those
who are listening.

Peace out.

Thanks, Kathy. See you next week.