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.

JOIN ME ON SUBSTACK Subscribe today. Get themed Q&As, live chats, in-depth analysis, comprehensive guides, and access to my Strategy Vaults. Founding Member spots are open now.

PICK MY BRAIN Got a particular problem you’d like clarity on? Schedule a 60-minute virtual call with me - we’ll work through it together.

ENROLL IN MY COURSE FMEA in Practice: from Plan to Risk-Based Decision Making is enrolling now. Lifetime access, practical tools, and over 300 students already learning.

GET THE BOOK Pierce the Design Fog is your playbook for concept development to engineering design inputs.

VIEW MY OTHER SERVICES Visit my website to learn more.

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.

Episode Transcript

Speaker 1 (00:00):
Welcome to the Quality During Design podcast.
I'm your host, diana Deeny.
In the last few episodes, thelast six or so in our current
season, we've been talking aboutconcept development.
This is that early phase ofproduct development where we're
still staying in the problemspace to discover more about our
customers and what our targetedbenefits are going to be of

(00:22):
this new product.
We really haven't startedengineering solutions yet.
We're working with ourcross-functional team and
gathering information aboutcustomer benefits, potential
problems and symptoms they mayexperience that we want to have
them not experience, and thenalso looking at the general use

(00:43):
process how generally at a highlevel, they're going to get from
A to B without defining theactual functions of whatever it
is we're designing, because wehaven't designed it yet.
Well, now we're at that pointin the process where we have all
this information and we've doneit in a way that we're driving
toward engineering design inputs, but we haven't really

(01:06):
developed the engineering inputsyet.
Now we're starting to move intothe solution space, where we're
starting to engineer solutionsand actually design a product,
and this is where engineersreally shine and where engineers
really like to work.
But that doesn't mean thatthere aren't some quality tools
or methods that we could use tomake that work a little bit

(01:28):
easier and more meaningful, andit all has to do with what we
need to learn for design, solet's talk more about it after
this brief introduction.
Hello and welcome to QualityDuring Design, the place to use
quality thinking to createproducts.
Others love for less.
I'm your host, diana Deeney.

(01:50):
I'm a senior level qualityprofessional and engineer with
over 20 years of experience inmanufacturing and design.
I consult with businesses andcoach individuals and how to
apply quality during design totheir processes.
Listen in and then join us.
Visit qualityduringdesigncom.

(02:12):
Welcome back.
We're at the point in productdevelopment in our short series
that we've been working on here.
We're at that point where we'restarting to want to engineer
solutions, actually designsomething that our customers
will use, the thing that we'regoing to sell, and we're basing
our decisions on all thatco-work and teamwork that we did

(02:33):
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 wantour customers to realize and
the problems that we want tostay away from, and what
actually adds value to thecustomers in their journey from

(02:54):
point A to B when using ourproduct.
That is a whole lot ofinformation and even though
during concept development,we've worked with our team team
and we've used their help toprioritize these targets, that's
still a lot to wrap our armsaround to pull it into design.
A lot of the things that we'velearned we can apply to design,

(03:25):
but we don't just have to relyon our memories and to jump from
our concept development idea toan actual design input that we
can start building things from.
There are tools that we can useto help us get there, and
they're specifically qualityengineering and reliability
engineering tools.
These tools can bridge that gap.

(03:46):
They can help you think throughhow you want to implement
concept development into anengineering design, and they can
also be used iteratively, soit's not like you do it once and
then you're done.
You can keep coming back to itas you need to.
So think of concept developmentas just the start of the
conversation and we can use theresults at concept development

(04:09):
as a starting point for otheranalyses that are going to help
us.
We're extending conceptdevelopment into the design
space, getting more intotechnical design inputs.
Information from our conceptdevelopment work can help us
answer these types of questions.
What are the priorities ofthese distinct features and
capabilities?

(04:30):
How many samples do we need totest?
Where do we need to work withour suppliers to better control
quality?
What customer servicecapabilities do we need to
change to best support ourcustomers with this new product
overall?
These are the kind of questionswe can answer about our design,
given the work we've done withour team in concept development.

(04:50):
Some specific examples are wecan improve the information from
our benefits analysis that wedid in concept into tree
diagrams.
These tree diagrams can help usdevelop vague drivers into
specific design inputs.
We use tree diagrams to help usthink through what's important

(05:13):
for design.
So, for example and this wouldapply to most anything with our
new product we want ourunpacking method to be simple
and we've identified a couple ofthings that we could do to
provide that to our customers.
In concept development, we canmake it so that parts are
unpacked from the box in theorder of assembly, or the user

(05:36):
can access the assemblyinstructions before unpacking
the parts.
And boy do I understand thisone.
Immediately, I had to buy adesk for one of my kids start of
the school year, needed a newworkspace and I opened the box
and right there, like tucked inthe corner, readily available,

(05:57):
were the instructions.
I really thought that was nice.
Maybe it's because I'm anengineer and I appreciate those
little thoughtful things, butthat can be something that is
really meaningful to yourcustomer but isn't difficult for
you to do.
It's just recognizing that youwant to be able to provide that
and being intentional with it.
That's how concept developmenthelps.

(06:20):
So let's focus on thatinstructions part.
We can use a tree diagram tohelp us figure out.
You know how it is that we wantto do this for our customers.
So we started with the tree,with a simple unpacking method
and that, moved into, users canaccess the instructions before

(06:40):
unpacking parts.
Now there are a couple ofoptions we can consider for our
product design.
One is that the assemblyinstructions are available
before the parts are unpacked.
This is a great example of adesign input because it answers
what about the product?
Another option we consideredwas the assembly booklet is in

(07:01):
the top of the first box andthis is okay.
But we don't really want totarget that as a design input or
design requirement, I shouldsay, because it answers how, not
necessarily what.
So a tree diagram can help usmap out these different design
requirements from concept todesign inputs.

(07:24):
I mean, if the design driversfrom concept development are
straightforward, we may not needa tree diagram.
We can also combine benefitfeatures that we've found during
concept development with designinputs in our solution space
using matrices, quality functiondeployment, which is a whole

(07:59):
system in and of itself that ifyour company isn't set up to be
able to support that, it may bedifficult for you to do the
whole quality functiondeployment.
But we can certainly borrowideas from it for us to develop
design inputs and requirementsfrom concept development.
Because a house of qualitymatrix really combines two
different kinds of matrices.

(08:19):
One is an L-shaped matrix wherewe list features by row,
ordered by customer satisfactionpriority, and in the columns
are our drivers or design inputsand potential design
requirements.
And where they intersect iswhere we evaluate the strength
of the relationship between thefeatures and the design inputs.

(08:42):
So we categorize them as strong, medium or weak in the
relationship matrix part of ourhouse equality.
In the triangle part it'scalled a roof shape matrix.
You're comparing design inputsand requirements with each other
.
So you're comparing the columnsagainst each other and looking

(09:03):
at the correlation matrix, whichis the body of the roof, to
determine what kind ofrelationship those design inputs
and requirements have to eachother.
So, really, the reason to buildthis out is to examine results
in order to make choices aboutour design.
We examine the rows.
Are there any empty rows?

(09:25):
Are there any rows that don'thave any relationship to the
requirements that we're lookingat?
Well, that could be a problem.
Are there any two rows that areexactly the same with the
relationship to requirements?
Well, that might indicatesomething we need to take a
closer look at.
Also, are there some sort offeatures and rows that don't

(09:48):
have any strong relationship toa column, to an input?
That could also be a problem.
Then we look at the columnitself with our design
requirements.
Are there any columns thatdon't have any relationship to
the inputs?
How are those relationships?
Are there some proposedrequirements that have a lot and

(10:10):
some don't have very many, orweak ones?
These will also help youprioritize.
We can also compare the roof ofthe matrix and then just
examine the matrix overall.
These matrices really help usto evaluate our features and our
design inputs, including thequality and cost of what it is
we want to implement.

(10:31):
So we can make sure our inputsare covering our features and we
can prioritize them byconsidering both customer
satisfaction ratings and thestrength of their associations.
These matrices can also help usrefine the design inputs.
Can we group some if they'resimilar?
Can we eliminate others becausethey're unnecessary?
So tree diagrams and matricesare both quality tools that can

(10:56):
be used to help us furtherdevelop the customer benefits we
identified and prioritized inconcept development and
translating them into designrequirements, design inputs,
technical requirements, whenwe're talking about symptoms
that our customers mayexperience if something goes
wrong, we can further analyzethat as part of a risk analysis

(11:21):
and use a system FMEA and fromthere, if we want to, depending
on what's the priority fromthose things, we can do a design
FMEA process, fmea or a faulttree analysis and same with a
process flow chart.
In concept development we mappedout a high level process that
our customers might take and wedid some analyses with it.

(11:44):
We identified what was criticalto quality, what's value added.
We looked at who's doing whatand what steps we want to add
and their priorities.
Well, from that we can furtherevaluate that for design inputs
using a task analysis and a taskanalysis used together with a

(12:04):
PCA framework, a perception,cognition and action framework,
it helps evaluate how ourcustomers are interacting with
the outputs of our process andwhat they're doing.
That's an input to ours whatkind of failures could happen
and what we could do to controlthose.
That directly affects ourdesign decisions.
But we can further analyze itmore into poke-y-okay methods or

(12:29):
mistake-proofing or evaluatingthat further in a usability FMEA
.
Now we don't need to do all ofthis on everything.
The whole point is that we'vegathered information at concept
development and now we need todo something with it.
So there are establishedquality engineering and quality
tools that can help that processin getting from concept

(12:54):
development into design inputs,because it's not like we just
forget about what we did duringconcept development.
We want to continue theconversation with our
cross-functional team throughthe rest of product development
and at the end of conceptdevelopment.
We haven't wasted or completelysigned off the work our concept
team did.
We continue to use it to helpmake decisions about the

(13:17):
functionality and performance ofthe product itself.
The results from conceptdevelopment help us to focus on
what matters most.
So in deciding what next stepsyou want to take or what quality
engineering tool would workbest for you, we need to decide
what we must learn and thencontinue to refine that, as we

(13:37):
need Analyzing those customerexperiences at concept, with the
benefits, the symptoms, the useprocess.
It provides rich, prioritizeddata that directly translates
into actionable design inputs.
If you want to learn more abouthow to do this, please sign up
for the newsletter.
Visitnewsletterdenienterprisescom

(14:06):
that's D-E-E-N-E-Yenterprisescom.
Or visit qualityduringdesigncomand you'll get pushed to the
Dini Enterprises website.
This has been a production ofDini Enterprises.
Thanks for listening.