Beyond Requirements: How Quality Methods Provide Actionable Design Inputs

Every product designer knows that critical moment when you must shift from understanding customer needs to actually engineering solutions. It's where the magic happens—and where many projects stumble.

After a week of concept development with your team (customer evaluations, benefit analysis, symptom ID, and process mapping), you've gathered valuable insights. But how do you transform this mountain of information into concrete technical requirements? 

Quality tools transform the concept-to-design transition from a jarring handoff to a smooth, continuous conversation with your cross-functional team. In translating concept development ideas into design inputs, you'll create products that truly solve problems and delight users—with less rework and fewer costly changes later in development. 

Ready to bridge the gap in your next design project? Visit the podcast blog and links to other episodes.

Work with Dianna I help product development teams build quality into the front end when it's cheap and easy, not late when it's expensive and painful. 

Book a 20-minute discovery call with Dianna's calendar. Whether you're navigating the "fuzzy front end" of product development and want to explore a workshop or advisory partnership, or you'd like to be a guest on this podcast. You'll leave with a summary, relevant resources, and a clear path for next steps within 24 hours. 

Pierce the Design Fog (piercethedesignfog.com): my book on aligning cross-functional teams, defining clear design inputs, and accelerating product success. NIEA Finalist Award, reviewed by PDMA. "Great for fans of Tony Fadell’s Build, David H. DeWolf and Jessica S. Hall’s The Product Mindset."-BookLife Reviews (Publishers Weekly)

Connect with me: I'm most active on LinkedIn. 

Free Resources for Subscribers Subscribe to the Quality during Design digest — https://newsletter.deeneyenterprises.com — for monthly actionable highlights, plus access to the Strategic Quality Integration Checklist (a free self-assessment download) and my Swipe File Vault.

Transcript

Copy

Introduction to Concept Development

Speaker 1 0:00

Welcome to the Quality During Design podcast . I'm your host , diana Deeny . In the last few episodes , the last six or so in our current season , we've been talking about concept development . This is that early phase of product development where we're still staying in the problem space to discover more about our customers and what our targeted benefits are going to be of this new product . We really haven't started engineering solutions yet . We're working with our cross-functional team and gathering information about customer benefits , potential problems and symptoms they may experience that we want to have them not experience , and then also looking at the general use process how generally at a high level , they're going to get from A to B without defining the actual functions of whatever it is we're designing , because we haven't designed it yet . Well , now we're at that point in the process where we have all this information and we've done it in a way that we're driving toward engineering design inputs , but we haven't really developed the engineering inputs yet . Now we're starting to move into the solution space , where we're starting to engineer solutions and actually design a product , and this is where engineers really shine and where engineers really like to work . But that doesn't mean that there aren't some quality tools or methods that we could use to make that work a little bit easier and more meaningful , and it all has to do with what we need to learn for design , so let's talk more about it after this brief introduction .

Speaker 1 1:41

Hello and welcome

Moving into the Solution Space

Speaker 1 1:42

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 2:13

We're at the point in product development in our short series that we've been working on here . We're at that point where we're starting to want to engineer solutions , actually design something that our customers will use , the thing that we're going to sell , and we're basing our decisions on all that co-work and teamwork that we did early in concept development , when we learned more about the customer , the use environment , their use scenario , the benefits we want to target , that we want our customers to realize and the problems that we want to stay away from , and what actually adds value to the customers in their journey from point A to B when using our product . That is a whole lot of information and even though during concept development , we've worked with our team team and we've used their help to prioritize these targets , that's still a lot to wrap our arms around to pull it into design . A lot of the things that we've learned we can apply to design , but we don't just have to rely on our memories and to jump from our concept development idea to an actual design input that we can start building things from . There are tools that we can use to help us get there , and they're specifically quality engineering and reliability engineering tools . These tools can bridge that gap . They can help you think through how you want to implement concept development into an engineering design , and they can also be used iteratively , so it's not like you do it once and then you're done . You can keep coming back to it as you need to . So think of concept development as just the start of the conversation and we can use the results at concept development as a starting point for other analyses that are going to help us .

Using Quality Tools for Design

Speaker 1 4:14

We're extending concept development into the design space , getting more into technical design inputs . Information from our concept development work can help us answer these types of questions . What are the priorities of these distinct features and capabilities ? How many samples do we need to test ? Where do we need to work with our suppliers to better control quality ? What customer service capabilities do we need to change to best support our customers with this new product overall ? These are the kind of questions we can answer about our design , given the work we've done with our team in concept development . Some specific examples are we can improve the information from our benefits analysis that we did in concept into tree diagrams . These tree diagrams can help us develop vague drivers into specific design inputs . We use tree diagrams to help us think through what's important for design . So , for example and this would apply to most anything with our new product we want our unpacking method to be simple and we've identified a couple of things that we could do to provide that to our customers .

Speaker 1 5:28

In concept development , we can make it so that parts are unpacked from the box in the order of assembly , or the user can access the assembly instructions before unpacking the parts . And boy do I understand this one . Immediately , I had to buy a desk for one of my kids start of the school year , needed a new workspace and I opened the box and right there , like tucked in the corner , readily available , were the instructions . I really thought that was nice . Maybe it's because I'm an engineer and I appreciate those little thoughtful things , but that can be something that is really meaningful to your customer but isn't difficult for you to do . It's just recognizing that you want to be able to provide that and being intentional with it . That's how concept development helps . So let's focus on that instructions part .

Speaker 1 6:23

We can use a tree diagram to help us figure out . You know how it is that we want to do this for our customers . So we started with the tree , with a simple unpacking method and that , moved into , users can access the instructions before unpacking parts . Now there are a couple of options we can consider for our product design . One is that the assembly instructions are available before the parts are unpacked . This is a great example of a design input because it answers what about the product ? Another option we considered was the assembly booklet is in the top of the first box and this is okay . But we don't really want to target that as a design input or design requirement , I should say , because it answers how , not necessarily what . So a tree diagram can help us map out these different design requirements from concept to design inputs . I mean , if the design drivers from concept development are straightforward , we may not need a tree diagram . We can also combine benefit features that we've found during concept development with design inputs in our solution space using matrices , quality function deployment , which is a whole system in and of itself that if your company isn't set up to be able to support that , it may be difficult for you to do the whole quality function deployment . But we can certainly borrow ideas from it for us to develop design inputs and requirements from concept development .

Tree Diagrams for Design Requirements

Speaker 1 8:14

Because a house of quality matrix really combines two different kinds of matrices . One is an L-shaped matrix where we list features by row , ordered by customer satisfaction priority , and in the columns are our drivers or design inputs and potential design requirements . And where they intersect is where we evaluate the strength of the relationship between the features and the design inputs . So we categorize them as strong , medium or weak in the relationship matrix part of our house equality . In the triangle part it's called a roof shape matrix . You're comparing design inputs and requirements with each other . So you're comparing the columns against each other and looking at the correlation matrix , which is the body of the roof , to determine what kind of relationship those design inputs and requirements have to each other .

Speaker 1 9:14

So , really , the reason to build this out is to examine results in order to make choices about our design . We examine the rows . Are there any empty rows ? Are there any rows that don't have any relationship to the requirements that we're looking at ? Well , that could be a problem . Are there any two rows that are exactly the same with the relationship to requirements ? Well , that might indicate something we need to take a closer look at . Also , are there some sort of features and rows that don't have any strong relationship to a column , to an input ? That could also be a problem . Then we look at the column itself with our design requirements . Are there any columns that don't have any relationship to the inputs ? How are those relationships ? Are there some proposed requirements that have a lot and some don't have very many , or weak ones ?

Speaker 1 10:13

These will also help you prioritize . We can also compare the roof of the matrix and then just examine the matrix overall . These matrices really help us to evaluate our features and our design inputs , including the quality and cost of what it is we want to implement . So we can make sure our inputs are covering our features and we can prioritize them by considering both customer satisfaction ratings and the strength of their associations . These matrices

Matrices and Customer Satisfaction Analysis

Speaker 1 10:44

can also help us refine the design inputs . Can we group some if they're similar ? Can we eliminate others because they're unnecessary ? So tree diagrams and matrices are both quality tools that can be used to help us further develop the customer benefits we identified and prioritized in concept development and translating them into design requirements , design inputs , technical requirements , when we're talking about symptoms that our customers may experience if something goes wrong , we can further analyze that as part of a risk analysis and use a system FMEA and from there , if we want to , depending on what's the priority from those things , we can do a design FMEA process , fmea or a fault tree analysis and same with a process flow chart .

Speaker 1 11:38

In concept development we mapped out a high level process that our customers might take and we did some analyses with it . We identified what was critical to quality , what's value added . We looked at who's doing what and what steps we want to add and their priorities . Well , from that we can further evaluate that for design inputs using a task analysis and a task analysis used together with a PCA framework , a perception , cognition and action framework , it helps evaluate how our customers are interacting with the outputs of our process and what they're doing . That's an input to ours what kind of failures could happen and what we could do to control those . That directly affects our design decisions . But we can further analyze it more into poke-y-okay methods or mistake-proofing or evaluating that further in a usability FMEA .

Speaker 1 12:35

Now we don't need to do all of this on everything . The whole point is that we've gathered information at concept development and now we need to do something with it . So there are established quality engineering and quality tools that can help that process in getting from concept development

From Concept to Final Design

Speaker 1 12:55

into design inputs , because it's not like we just forget about what we did during concept development . We want to continue the conversation with our cross-functional team through the rest of product development and at the end of concept development . We haven't wasted or completely signed off the work our concept team did . We continue to use it to help make decisions about the functionality and performance of the product itself .

Speaker 1 13:20

The results from concept development help us to focus on what matters most . So in deciding what next steps you want to take or what quality engineering tool would work best for you , we need to decide what we must learn and then continue to refine that , as we need Analyzing those customer experiences at concept , with the benefits , the symptoms , the use process . It provides rich , prioritized data that directly translates into actionable design inputs . If you want to learn more about how to do this , please sign up for the newsletter . Visit newsletterdenienterprisescom that's D-E-E-N-E-Y enterprisescom . Or visit qualityduringdesigncom and you'll get pushed to the Dini Enterprises website . This has been a production of Dini Enterprises . Thanks for listening .