Quality during Design
Quality during Design is a production of Deeney Enterprises, LLC. It is a podcast for product designers, engineers, and anyone else who cares about creating high-quality products. In each episode, we explore the principles of quality design, from user-centered thinking to iterative development. We introduce frameworks to make better design decisions and reduce costly re-designs. We explore ways to co-work with cross-functional teams. We also talk to experts in the field about their experiences and insights.
Join host Dianna Deeney in using quality thinking throughout the design process to create products others love, for less. Whether you're a seasoned designer or just starting out, looking to improve your existing designs or start from scratch, Quality during Design is the podcast for you.
Quality during Design
Design to Avoid Problems: Focusing on Symptoms Early On
Ever stood in that devastating moment when customers finally interact with your nearly-finished product only to hear them say, "I don't like that" or "This doesn't work for me"? After months of development and what you thought was adequate customer engagement, these late-stage revelations can send you spiraling back to the drawing board, costing time, money, and team morale.
This episode dives deep into why this painful scenario happens even to the most diligent product development teams and offers three powerful strategies to prevent it.
- First, we explore the concept of the "problem space" - that crucial period between identifying a customer problem and jumping to design solutions.
- The power of cross-functional collaboration forms our second focus. These varied viewpoints collectively create a comprehensive understanding that helps identify potential issues much earlier.
- Our third strategy introduces the concept of "symptoms" - what customers experience when there's an unintended output or event with your product. By intentionally exploring these possible negative experiences during concept development, teams can make informed design decisions that prevent or mitigate problems before they materialize in the final product.
Ready to transform your product development approach? Start with these strategies on your next project and watch how they reduce those heartbreaking late-stage discoveries. Your customers—and your future self—will thank you.
Other podcast episodes you may like:
Uncovering Customer Desires: Understanding Benefits in Concept Development
The Hidden Costs of Poor Concept Development in Product Design
DISCOVER YOUR PRODUCT DEVELOPMENT FOCUS: UNLOCK YOUR IMPACT
Take this quick quiz to cut through the 'design fog' and discover where your greatest potential lies
BI-WEEKLY EPISODES
Subscribe to this show on your favorite provider and Give us a Rating & Review to help others find us!
NEWSLETTER
Subscribe to get updates: newsletter.deeneyenterprises.com
SELF-PACED COURSE FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling students now. Join over 300 students: Click Here.
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.
Welcome to the Quality During Design podcast. I'm Diana Dini. Picture this you're at the end of a product development cycle and you're watching a customer interaction with your new product design. It's one of many, because you've been inviting the customers to interact with you and your team, try out ideas, give their feedback. All along the product development process, even before you started designing things, you involve the customer. But now that the customers have something in their hands, you're hearing things like this. I don't like that. The way that works doesn't work for me. I wasn't expecting that to happen. And they're saying that in not a good way, not a pleasantly surprised way, and your engineering mind starts solving the problem. And, oh my gosh, to fix it would mean a major redesign. You wish you knew about this stuff earlier. Why didn't it come up in all of those other interactions that we had with our customers and what can we do differently next time? Let's talk more about it after this brief introduction.
Speaker 1:Hello 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. Welcome back.
Speaker 1:We're talking about how customers don't like our stuff and that can be really disappointing, especially if we've been working hard to involve them in our decision making process all along. Sometimes we don't do enough of that customer interaction early, or often enough in our product development lifecycle, and sometimes that can be hard to gauge. Sometimes it's built in and our customer facing teammates have a lot of contacts that are willing to talk and work with us. Sometimes it's not so easy, but in any case, we're at this point near the end or what we thought was the end and we're getting a lot of negative feedback as engineers working in product development. What can we do about that? There's three major areas where I can see that, no matter what product development style or process that you have, there's three basic things that we can do for ourselves and our team in our new product development life cycles to avoid this.
Speaker 1:Learning about problems really late. Even if we do these things, we may still find out problems really late, but we're going to significantly reduce the chances of that happening. So for one, did we jump from idea to solution too soon. Did we skip the problem space and not do enough concept development? I've been talking a lot about concept development in the last few episodes. That's that fuzzy front end of product development and it lives between hey, we have a product idea to hey, let's build this thing that I've come up with. I call it fuzzy because it's not really clear what we're doing yet.
Speaker 1:And within concept development is what I call the problem space. Yes, we've already identified a problem, a problem that our customer has, that we want to solve with our product. That's our product idea. But then we jump right from that into designing stuff because, I don't know, it's fun, that's what we like to do. We like to design things, but we skip that middle step, which is where we want to question and investigate a little bit more about the problem, better understand the problem so that we can develop designs that better fit the needs to solve the problem for our customers. So that's number one.
Speaker 1:Maybe we didn't stay in the problem space long enough to question, investigate and really understand what the true problem is. The other part of that is if we did stay in that problem space and try to do extra work to understand our customers, their environment, the kind of choices that they need to make and what their real problem is, and their customer journey, where they're starting and where they want to end. If we did do that, did we do it solo or did we do it with our team and some customers involved too? If we did it solo, we're missing out on some of those aspects of teamwork and cross-functional teamwork that we can really benefit from when trying to understand the concept space. First of all, people from different departments are going to come at the same problem with a different viewpoint. They may understand the customers a little differently than we do. They have a different background on what's going on in the environment and, especially if we get our customers involved, they have their own particular knowledge base and information and viewpoints that they're going to bring to better understanding this problem space. We can work with all these people to better question and investigate these problem space and really bring clarity to what it is that we're developing. They bring a lot of value. I covered that in a previous episode also. Now maybe you're saying, diana, I already know all this. We spend a lot of time in concept development. We work together with our team and I'm still having this problem.
Speaker 1:The third thing that's important is being intentional about finding potential symptoms. Yes, we got together, we got better clarity, we got some customer feedback, but did we intentionally look for and ask about the things that are a pain or, within this concept space, we have a general idea of what our product is going to be? What are some of the things that could go wrong that they would find really annoying? In a previous episode, I talked about finding benefits, the things that are really going to delight our customers. Well, the other part of that is the symptoms, the things that don't delight our customers and, in fact, just really turn them off. In this context, symptoms are what customers experience when we have unintended output or event. When we have unintended output or event In concept development, we can think of whatever it is that we're developing as a system a input, a black box and an output. Except our outputs are divided into two One is benefits, where things go right, and one are symptoms, when things go wrong, and we're looking at this at a high level from our customer's point of view.
Speaker 1:Now, a failure may cause this unintended output in our product. A mistake could be made in its use, or it could be just an event in our environment. It's a negative experience for our customers. We want to examine those potential negative experiences so we can eliminate, reduce or otherwise control them from happening with our design choices. If possible, we can word a symptom statement like this Our customers may lose product features or be challenged, which leads to them experiencing this negative impact.
Speaker 1:You may think that this sounds a lot like failures and hazards, but symptoms, failures and hazards are different things. Remember, we're in the fuzzy front end of concept development and failures are specific to the product that we haven't developed yet, so it's too soon to list those. We don't have functions and failures. However, after we've collected ideas about design inputs through the concept space, we'll likely have much more clarity about our concept design. That's when we can start. Things like FMEAs or other risk analyses will help us make us more design decisions and prioritize decisions. It's too early for failures.
Speaker 1:What about hazards? Hazards are top-down negative events that are beyond the scope of the concept space, our customers' experiences. Risk evaluators usually categorize hazards as things like biological hazards, physical hazards and safety hazards. Your industry may use different categories specific to your product type and use environment. There are hazard analyses that focus on what could go wrong and include sources of hazards and their causes. They're used to identify risk controls, which may include some design choices, but identifying sources of hazards is beyond the scope of the concept space.
Speaker 1:In the concept space, we're developing a concept design that's focused on the user's experience with our product. We're not looking to identify hazards. Rather, we're looking for potential experiences that make our users unhappy. This is why we want to align our idea of symptoms with a customer complaint, want to align our idea of symptoms with a customer complaint. In fact, that's a great way to think about symptoms. You can imagine what kind of complaints that they're going to make with your product once it's released. Those are the symptoms that we can focus on early in concept development to be able to make design decisions against. So remember at the top of our episode, we were really disappointed in what our customers were saying about our product design and wondering if it's something that we need to go back to the drawing board or redesign. It's extremely disheartening and disappointing when that happens. That's why we need to do as much as we can earlier, understand as much as we can, as often as we can or as soon as we can so we can make those design decisions, design trade-off decisions, implement risk controls the things that are not only going to delight our customers but prevent them from complaining or experiencing negative things with our products. Being intentional about looking for and evaluating symptoms in concept development can help give us more information to be able to better design, to apply quality during design.
Speaker 1:When you're further along in your product development process and it's after concept development and you're ready to start FMEA, consider taking my course in Udemy. It's called FMEA in Practice, from plan to risk-based decision making. It's hosted by the Manufacturing Academy. You have lifetime access and Ray Harkins and I are available to answer questions. We're the instructors for the course that actively support you as a student. I'll include a link in the show notes. This has been a production of Dini Enterprises. Thanks for listening, thank you.
