Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
Design Communication for New Engineers
26 Plays4 days ago
In the season 4 premiere, Dr. Jill Fennell sits down with returning guest Dr. Amit S. Jariwala and new guest and fellow instructor Marty Jacobson to discuss the conventions of Design Communication. The episode covers how early-career engineers make communication decisions as they move from "student writing" into professional practice, design teams, and real constraints.
_
Show Notes and Timestamps:
- 01:00 Welcome and Introductions to Guests - Amit Jariwala and Marty Jacobson
- 01:36 Communication Design Processes: Creating Specifications
- 03:27 What defines a strong input or specification
- 06:27 Role of the spec sheet in early design decisions and how you discuss them
- 09:02 Common misunderstandings students have about requirements
- 12:10 examples of good or bad Specs
- 15:47 Ensuring Measurable Specifications
- 20:05 How do students talk about design processes to different stakeholders?
- 20:57 How do students build trust that their designs are feasible and reliable?
- 22:27 Undercutting utility through qualitative language
- 25:55 Specific Qualitative Phrases
- 29:46 advice for students resisting to commit to numbers early in the process
- 33:43 Advice for students trying to balance flexibility and actionability
- 38:06 Wrapping up and last points of advice
A transcript of this episode is available here.
Episode edited by Lee Hibbard.
Recommended
Transcript
Season 4 Introduction: Communication in Engineering
00:00:08
Speaker
Welcome to season four of Communication Mechanics, a podcast for engineers. In this season, we're focusing on a reality many engineers experience early, but aren't always taught to name. And that is that communication is not just about clarity, it's about judgment.
00:00:24
Speaker
Engineers constantly make decisions about audience, purpose, power, and consequence, often before they feel fully prepared to do so.
Engineering Communication in Professional Settings
00:00:31
Speaker
Across these episodes, we'll explore how engineers communicate as they enter professional spaces, work across hierarchies, solicit opportunities, and take on greater responsibility.
00:00:42
Speaker
Whether you're a student, a new engineer, or someone mentoring others, this season is about understanding how communication shapes not just what engineers say, but who they become as professionals.
Guest Introductions: Amit Jarawalla & Marty Jacobson
00:01:00
Speaker
Today we have with us a returning guest, actually the first guest of our very first episode of our very first season, Amit Jarawalla, who is the director of design, innovation, and experiential learning. Welcome back, Amit.
00:01:14
Speaker
Hey, ah thank you, reg Jill. I'm excited and happy to be here again. Great. And we also have another teacher with us who does a lot of teaching in our design curriculum, and that is Marty Jacobson. Welcome, Marty.
00:01:27
Speaker
Hi Jill and Amit. It's really exciting to be here to talk about how to help our students communicate better and talk about design and specifications. Great.
Effective Communication in Design Decisions
00:01:36
Speaker
So this episode is really for the students and thinking about where they are in their design process to actually communicating some of their design decisions. So imagine you've brainstormed, built a first prototype, and now you're writing a spec sheet to communicate your design decisions.
00:01:55
Speaker
But will anyone understand what you actually mean by small, durable, or safe? Today, we're really going to dig into how clearer language and design tools help translate concepts into manufacturable realities.
Quantitative vs. Qualitative Specifications
00:02:09
Speaker
Thoughts on that? lot, actually. And I'm sure Margie has those, too. What specification does, it lays out the blueprint of what you want the end product to perform, right? So you're looking at exact specifications in engineering language of how the end product would work.
00:02:27
Speaker
And so it's very important to have this quantitative, specifications listed and not qualitative like it has to be safe or it has to be lightweight like being very specific of what you want because what you're doing in a way is setting up a contract with yourself and with your team that by the end of this we will design a product that will meet those specifications the more vague you are the more challenging it would be to convince that you actually solve the problem would you say that this is a common hurdle novice engineers need to go through Yeah, it's really an inherent part of learning what design is.
Validation vs. Verification in Design Specifications
00:03:00
Speaker
I think everybody starts out by specifying goals that are both too lofty and too tangled. So, you know, for example, you would never accept a job from an employer if they just said, don't worry about the money, we'll pay you enough.
00:03:18
Speaker
yeah No, I want to know exactly how much you're going to pay me and when. But for some reason when we do design projects, we're like, oh no, we'll stop when it's good enough. Then what defines a strong design input or specification?
00:03:34
Speaker
I think to do that, we really have to make a distinction between two big types of specifications and design inputs. And those are validation requirements, where we're really trying to decide whether we made the right product, and verification specifications, where we're really trying to figure out if we did what we said we were going to do.
00:03:54
Speaker
So typically, you know if you're talking about a basketball game, a validation requirement would be win the game. But to get there, you need to do a lot of other things right. Like for example, you might need to measure the pressure of the air inside the basketball before you even start the
Defining Project Scope
00:04:12
Speaker
game.
00:04:12
Speaker
And so in order to say that you won the game, there's a lot of things that have to be satisfied before you can even know whether you did. I really like that analogy because occasionally what happens is students get fixated on the end goal. So think like you're designing a car, and it wants to go zero to 60 in two seconds.
00:04:32
Speaker
Well, that's one spec, but what all do you need to get there, right? So that helps you even think more deeper about your functions, right? Maybe it has an engine, a transmission. So what what are those requirements for that torque and RPM and stuff like that that's really helpful to think about?
00:04:47
Speaker
Okay, so it's really making sure that you're thinking about the bigger picture of everything that is going to be involved in this design. Not just that, but defining how much of the big picture you are handling. So it's about scope. Scope is a very important part of any design project.
00:05:06
Speaker
Because, you know, if you say, we're going to cure cancer, I mean, that would be great, but it's probably not gonna happen this week, right? Right. But we can measure something that might relate to cancer outcomes in a patient, and that we can formulate a test that we can objectively measure, right? Right.
00:05:24
Speaker
So I'd say once you've defined like what it means to solve the problem for the customer, and we call those customer requirements, then it's time to break them down into very specific, very, like almost stupidly simple, like a free body diagram where you have ah a simple system that it might be so simple that you can measure it in one unit, like length or time, right? But with some constellation of a few of those different simple metrics, you can tell whether you did address that customer's need.
The Living Document: Specification Sheet
00:05:59
Speaker
In other words, it's kind of like a metric of success, right? What it takes for you to say this is successful is what you write down. There is also an element of realizing that you want your design to be your solution approach, to be solution agnostic at the beginning, which means you might not have all the specifications.
00:06:16
Speaker
But the idea is that as you add more, as you do more iteration, you might end up also adding more to your specification sheet. So it's, if the specification sheet is a living document that keeps on evolving over time.
00:06:27
Speaker
What I'm hearing is that an important key quality of the work that's being done at this time is that it needs to be measurable. In thinking about that, what is the role of the spec sheet in early design decisions and especially the way that you discuss those early design decisions?
00:06:45
Speaker
To start out with, you first want to define what is it that you would consider as success for your early prototype, whatever you would that would be, right? Because you're not probably going to design the entire product in the first week or the first few weeks.
00:06:58
Speaker
So it it takes some level of foresight to scope down the problem and say, okay, by the end of the semester, we'll accomplish all of this, but what's the near goal that I need to accomplish? And that sounds like a very mature skill to be able to scope down and then back up.
00:07:14
Speaker
And it is challenging. It is totally challenging. This is why design is taught across multiple courses and multiple times because it doesn't come naturally. It's not like following the steps on a textbook and getting to an answer. It's an iterative process and that needs practice. And one of the challenges sometimes to scope down, you need to understand what your capabilities are as well. And obviously, students like to change the world in in a day, but that's not possible. So that's why iteration and practice are required for this.
00:07:44
Speaker
yeah and I would say directly the spec sheet's job is to define how good good enough is.
Specification Sheets: Guiding Prototypes and Resources
00:07:51
Speaker
it's It's really a rubric that you're going to use to grade your prototypes against.
00:07:55
Speaker
And you can also grade existing competitive devices against it too. So can it helps you figure out not only where your designs are strong and where you need to invest more time, it also helps you figure out how you can communicate the value of your new solution over existing commercial solutions.
00:08:12
Speaker
It also will help you determine where you're going to need more resources. So if you're easily meeting several of your metrics, then you might not need to invest resources in those, but it's going to help you figure out, well, this part of it is going to be really difficult.
00:08:26
Speaker
So we need to prioritize the resources or the research that we need or getting this tool or a measurement device. It helps you identify where the project is going to be hard and where it's going to be easy.
00:08:39
Speaker
That's a really good way to think of it because if you're talking about the design process, at times you have to make a decision of what's an important problem to solve. What's the riskiest things that's supposed to fail so I can test for it? And this is where the spec sheet goes hand in hand with that process, that it's not like one sheet you make and then forget about it and do the design, but rather you are reflecting on it as you're progressing throughout and making it as necessary.
00:09:02
Speaker
What's a common misunderstanding students have about these requirements? So one of the most common ones I've heard after getting them to realize that these specifications need to be quantitative is that they get hung up on this idea that I need a perfect number.
00:09:18
Speaker
So sometimes they feel like because I don't have this number, because I don't know how much should be the battery capacity, maybe I should not include it in entirely. And my advice typically is that it's okay that you don't know, but at least list within what range is it acceptable so that in your next iteration you can narrow down the range further.
00:09:36
Speaker
So that is, I think, very valuable to add is also mentioning what you know, but equally important is to mention what you don't know in the spec sheet itself.
Generative AI and Test Methods in Specification Writing
00:09:45
Speaker
That really reminds me of a conversation i've been having with students lately about using generative ai and like what to look out for because it's not good at being an engineer, is that it likes to make statements that are universally true and therefore not usable for engineering.
00:10:01
Speaker
Exactly. Yeah. The more specificity, the better. Yeah, I think there's ah definitely a misconception that more vaguely stated metrics will be easier to address. So something like a percentage, it's really difficult to figure out exactly what will align with that customer requirement. And in industry, in fact, one of the most difficult parts of product development is developing your test methods.
00:10:26
Speaker
And so, you know, this is kind of like a hidden learning objective in a lot of design classes that all design classes are also inherently like test methods, developing development classes. And when you have easy things to measure that also tell you a lot about your design, then your prototypes are gonna be very valuable.
00:10:47
Speaker
But if you have fuzzy things, ah like if you're measuring something that's complicated to measure like comfort, then it's going to be very difficult to know whether a new prototype really positively impacted that because it's going to be subjective and it's going to be difficult to measure.
00:11:04
Speaker
So instead, if you can correlate something like comfort to surface area and you can make a reasonable argument for why surface area correlates to comfort, now you have something clean to measure.
00:11:16
Speaker
Maybe on something like airline seats, for example. sure But to echo the Marty's point, I think two most important things are the source, right? So in the spec sheet, you do have to mention source. And one of the common misunderstandings I hear from students is my sponsor said so, hence it is important. And generally the answer there should be, well, i have we have done this research or we have found this standards and specifications and this is where our standards are grounded in because the spec sheet also acts as a blueprint for the next team or next design team to iterate upon. So it's important to have the source correct.
00:11:53
Speaker
Also important is, as Marty mentioned, like what how will you test it? If you mentioned like it has to be comfortable to 20% or 80% of humans, what does that mean and how will you test it? Because the process of prototyping is deeply rooted in the specification sheet itself.
00:12:10
Speaker
Do either of you have any examples of good spec or bad one that you've seen recently? Well, not recently, but this example is one that sticks in my mind. I was actually in a past job, a construction project manager, and we specified that all the light bulbs in the project should be dimmable.
00:12:30
Speaker
And we got there, and this like this had like a stage. like You need to be able to control the lighting. And we got there, and they had put incandescent lights everywhere, which are technically dimmable.
00:12:42
Speaker
Mm-hmm. but no way to actually dim any of the lights. And it was a gotcha moment. We had to pay them because technically they did do what we asked, but our poor specification, when it was not actionable or defensible, like in court, there was nothing we could do about it.
00:12:58
Speaker
So ah ah another example, like in in medical devices, a lot of times you will say that the device needs to be sterilizable. And so a lot of times that gets embodied in projects by saying, oh, well, it's all stainless steel. Well, that's not how sterilization requirements are defined. Just because the material can be sterilized, there's actually validation procedures that are the result of the product being used.
00:13:23
Speaker
and then you know the actual residual biological materials are tested right in a specific way. So you know if you can turn it from being a vague requirement into something that's based on a standard, that is the ideal because it's a rigorously vetted, standardized procedure that is used across the industry.
Applying Standards in Design
00:13:45
Speaker
The example Marti, you just shared about standards reminds me of some of the previous capstone design projects that we have had. And back around that time, cell phones were coming out. They were all being advertised as IP65 rating or some sort.
00:13:59
Speaker
And I would see every single capstone team, if they had anything to do with rain or dust, they would just blasted IP65 as a requirement. And then I would ask, why would that be? How would you accomplish that? And that would lead into a more interesting conversation.
00:14:15
Speaker
But that happens that when they they see certain standards, they might feel like it's applicable. But this is where spec sheet really helps to think about, do they really need the requirement or not?
00:14:26
Speaker
Another thing that really wreaks havoc with specifications is when you have confounding variables, like maybe you have one element of the design that you think is actually providing rigidity, but it's actually another part of the design that's doing it. And then you change something and it all behaves differently.
00:14:45
Speaker
you know So really doing a functional analysis, using your function tree or functional decomposition, doing simple mathematical modeling or any kind of analysis of the structure or the mechanism.
00:14:59
Speaker
If you can't draw it on the back of an envelope, you probably don't understand it well enough to write a specification. And then the other big thing that I would say to really be aware of is rationale. So why was this spec chosen?
00:15:11
Speaker
Not just IP65, but like why weather sealing at all? Why does that matter? I've seen a lot of teams where they started with the presumption of it being powered and then it moved to being an unpowered solution, but they still have like a compartment for a battery.
00:15:27
Speaker
And you're like, well, why do you still have that space there? It's really easy to do that. So having some rationale defined in your spec sheet for why this is a requirement allows you to update it and realize what the dependencies are, which is another big part of making specifications that are robust and actionable.
Communicating Value Through Specifications
00:15:47
Speaker
We've talked a lot about these really important tools, these tools that students need to take a lot of time to think about when they're using them so that they can be very specific because that's going to be really important with their engineering decisions.
00:15:59
Speaker
How do they talk about these tools, especially how do they talk about these tools to supervisors and how their supervisor might want to know about their decision-making process versus the way they might talk about them if a client wants an update on where they are.
00:16:16
Speaker
I think for both of those key stakeholders that they might report to, it's really good to frame it in terms of value. Because the whole point of specifications is to determine what acceptable means.
00:16:32
Speaker
And that comes down to not just how much time you're gonna be spending on something, Like, why would you spend another hundred hours trying to get a 0.1% improvement in the optimization of some metric when you've already met the target, right? But for your customer, if you've met the target, then Why would you spend more time paying somebody to develop it further? Or why would you spend more money refining a process to make something more consistent when the process capability can already hold tolerances or functional performance within the range that you need, right? So I think at the end of the day, it's all about value.
00:17:12
Speaker
It's not just the values of the design strategy, but it's also, again, how good is good enough. And by defining that really clearly and communicating every single thing you do, we're building a prototype.
00:17:26
Speaker
Okay, what are we gonna measure? And what is that gonna tell us about how well we're meeting the customer requirements? If you do that, not only are you gonna answer the customer's needs really well, but you're also not gonna waste time as a design team.
00:17:40
Speaker
I really like the framework of using the spec sheet as a way of communicating value. I'll add a little bit of nuance of the differences between communicating to the sponsor or external client versus communicating to your instructor.
00:17:53
Speaker
So when you take the spec sheet to communicate to your sponsor, you are in a way trying to achieve this consensus of sorts that, hey, this is what you require vaguely as a customer of sorts, and this is what we translate as an engineering spec, are we in agreement, right? So you' you're targeting the most critical elements of where you expect there might be disagreement, and you're focusing there.
00:18:13
Speaker
Whereas when you are discussing with your instructor, what you're doing is, you are identifying from an engineering standpoint which features would be most difficult to accomplish, And then we having had that discussion of, is this something that we can accomplish within this time period? So your instructor can advise you on, yeah, this is feasible within the time period that you are located. So that's a minor nuance, but in a way you are still communicating the value.
00:18:37
Speaker
One other thing that I would add is, in capstone design we typically say, you're designing your product, not your prototype. You might make multiple prototypes to get to your product. And so what the spec sheet does is we tell them that, use the spec sheet as a means to write the specifications of your product.
00:18:53
Speaker
But then in how you validate it you can specify how will you use prototypes to validate certain aspects. Sometimes you need a physical prototype, sometimes you need a virtual prototype. But you're you're laying down that strategy as well in the spec sheet while you're preparing it.
00:19:08
Speaker
In something like a preliminary design report, it sounds like students will need to be referring to a spec sheet like pretty directly throughout to talk about why they made certain decisions.
Documenting Rationale for Specifications
00:19:20
Speaker
Absolutely. And in fact, even in the spec sheet section, they might have to define further, going back to Marty's earlier comment about the rationale. How did they arrive at that number? If it's not in a typical standard, or even if it's in a standard, why is that necessary? It's very critical to include that.
00:19:38
Speaker
Would that go in something like a paragraph where you're discussing the spec sheet? Would it go in an annotation or a caption underneath the spec sheet? What's industry standard? Typically, we we prefer having it adjoining with the spec sheet, so you are explaining with the spec sheet, because the spec sheet is the table. It's it's fairly straightforward.
00:19:57
Speaker
But then in in the discussion, you can explain more about where those things are coming from. Okay.
00:20:04
Speaker
Is it ever appropriate then to have a specification without numbers, units, those hard engineering metrics? I know it's a volemical question, but you two are the best people to ask for our students to hear the answers, so...
Precision in Specification Sheets
00:20:19
Speaker
I would say no. I would say you can always figure out a way to reframe what you're asking so that it is measurable.
00:20:28
Speaker
That would make sense. I mean, why does the client need you as an engineer if not to turn their request into engineering measurable metrics? Amit?
00:20:38
Speaker
Yeah, and I would agree with that. The answer is no, and that's because I'm looking at the definition of specification which says identifying something precisely or stating a precise requirement.
00:20:50
Speaker
So how can you have a specification sheet without precision? just doesn't go together.
00:20:57
Speaker
What can students do in their communication deliverables that build trust that their design choices are intentional and feasible? I think having an awareness that they are communicating to make an argument present the justification as against writing a report to trick mark this box that someone asked them to write and so they are writing it, right? So taking away the semative aspect and really thinking about I'm writing this report, I'm creating this spec sheet, I'm using this design tool so that it helps me make a better decision and I'm communicating that decision.
00:21:31
Speaker
I think if that's the attitude and perspective, they will most likely end up making good choices. So don't think about it as summative or chronological, but as a logical engineering argument.
00:21:44
Speaker
Exactly. And expand on that to really build credibility, especially in a design report, never spend time in the abstract defining what steps or tools were used. For example, don't say, we use the house of quality to identify the weighting of the customer requirements.
00:22:02
Speaker
Make it specific and say, Using a house of quality, we identified that these three things are most important to the customer. It's a subtle change, but all of a sudden you're actually communicating information instead of saying something that is generic to the design process. Communicating a process that the readers would likely already know.
00:22:21
Speaker
Absolutely. And just not really saying anything specific to your project.
Defining Metrics: Avoiding Vague Terms
00:22:26
Speaker
Mm-hmm. I'd like to talk about language specs. Quantitative language, qualitative language, and how they should be working together. What's the impact of using vague qualitative terms like fast, simple, or compact? And what kind of language do you see students use that undercuts the usefulness of their work?
00:22:47
Speaker
I think the common most thing I see is safety and portability as a specification requirement. And it's really easy to dig deeper and get them to specify, but it just becomes easier to just use those words because who doesn't want a safe staff, right? Everyone wants safety.
00:23:06
Speaker
But having that discussion really helps add clarity. There are also things like, maybe they might have seen examples of materials like Marty was mentioning, stainless steel. If you want anything to be sterilizable, just use that material.
00:23:20
Speaker
But products are composed of so many materials and so many components. And occasionally what happens is they they fixate on one component and make the entire spec sheet for the product, but few specs only for a component.
00:23:33
Speaker
So that there's this sort of dissonance between what the entire spec sheet is for. Yeah, I think my least favorite vague term is efficient because other terms like lightweight. Okay, you just told me that the mass is important, but you didn't tell me what it should be or how to be measuring that. So that's one question mark that you raised by mentioning.
00:23:58
Speaker
but i would almost prefer that you didn't mention it at all if it's going that vague. I was thinking about the the foam poster boards behind you and how they're very lightweight, but I don't want to carry that across campus because it's going flap in the wind and I have to hold my arms all the way apart when I'm trying to carry it.
00:24:12
Speaker
so Right. Yeah, that's not it doesn't live in a vacuum. And efficient is even worse because when you say efficiency, there's at least two question marks because efficiency is always an optimization. Right. So I am getting a lot of something for a relatively small amount of something else that I'm investing. Right.
00:24:30
Speaker
um And so you didn't tell me if you say it needs to do this efficiently. I don't know what those two things are and I don't know how much of each is being involved in this transaction. So, you know, I would instead of saying efficient, just tell me it can travel a meter in two seconds. And now I know what the things are that you're balancing. Or you can say it travels a meter while having a mass of 500 grams, right? Like,
00:24:55
Speaker
There's lots of different ways that things can do things efficiently. I remember a mentor way back when I was a kid, we were driving and the windshield got fogged up and he was like, hey, turn on the heat and the AC at the same time. And I was like, isn't that inefficient? And he's like, it's very efficient if your goal is to defog the window.
00:25:13
Speaker
And you know it's like, okay, if you wanna say something's efficient, tell me what the goal is and then tell me what are the things that you're investing and what you're getting out of it. And then that is good communication. So I would say if you're drafting and you wanna draft and use these vague terms as like placeholders, they can be good to help you structure your thought process like an outline.
00:25:36
Speaker
But by the time your draft is finalized, you should have converted anything that's vague into specific steps that were performed or specific decisions that were made. And you should be able to say why that combination of unit and value is appropriate.
00:25:56
Speaker
Any other terrible qualitative phrases that just like really, really get you? I know we have issues sometimes in the lab classes with the word optimal, which can be... It has a specific meaning. Right. It has a specific legal meaning. And one thing that our students don't necessarily have to worry about, but should be on their minds as they're learning communication, is that these written documents are what we call in the legal field, discoverable.
00:26:26
Speaker
So some other things that are pet peeves of mine are percentages. If you use AI to help you draft design inputs, it almost always put percentages in there. Again, a percentage of what, at what scale, like what kind of error bars are on this measurement, right? Like, and is it's just so vague. Tell me how many times you're going to run a trial and and what you're expecting to see or, you know, somehow define that. Don't just use a percentage. Also, just like a less than a certain amount, an unbounded, you know, expression. I want to see a range of values because, you know, if you're going to tell me that it should be less than 50 Newtons, why why not zero?
00:27:04
Speaker
Or if you say it should be more than 50 Newtons, why not 500? Like, or 5,000? Like, if I get paid a certain amount for a job, there's no upper limit to what I would like to be paid. Yeah. So why not? If you're saying something's better, then how much is best? right like there There always is a range at which it becomes excessive in engineering. There's something that starts to fall apart. So figure out what that range is.
00:27:32
Speaker
As the engineer, you're the trade-off expert. Yeah. And that reminds me of a common issue that I see in some of the specification sheets, and that is about the battery life. So they want maybe the device to last for X number of hours, but they would say the battery life has to be X number of days or something.
00:27:53
Speaker
And then when you go and ask, like, can you spec out the battery and how large would it be? And would you meet the weight considerations? And then you immediately realize, oh, maybe battery is not the right answer. or things like, oh, we'll use solar power without necessarily having done this ideation to identify all sources of power. So sometimes spec sheet, if done in a way to add too much specificity early on in design, could lead to some design fixation as well.
00:28:17
Speaker
So that's something to keep in mind as well. And you're talking about like the balance between quantitative and qualitative. And so obviously the customer requirements generally are binary.
00:28:29
Speaker
It's either safe, or not. And so we accept that with customer requirements because we build it out with a constellation of other things that are more specific and quantitative.
00:28:42
Speaker
But another way to look at this is that sometimes when you're making your spec sheet and you realize you don't have the data, that's an opportunity too. I see a lot of teams waste a lot of time endlessly searching for a literature value for something when they could do a very quick high school physics lab level experiment and just like go pull on the thing with a force gauge. Like you can devise an experiment that will give you real world data this afternoon.
Experimentation to Fill Knowledge Gaps
00:29:09
Speaker
And so i would say another opportunity is anytime you have something that's qualitative, you don't know what that answer is, highlight it in your spec sheet and then go figure it out. Go benchmark it.
00:29:21
Speaker
In med device development, we would often, you know, go into the cadaver lab and measure something specific because You're going to find values just all, you can find essentially any value if you look at enough human bodies, right?
00:29:35
Speaker
So you got figure out like what is a range that's appropriate and developing an experiment to fill in that gap in your knowledge can be a really good way to do that as a start to your prototyping. What advice would you offer to students who are resisting to committing to numbers early in the process?
00:29:53
Speaker
I would say the number one term I use is iteration is okay. And you're not committing your life to that number that you're specified. And most importantly, in fact, at the earlier stages, it's okay to mention a range that you feel is comfortable and then narrow the range down or get to that specificity.
00:30:11
Speaker
But you can always run an experiment, a a prototype, and you can pivot it realizing this is not accomplishable. But the idea is design is an iterative process. And so it's not like you you have made a contract for the rest of the semester.
00:30:24
Speaker
All you're doing is based on the information you have at that point in time, these numbers make sense. And tomorrow if you know more, you will change. If you have a reason for why you arrived at that, then you can make the claim. If you have a better reason later, you can adjust the claim.
00:30:41
Speaker
Yeah, I would say that the reason they should really define the specifications granularly is because, really two reasons. One is it makes your life easier.
00:30:53
Speaker
I would much rather design a widget that can withstand five one-meter drops then design a widget that is durable.
00:31:04
Speaker
Right, like I don't know what that means. What are you going to do? Are you gonna shoot it out of a cannon? i don't I don't know what durable means. And if it's defined very specifically and reasonably, then I can go back to my customer and say, yes, we did this.
00:31:20
Speaker
And I can show you it doing this And I can show you the data about how regularly we can repeat this. And that's easy. I can go to lunch and have a weekend, right? Early in my design consulting career, I would define things too vaguely.
00:31:35
Speaker
And I remember one customer specifically who I built a prototype and I thought it was great. It met the requirements. It worked. And then he's like, that's not it And I was like, okay, well, I went back and built a whole nother prototype and showed it to him again. was like, oh, no, still not it. Three rounds of prototypes. I eventually realized that he was just getting free work out of me.
00:31:59
Speaker
Really, he was just keeping on going. I mean, the prototypes were getting better. I wasn't getting paid anymore. So, you know, it makes your life easier to know exactly what that means. Also, are the way our brains work, when you have more constraints, you are more creative. If you have done the work,
00:32:17
Speaker
to figure out a bunch of easy ways to measure a problem. Designing solutions is easy. We have things like concept evaluation matrices, which are there to help you figure out which of all the ideas that you have, you should move forward with.
00:32:32
Speaker
Because the problem ends up being not how do I come up with ideas, but how to choose choose which ones to go forward with, right? And that doesn't come from just having a, you know, lightning bolt moment of inspiration. It comes from understanding the problem so well that you, with a little bit of knowledge of how physics works and how basic prototyping tools work, you will have plenty of ideas for how to prototype it.
00:32:57
Speaker
It just comes with the territory. But if it's too wide, that's those are the teams that I see really struggling, you know, at week eight of the semester is they don't know what to build because they don't know what they're going
Constraints Foster Creativity
00:33:08
Speaker
to measure. Right.
00:33:09
Speaker
I love that analogy. It's almost like you can only think outside the box if you know you can draw the box. yeah As someone who started her career in teaching writing, I would much rather have to write a paragraph that argued that the machine could withstand however or many Newtons of force than to have to write an entire essay to make the argument that it's durable. That's the kind of level of of need that I think those those two parameters really evoke. yep
00:33:42
Speaker
What advice or insights, recommendations, what have you, would you have for students who in their communications are trying to balance being flexible and iterative and writing to a level that can actually be actionable?
00:33:58
Speaker
So in the spec sheet itself, one of the important columns is the date. So you can think of that as, okay, that is the date at which I knew this was correct, and now I know more. So now there's a new date for it.
00:34:10
Speaker
So I would say like everything everything in design process is iterative for that reason, because you gain more information as you work towards the problem. And so it's fine to have that approach because only then you will come up with a solution that will actually solve a problem for someone who cares. Otherwise, you'll just build something that you built and no one would use it.
00:34:31
Speaker
Right. I think the scariest thing to me about novice engineers is when I ask most teams, what are your top design inputs?
00:34:45
Speaker
They're like, oh, yeah, we have those somewhere. And you know like you're actively prototyping something in the shop and like, what is this prototype? What are you gonna measure about this prototype? Oh, we'll figure that out. you know I really try to push back on that and say, hey, look, I'm not gonna give you feedback on what you're building right now until you tell me what it is that you're trying to show with this work that you're doing, right? It's almost as if you you can't really give feedback on that without knowing what the overall point is. Right, it's gonna be it's goingnna be it's garbage in garbage out. like If I don't know what you're trying to do with it, how can I give you feedback on that?
00:35:26
Speaker
And I think that is also a really good thing to remind teams about. I think a lot of times team dissension and lack of consensus simply is just not using the tool. like How many teams close the spec sheet when it's due and and don't open it again weeks?
00:35:43
Speaker
for weeks If you're not using that tool, then you're just not working efficiently. and I really do think like one of the jokes I always tell people is, you know, the difference between a junior engineer and a senior senior engineer is that a senior engineer gets weekends. And it's not because they're not doing work. It's because they are using every hour of their time to do productive work that moves the project along and addresses project goals. And junior engineers,
00:36:11
Speaker
tend to get wrapped around little details that blow out of proportion and they don't they don't have the spidey sense to recognize when something is not being productive and not contributing towards the development of successful solutions. They're not measuring things against the specifications.
00:36:32
Speaker
And the senior engineer has seen that project creep happen so many times and has had those difficult meetings with customers where they went 500 hours over budget on a project. And you just start to realize that the spec sheet is the most important tool for maintaining sanity and getting work done.
00:36:49
Speaker
It sounds like it also might be one of the most important tools for making arguable claims, making actionable claims.
Specification Sheets in Reality and Design Iteration
00:36:57
Speaker
From your answer, Amit, it sounded like the balance is knowing that in design it is iterative until it's done so just be as actionable as possible is that a good right is that a correct interpretation of your statement yeah it's like at every stage in time you have limited information access to the information and so you're reflecting that reality as against making up a fantasy and this is why
00:37:24
Speaker
Having the specifications be very specific, grounded in reality and rational with sources. All of these matter because you are reflecting what you know as of now so that it drives your next action.
00:37:36
Speaker
And I feel like that really brings all of our points and really the episode as a whole together in that What we're really looking for from engineering communication, especially from novice engineers, maybe the first time doing a communication deliverable for design, is for you to make a claim that could be wrong, but to have a reason for why you made it. Absolutely. Absolutely.
00:38:06
Speaker
So as we start to wrap up, do either of you have a takeaway you want to offer or maybe one last piece of advice that students can hear before they sit down and write that first deliverable? I just always remind the students that yeah whenever you're designing something, you're designing it for a reason.
00:38:23
Speaker
And the the reason is that it should have value for real people. And so any design decision that you have made, you should be able to tell me specifically what is the design decision you made What specific metric was it made to address and how does that metric contribute to solving the problem for the customer?
00:38:48
Speaker
And if you can make that, in in medical device development, we call that traceability. If you can do that, the FDA will be very happy. But also, if you do that, that's just good design.
00:38:59
Speaker
that's also just what you learn, almost really, in high school for expected
Defining 'Good Enough' in Specifications
00:39:04
Speaker
paragraph structure. You have a claim, you have your evidence, you say why that evidence matters in relation to your claim, and you move on.
00:39:11
Speaker
Yep. I really enjoyed listening to Marty explain some of these concepts, and something I'll take back as a tagline is that if you want to work just enough and have free weekends, make sure to define what is good enough in your spec sheet.
00:39:25
Speaker
That's good. Yep. Marty, Amit, thank you both so much for being here. i really appreciate the conversation, and I'm really looking forward to seeing students get out there and make those claims.
00:39:38
Speaker
Fantastic. Thank you for having us. Thanks. Yeah, thanks so much.