Welcome to the Quality during Design Journey! I'm so glad you decided to join me. There are a lot of things we're going to explore and many of them have to do with the use space or the concept space. This is an introductory lesson to the Quality during Design Journey and it's called "Engineering Products from a Concept Space".
There's a world of opportunity when it comes to design, but we're not designing products for the whole world. We're designing for a subset of that which I call the concept space. Sometimes we're brought in on a project at the beginning of the project and sometimes we are brought in on the middle of a project and we're given information about the use space that someone has already vetted for us.
During this time of design when we're trying to better understand the use space so we can start designing, we don't want to rely on wild guesses or our imagination: prototyping idea after idea only to have them shot down, scrapped or picked apart.
We also don't want to tie down or stifle our creative process because as engineers, we are very creative people. But when we get with our cross functional team and our customers, for one, we aren't quite sure what to ask them and we may not be quite sure what information we need. And on the other hand, they may not be sure what to tell us - what details are important? Something that seems obvious to them from their experience might be a revelation to design engineering.
What we don't want to do is design or engineer something that nobody wants or that might hurt someone.
What we want to do is develop ideas about a concept design with others.
Before we start engineering design or even conceiving of ideas, we want to understand the boundaries and expectations of this new product, which means understanding the concept space. We also want to facilitate some of the narrative and be involved in the concept discovery because we're actually gathering information that we'll need later for design and we want to gain an understanding of what is important and what's not important in the concept space.
We want to learn from our cross functional team about our product early in development and a lot of quality and reliability tools can help us do this. They help everybody get on the same page. They can also help us prioritize between decisions or compare ideas against each other, which idea is going to be better for our product design. In all we want to be innovative and creative with our engineering ideas and have them be successful.
Let's talk more about the concept space and how we're going to use it during the quality during design journey to prompt discussions, to facilitate all of those aspirations.
Here is what we're going to cover in this lesson.
- We'll talk about the concept space itself and how we can identify design inputs from it.
- We will also talk about why it's important to involve our cross functional team in early concept development and we'll look at what academics have to say about it.
- We'll discuss different quality and reliability tools that can help us explore the concept space with our team for those design inputs.
- And we're going to recognize that what's been done at concept doesn't have to stay in concept. We can iterate it throughout product development. So we continue to get value from it to be able to make informed design decisions.
- We will then talk about what to do next, which is the next step with the Quality during Design Journey.
What kind of design inputs can we gather when we're looking at the concept space? And even first, let's back up and say, what is the concept space?
What is the concept space?
We're all familiar with a black box model, we have an input, we have a system model or a black box in the middle that does something and then we have an output. We know it's not as simple as that. So we can capture some things that are more complicated about this model.
We can add conditions and assumptions about the inputs and we can break our outputs into what we intended to have happen and what we didn't intend to have happen, we could still get this model a little closer to reality if we add some feedback mechanisms, because there probably are some, there may also be some observable states, alarms or notifications that get fed back into the system or back to the inputs.
Now, this is more representative of a typical product design and it looks a lot like a P diagram, which is a tool we may use to help us with product design itself, understanding the nuances of our particular design.
What I want to do is I want to take a huge step back or earlier in the product development process from where we would typically use a P diagram. And I want to add the user experience, the customer experience to this model.
When we take a step back or zoom out to this highest level of product design, we're no longer focused on the design itself, but on the use space, the customer experiences and their environment. And this is what I refer to as the concept space.
- We want to evaluate the experiences that our users are having with our product on the output side of things. When our product does, the thing that it's supposed to do, our customers are experiencing a benefit of using our product. So we want to maximize those kind of things.
- When our product doesn't work like we intended or we had an unintended output, our users are experiencing the symptoms of a problem. And those are the kind of things we want to minimize, which we might be able to design out or avoid altogether.
- When the customers are using our product to get from where they start to where they end from input to output - they are taking steps of using our product. And with that, we really want to make it easy for them to use.
- And at the input side of it, where we have our assumptions and our understanding of the use environment, we also have our customer, they may be coming into this with their own assumptions and their own expectations.
So with product design, we really want to meet them where they are with each of these areas. We can get important design inputs and prioritize those design inputs to be able to make design decisions with it.
We already have customer needs - We need to search for more
When we start evaluating this concept space with our team, at this point in the project, a needs assessment was probably already done, an opportunity was already identified and a project started. Needs are gaps within the problem space. There are gaps that people in our target market have, whether they're really aware of them or not. We've already identified needs. That's what started this whole product development project. Our project goal is all about developing a product that our customers will use to be able to fill the need.
When we are looking to fill a need, we don't want to jump into design mode until we've really explored the concept space. We want to stay in search mode where we're finding problems and defining the use space.
- We'll be able to translate benefits to design inputs. So you can design what the customer wants.
- And we can examine symptoms of undesired outcomes. So we can design in risk controls and design out problems.
- We assess the use process of a concept. So you can design for humans, prioritize design ideas and mistake proof the process.
- We can vet solution ideas with the cross functional team so they can design for excellence.
We are really working from the outside in starting with the user and then developing that into design inputs for design.
So there are many design inputs that we can get from examining the concept space before we even start engineering solutions or features.
Why we explore the concept space with our cross-functional team
Now, let's talk about why we want to develop these early concepts with a team.
There's common challenges in design development and new product development has its own particular challenges too. Even with a cross functional team, there is concept development that's happening but there may not be a lot of concept development with engineers. Before they start prototyping, there could be unexpected failures late in the design and a mad rush at the end. This is what I hear from a lot of cross functional professionals people in marketing quality and reliability: "I wish the engineers had involved me earlier."
We can target an ideal design development, we can target it as a goal. And I understand that there are still challenges in any product development project that they're each unique. But we can target to have more concept development upfront with our cross functional team. Early failures of preliminary tests can prompt design improvements, not design concept changes. And we may have a steady development through engineering and test. And if we do, that means easier planning and more consistent activities reduced firefighting.
Academic people have studied it specifically, Robert Cooper projects are 3.3 times as likely to succeed with as he described "sharp fact-based product definitions before development begins." Product designs are twice more successful if the team does "solid upfront homework, doing the front-end activities well." There's also increased profitability with a more quality product: there's a perceived quality that customers will be willing to pay more for. And there's also quality built in that reduces the production cost. All of this can drive up the success of the design, the market shares and the profitability.
So if teams are not doing upfront concept work, and we know that upfront concept work is something that works for product development to lead to higher success, how do we do it? We can focus on concept development with our cross functional team with design engineers before we start engineering solutions because we're not just designing in a vacuum by ourselves, not if we want to design for excellence.
There are other people on our team that are going to be affected by the design that we come up with. They are our internal customers, they are our partners in product design. That said, all of these different people may have different goals and they may focus on their own particular part of the project or the product. Our goal as a product design engineer is to give them opportunities to talk together and with us, for us to gather design inputs. And that's really what we want are the design inputs.
Having structured working meetings is much better than sharing reports. We'll have easier buy in on design ideas because you made them part of the design process. We avoid surprises because we've verified and checked and left room to explore interpretations and hidden problems in the youth space. We've also identified more opportunities, we're getting design inputs, but the rest of the team is also getting the inputs they need.
In new product development, we can get stuck in a never ending loop and not really go anywhere or move forward. But evaluating the concept space, the users' experiences, with our cross functional team is a way for us to break into this loop and be productive and get the design inputs that we need for design engineering.
It's really our responsibility to ask because they are the internal customers or they represent our end users, which are our external customers. So how do we have these working meetings with the cross functional team for concept designs? We can use quality and reliability tools to have working meetings with our team. Some of the cornerstones of quality and reliability engineering are:
- risk based thinking and identifying ways to control risks
- being intentional with data, what's collected when and why
- bringing it back to people both internal and external customers and
- understanding variation and how it affects what we're trying to do.
More than that quality can be seen as a strategic asset for product design. And did you know that only 36% of our organizations view quality as a strategic asset a way to differentiate ourselves from what everyone else is doing. The rest of us see quality as a compliance activity or a continuous improvement or just as a way to fix problems and mitigate risks. But quality is a strategic asset to product development and we can use it proactively to help us improve the development process and get the inputs that we need from our team. You're making decisions daily about the product design itself and those decisions are coming from the information that you've already learned in order to gather and best gather the information that you need for product design.
You can use these quality and reliability tools to help you. They are a tool for you to use during product design. Quality and reliability engineering methods effectively prune the development process. They help teams uncover ideas and make decisions with data use risk-based thinking and consistently keeping the voice of the customer at the forefront. The team can cut off the development of ideas and development paths that are not going to contribute to a product that is safe, usable and dependable, which allows us to focus our efforts and resources on getting the product that fits the fruit of our labor. That's the best we could produce. And it starts with a strong concept development.
Quality tools in concept development
With the greater team, quality frameworks can help with structured conversations. These conversations could be exploratory or they could have specific goals or outputs. Team built graphical tools like flow charts and fish bone diagrams get everyone on the same page and help teams explore ideas and details. FMEA, five-whyss, and tree diagrams help to get to the root of potential issues.
They can also help clarify vague concepts. We may each have an idea of what we think the product should look like in the end. But with these tools, we can hash it out with our cross functional team and engineers from different backgrounds and different studies to work within the concept space.
- We first focus on the users and their use environment.
- We define what it is we want to learn.
- We choose a model and a team activity
- We work with the team, do the work with the team, and we use that information for design.
After we've done that we can consider modularity and interactions. The cross functional team has a lot of input into these aspects of design. And we can do that in a similar way.
These methods are also a little bit predictive we gather and use the information that we know to be able to predict what will happen with the product that we're developing. And we can use that information to help us with the product design.
Iterate and scale work at concept throughout development
Now that we've done this work with our team in early concept development, it doesn't just stay in development. We can iterate on it later to be able to make more design decisions as we know more about our product. And even as we're designing and testing our product quality and reliability techniques and tools can also be scaled. If something is more critical, we can do more with it, more analyses or a deeper analysis with that. But we don't have to go as far with everything and that could be dependent on the criticality, but it can also be based on the level of what we're looking at. We may look at the complete system versus subsystems and components. We don't have to do everything on everything we can scale our analysis to what's important and what we need to learn. We gather information at concept development and then we iterate on it and these analyses include prioritization. So we can focus on what's important and have information to be able to make trade off decisions with our assumptions.
It can help us with
- Our requirements including reliability requirements.
- The use process, we can consider what is value added to the user and what is critical to quality. We can mistake proof and design for the user
- Benefits - we can get to features that are a priority for our users. We can analyze requirements and determine quality measures.
- Symptoms - we can do risk analysis which can then feed into F M E A s. We can do preventive design where we're designing out problems and designing in controls.
- And we can also look to do reliability testing early so that we can understand how our design decisions are affecting the reliability of our product.
We are working with our team in the concept space to selfishly gather design inputs from them, but it isn't just one sided. At the same time, your team is gathering the same inputs for their own purposes. They do have their own goals even if we are all working toward the same goal, which is a successful product launch. As we're designing the product, its requirements and maybe even setting up a test plan to verify your requirements, your team is setting up their own plans. So even though you are breaking into the loop by facilitating these conversations with your cross functional team, they also have a vested interest to talk about the same things for their own purposes too.
These tools and techniques are also transferrable. So no matter if you are working in a particular industry, now, if throughout your engineering career, you decide to change to a different industry, these methods are going to apply. If you have suppliers that are doing something completely different than you are, these quality tools and methods can still be a common ground with which to communicate.
Summary
What have we talked about today? We've talked about the concept space, what it is and where we can get design inputs from it. We also talked about why it's important to do with a cross functional team and that they actually also have a vested interest in having these conversations with design engineers. We talked about different quality tools that are related to assessing the concept space and how we can iterate on it later in development.
Next Steps
Now, what can you do next? The next steps are really within the Quality during Design Journey. The Quality during Design Journey are really three different courses.
- Course 1: Designed for Problems and Risk.
- Course 2: Design with Quality and Reliability
- Course 3: Design for the Users.
Each one of these courses covers a different area of the concept space.
- Course 1 relates to symptoms: how to identify those with your team in a working meeting, how to derive design inputs from that and then iterate it on through development and even after market release.
- Course 2 focuses in on the system model itself where you're at the point where you've identified the use space and you're starting to develop your design concept. What are some of the things that you can be doing with your team, still at concept, and how can you iterate on that throughout development?
- Course 3 focuses on the benefits that the customers are experiencing, getting design inputs from those benefits. And it also takes a look at the use process.
With all of these courses, you'll be looking at strategic ways to design for risk and reliability and quality. You'll be actively working with your team to get input into the design using benefits and features and you'll be doing it early in the concept development phases before you've even started designing solutions.
Within the Quality during Design Journey, there is a Fast Track which is really four lessons that focus on those four working meetings that you would have with your cross functional team in early concept development to be able to gather those early design inputs to make design decisions.
Let's get started on our Quality during Design Journey, I'll see you in the courses!
