Quality during Design
Quality during Design is the podcast for engineers and product developers navigating the messy front end of product development. Each episode gives you practical quality and reliability tools you can use during the design phase — so your team catches problems early, avoids costly rework, and ships products people can depend on.
You'll hear solo episodes on early-stage clarity, risk-based decision-making, and quality thinking, along with conversations with cross-functional experts in the series A Chat with Cross-Functional Experts.
If you want to design products people love for less time, less cost, and a whole lot fewer headaches — this is your place.
Hosted by Dianna Deeney, consultant, coach, and author of Pierce the Design Fog. Subscribe on Substack for monthly guides, templates, and Q&A.
Quality during Design
Revolutionize Your Technical Presentations: Mastering the Assertion Evidence Model and the Six P's Framework
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
Can the way you present technical information drastically impact decision-making? Absolutely. In our latest episode, discover how the assertion evidence model can revolutionize your presentations. Rather than relying on lifeless bullet points, this method encourages you to make clear recommendations at the top of each slide, coupled with compelling graphical evidence. We delve into the six P's—Perspective, Problem, Principle, Proposal, Proof, and Process—that serve as the backbone for structuring your presentation. These elements not only enhance learning but also facilitate more informed and productive discussions within your team.
If the thought of presenting to your team makes you anxious, we've got you covered. We'll share practical advice to boost your confidence and help you deliver your findings more effectively. By focusing on the value of your insights and using the six P's framework, you'll be well-equipped to engage your audience and convey crucial information. As we approach a busy season of deadlines and presentations, challenge yourself to adopt these methods for the benefit of your team. For more learning techniques, don't forget to check out qualityduringdesign.com.
Visit the podcast blog for helpful summaries and graphics.
If your team is still catching problems too late — let's talk.
→ Schedule a free discovery call: Dianna's calendar
Want insights like this?
→ Subscribe to my newsletter: qualityduringdesign.substack.com
Get the full framework.
→ Pierce the Design Fog
ABOUT DIANNA
Dianna Deeney is a quality advocate for product development with over 25 years of experience in manufacturing. She is president of Deeney Enterprises, LLC, which helps organizations and people improve engineering design.
Effective Technical Reporting for Decision Making
Speaker 1Fall is almost here and I don't know why, but I always associate fall with trying to tie things up, get things moving with the project and meet end-of-the-year deadlines. Maybe that's because that's what I experienced in my own work. Perhaps you're experiencing that too. So you're probably heading into technical review season, where you are finishing up tests or you're writing up technical reports and now you're being asked to present the results of those reports for the team to be able to make a decision. Well, good thing that you spent all that time writing that really awesome technical report, because now you can just bullet point, list things from the report from top to bottom to just share with everybody. Right Wrong, that is the wrong approach to reporting out results from your tests, from your surveys, from anything that you've done in the lab, anything that you've studied. You have recommendations and people need to give input on those recommendations to make a decision. So we don't want to start from the top of our technical report and then just report or copycat or re-blurb everything that's in the report. The report's its own thing. We're done with that. We've got it. We need to do something different when we're presenting. So what do we do? I'll talk more about it after this brief introduction.
Speaker 1Hello and welcome to Quality During Design, the place to use quality thinking to create products others love for less. I'm your host, diana Deeney. I'm a senior level quality professional and engineer with over 20 years of experience in manufacturing and design. I consult with businesses and coach individuals and how to apply quality during design to their processes. Listen in and then join us. Visit qualityduringdesigncom.
Speaker 1We have all been there in those meetings. We may even have facilitated or presented this way in different meetings, but we have important things we want to share. So we list out everything in a bunch of words and bullet points on a presentation and then we might read from the presentation while it's being shown to everybody and we're asking no-go phase, where you're deciding if you want to continue or if you just want to cut off the project. In any case, these meetings are sort of important and you may have a wide variety of people that you are talking with, that you're trying to communicate with. They may not all be engineers and you're doing your engineering things. So you need to be able to communicate your ideas well and you want the team to make informed decisions based on everything that you've been learning and studying and testing for, and studying and testing for. So the worst thing that we can do for ourselves and our team is to write out a bunch of words on a PowerPoint and read from it to present our technical information. It's just not a good way to go about it.
Speaker 1As I mentioned in the introduction, you've already written up a report, or at least you should have a technical report that outlines what you did and that will be for posterity's sake for as long as the project is in existence. After the project is closed, you've tidied up and presented all your information in a technical report with all of the data and all the background. Good for you, that's a good thing to do and it's an important thing to do. So it's good that you did it. But now you're being asked to present all this technical information. The way to do it is an assertion evidence model. This assertion evidence model was published about after I graduated, but it came from my alma mater, penn State, so that was a little bit of a Penn State pride there. But the assertion evidence model means that you are Write down your recommendation at the top of the PowerPoint slide in a complete sentence, no partial sentences, no bullets.
Speaker 1Write it out in a complete sentence and then support that with some sort of graphical proof or related graphic that shows your data or that shows the results of your data. So you're making an assertion at the top of the slide and underneath it you're providing the evidence to back up your assertion. So that's how you're going to present your recommendations. But then you can't just invite everybody to come in and then expect them to be caught up to the point where you are and catch up to what it is you're doing and your ideas. You need to kind of warm everybody up to where you are in this whole process, your whole learning journey and why you're coming up with these recommendations. You need to give them some perspective. You need to describe the problem, reiterate the problem that you're trying to solve or the questions that are left unanswered, and you want to review the principle of why you're doing it. What's the criteria against which you're measuring these kind of things against which you're making recommendations? So these two ideas the assertion evidence model and then introducing the topic in a way that gets everybody up to speed and on the same page I combine them into what I call the six P's the perspective, the problem and the principle are the first three that we want to get into with our team, and then the next three is the proposal, the proof and the process, and we repeat the proposal, proof and process for as many recommendations or proposals that we have.
Speaker 1The proposal is our ending recommendation, our conclusion, our proposal of what it is. We've learned from what we've been studying. The proof is the graphical evidence that supports our recommendation. I say graphical evidence, but it could also be photographs, anything visual that helps communicate the data and information that backs up your proposal. Those two things are on a PowerPoint, on the screen, and while it's on the screen, you're going to talk about the process that got you to that recommendation. What tests did you perform? What was the scope of your testing? Were there any exceptional conditions? When you use this method, you're going to be promoting learning among everybody that is at your meeting and you're going to be promoting discussion and dialogue for everyone to make an informed decision. Now here's why this works and this method is backed up by a lot of studies from psychologists and sociologists and engineers on what works and what doesn't work and how people learn.
Speaker 1I started off the topic by saying that we have a lot of bullet points on a PowerPoint presentation and we're just reading from it, or maybe we're talking over it, elaborating on some of the points that are on the board or are being displayed for everybody. This is a problem with people understanding what it is we're trying to communicate. They get hung up because of cognitive overload. It's a limitation of being a human being. What's happening here is our audience is trying to both read and listen, even if it's the same thing, and they experience cognitive overload and their comprehension rate of what it is that you're trying to communicate drops very low.
Speaker 1Also, when we're using bullet points, we tend to abbreviate sentences. We don't write out complete sentences. Abbreviate sentences we don't write out complete sentences and sentence fragments also decreases learning because it's not showing connections among the details that we're listing on our PowerPoint slide. So now we have reading and listening and then also trying to decipher these abbreviated sentences and trying to make connections between all these different levels of bullet points. It's a cognitive overload and it doesn't work. So that's why we don't want to create recommendations with a bunch of wordy bullet points and talk to them, because our team isn't going to get it. They're not going to understand. So then we think, all right. Well, if it's too many words, maybe I'll still include the words so that I can remember what I'm supposed to say, but I'll also include a picture. So now we're trying to communicate our recommendations with a lot of words, sentence fragments which are still a problem and also a graphic. But this is no good either. Now we have a redundancy effect going on when there is unnecessary duplication of the same information using different modes of presentation.
Speaker 1What's happening here is that there are actually three tracks of information that our audience is trying to interpret all at once. We're talking, they're reading bullet points and trying to decipher connections and understand what is written there, and there's now also a graphic and they're trying to tie it all together and it's just not a good mode for people to learn against and we want our audience mode for people to learn against, and we want our audience, our team members, to learn what it is we did in the lab so they can make an informed decision. So this model is not good either. Now, graphics is a good thing. In fact, people learn better from graphics and narration than from graphics, narration and printed text, and that's because of the principle of multimedia, which is that audiences learn more effectively from words and pictures than from just words alone. In fact, with the audiences that participated in these kind of presentations, there was 28% more information that was learned and they could apply 79% more creative solutions with what they learned. So therefore, we want to include relevant visuals, be photos, drawings, diagrams, graphs, even films. This makes sense. Think of a movie, think of a documentary movie. I really enjoy Nova on the PBS public broadcasting station and I also enjoy National Geographic documentaries. In this case, they're combining a video with somebody talking about what's happening in the video, and I tend to remember and learn a lot from those types of shows, and that's because of the principle of multimedia.
Speaker 1There is a fallacy associated with this. It's called the pipeline fallacy. With a pipeline in mind, we assume that our audience are going to get whatever we deliver to them, but just because we showed it and presented it doesn't mean that they understood it and received it. When we say things like well, we show them the facts, but they just didn't get it, or the presentation went right over their heads, it's probably because of this pipeline fallacy. We're showing too much at once. We need to focus in on a particular recommendation or proposal or result instead and that's why the proposal, proof and process method works A complete sentence with an assertion of what it is we're trying to communicate, showing graphically the proof that backs up that statement, and then talking about the process that we use to get there, maximizes the learning opportunities of our fellow human teammates. Because when we're giving our presentation, that's what it's all about. It's all about communicating to our audience. It's less about our studies and our technical information, and it's all about communicating and helping other people learn what we've learned.
Speaker 1Now you did this technical report and it's something that's going to be added to the file and people are going to be reading it and reviewing it. This is something that you can reference while you're presenting things. Discussion point comes up, if a question comes up. Everyone in the meeting has access to or has a copy of the technical report. Maybe they read it ahead of time, maybe you left a few minutes at the beginning of the meeting to read it, but in any case, as you're giving your presentation, you can refer to your technical report for some of the detailed information. But maintaining the proposal, proof and process method will help your team to decipher and understand the information better, so you can have better discussions about what to do with that information.
Speaker 1Presentations have advantages, specifically interaction and communication with whoever's there, so you can gauge how deep you want to go into an explanation based on their questions and their expressions. Don't just stick with questions that are posed pre-meeting. If it's topical, maybe someone thought they knew something but then realized that they hadn't. If they have a question about something, don't say wait, I'm going to get to that point later. Go ahead and go over that point, skip ahead, refer to the report. And another thing is that you don't have to rely on a PowerPoint presentation for your visual aid. In a report, you're stuck with graphs and photographs, but in a presentation you can use still images, film demonstrations, models, hands-on things. You are less limited when you're in a presentation. Now I've said that this is all for the audience and communication, but there are some selfish reasons to use this method also Because just preparing the presentation like this is going to solidify your ideas and may lead to new insights.
Speaker 1I volunteer for technical conferences. I review students' papers and provide feedback on them, and these are technical papers. I also just finished up with a conference in DC where there were a lot of students' presentations given A common thing that I've seen and I've, honestly, I've experienced this myself with my own things is that we start off really strong. We have a good introduction, we have a good problem statement, we go over our process and then, by the time we get to the results and the conclusions and the recommendations, things just kind of I don't know they fizzle out by preparing our presentations in this proposal, proof and process method. It's really forcing us to focus on the recommendations. What did we learn? What are the next steps that we need to take? What are the questions that we need to have answered? In preparing a presentation in this way, you may find you need to go back and revise your report and make it more clear, make it more definitive on the results.
Speaker 1One last recommendation I want to give to you when you're preparing for these presentations, I want to give you a little more confidence in being the presenter. Really. Your team is there not to judge your presentation skills but to learn more about this project so that they can be better informed. They're looking to you to learn information. They're not looking to you to perform a master's class and how to present. You're not in sales and marketing. You're not being customer facing. Your presentation is really for your team to learn information, and the more that you can do to help them learn the information and become part of the discussion, the more they will appreciate your efforts.
Speaker 1I know sometimes it can feel daunting, like you're in a dog and pony show that you need to put on a show for everybody, but they're really not there to be entertained. They're there to learn and you are in a great position to be able to share with them what you know. My point is this be confident in why you're there and what you can do for your team and don't worry about being a master presenter, because you yourself and what you know and what you've learned, that's enough. So what's today's insight to action? You can follow my six P's. It helps me when I'm trying to put together a presentation. Again, the first three P's have to do with helping our audience gain some perspective about what it is we're doing and reiterating what the problem is, what it is we're trying to solve, and the principles, the scope and the criteria against which we're measuring success. And then, for each result that we have, each conclusion point or recommendation, we have a proposal in a complete sentence. We show the proof in graphical or visual form and we talk about the process that got us there.
Speaker 1This all uses proven techniques for enhancing the learning and information sharing and communication within people and within teams. So, as we're entering into this season of presentations, give it a try. Challenge yourself to do a little bit better at sharing your information, because it's important and your team needs to know it. Please visit qualityduringdesigncom On the podcast blog for this episode. I'll list some of the resources that I reference about how people learn and, if you'd like to, you can look into more of it yourself. This has been a production of Dini Enterprises. Thanks for listening. Thank you.
Podcasts we love
Check out these other fine podcasts recommended by us, not an algorithm.
Speaking Of Reliability: Friends Discussing Reliability Engineering Topics | Warranty | Plant Maintenance
Reliability.FM: Accendo Reliability, focused on improving your reliability program and career
Reliability Hero
MAINSTREAM Community
Manufacturers Make Strides
Martin Griffiths
The Manufacturing Executive
Joe Sullivan
The Antifragility Reframe
Dr. Frank L. Douglas
The SAFE Leader with Mark McBride-Wright
Mark McBride-Wright
Coaching for Leaders
Dave Stachowiak