Welcome back to the next lesson. This lesson is called diagram concepts to communicate for design inputs.
When we think about engineering models and diagrams, we think about the actual engineering prints and specifications or the 3D computer aided design, graphics and even the prototypes in hand. And those are all common tools that we use as engineers.
There's also other kind of drawings that we can use and we can use them with our team. We can iterate on them throughout development and they can help us make decisions. And we use these other kind of diagrams to help us communicate with our team. Because it's sometimes difficult getting people that work in different functions of the company on the same page about an idea and these graphical tools can help with that.
Prototyping is sometimes an answer. It is a very valid thing to do. We mock up whatever design that we're thinking about and give it to our teammate and our potential customers to give us feedback about it. It does cost time and money to develop prototypes. So is there anything that we can maybe do before we invest that time and money into prototyping? I think yes, depending on the situation, these graphical tools can provide great inputs to the design and get you talking about the design with these other functions and groups of people.
Before you even need to prototype, we can use these to be a fast and economical way to communicate with others and get the design inputs that we need. These kind of diagrams also help us plan, they help us plan for the product testing that we may need to do later. They'll help us decide what we need to research or where there are gaps where we need to find out more information before we start making design decisions and it can help us develop relationships with key partners. We're going to have these analyses, we'll be able to use them and reuse them later in the development to make other decisions.
We've been exploring concepts with our cross functional team before product design, we're getting to better know the users, the use environment and the use process. And still in these early phases, we've been able to start exploring the concept space and get design inputs from it, including the use process, the benefits and the symptoms all before we can even start engineering solutions.
Yet, in this lesson, we're going to start getting into some of the product design: how. How our product is going to help our users get from A to B. And here is what we're going to be covering in this lesson.
- We'll be drawing three diagrams to be able to communicate design concept ideas will assess design choices with a cross functional team with concept diagrams. And we'll develop these diagrams for design for excellence. These diagrams are going to feed into other aspects of product design. Let's start with these three diagrams to communicate a concept product. It's a schematic, a geometric layout and an incidental interaction diagram. These are not new ideas for product design engineering, Dr Erich from the University of Pennsylvania and Doctor Ebinger from Massachusetts Institute of Technology, both published a book of product design engineering and they outlined these three engineering concepts. The point of introducing them at concept is to be intentional with them. We want to start the conversation early because these diagrams are a way that we can talk with the cross functional team before we start engineering solutions because the information that we get from them is going to affect our design choices. Whereas we might start these diagrams on our own, we're going to start working with our team and using them to communicate our design ideas. We'll be taking these diagrams and showing how to use them throughout development with other cross functional teams including reliability and quality. So these are definitely something that we develop for ourselves, but that we also share for our other team to communicate and for them to take and develop. The schematic is made of three elements. We use blocks chunks which is a combination or a grouping of different blocks and lines that connect blocks and chunks, which are the fundamental interactions. The great thing about using a schematic during concept design is that the blocks and chunks can be a physical item. It can be a functional concept and it can be critical components or a mix of all three of those within one diagram. Any of the information that we know for sure at concept is fine. Even if we don't know very much, we're still going to be able to organize our system into modules and then determine what the interactions are. Speaking of those fundamental interactions, those are flows between the blocks or chunks and usually represented by different types of lines. For each type of flow, you could have forces or energy or signals and data between different blocks or there could be material moving from one block to the next block. The big idea is that we examine these areas of design integration and modularity which affects a lot of design for excellence types of things. Schematic is one of the diagrams and it's the first thing that we produce a concept development and work on with our team. The second diagram that we produce after our schematic is a geometric layout. This really is a back of a napkin kind of thing. It can be, we don't have to be really complicated with it. You can see here that I created a geometric layout of a bike stand concept. Of course, if you're not as confident as I am in your drawing skills, you can use a computer aided graphic, but really, it's not anything functional that we'll be using to set specifications or create engineering drawings from. This really is a rough geometric layout. We're really replacing elements of whatever we've developed in our schematic with simple shapes. We're adding form and fit and we're starting to show some human interfaces with our product. And we're starting to show physical relationships between the chunks and the blocks we can start to assess. Are there tradeoffs are these feasible? And as far as the human interface are things accessible fable and usable? The third diagram that we can create about our product and its features at concept design is an incidental interaction diagram from our geometric layout. We're going to start to get ideas about what chunks are placed really closely to other chunks and what are some of the interactions that we're seeing with our geometric layout. This is going to highlight some incidental interactions between our chunks and our blocks. Examples of incidental interactions are thermal vibration wear and R F interference. These are things that maybe one chunk just by order of its operation and where it is in our geometric layout is creating a problem or could create a problem for another chunk or another piece of our product. You know who really likes incidental interaction diagrams, reliability engineers, these diagrams are a great way for us to think about what kind of stresses our product might be seen and compare that against the reliability that we want. We may start to get an idea of what kind of reliability tests we want to perform in order to better understand the incidental interactions. And if it causes a problem, it could affect our geometric layout or maybe even our schematic. So these are things that feed into the design architecture. The incidental interaction diagram works best if we work with 10 chunks or less, those are the three types of diagrams that we can use during concept development to talk with our cross functional team and develop design concept ideas. But that's fine, we can share them. But what kind of design choices are we really making from these diagrams? These diagrams really explore three aspects. It's exploring the modularity of a design, its layout of components and parts and the interactions that we have with them interactions are coming from our schematic. The first drawing that we create and the incidental interactions are the things we're considering. After a geometric layout. With those two diagrams, we're considering both the fundamental interactions and the incidental interactions. Why is it so important for us to use these diagrams to develop engineering designs at a concept phase early because it takes a team to deliver a product. Our goal is to guide them through working meetings, to get their input into the design itself. We're using these three concept development tools to talk more about specific parts of the product's features and characteristics. But doing it in a way that lets us explore design choices before we go too far down the path of engineering solutions. Sometimes that learning is an aha moment. Other times it will bring up more questions. It's our responsibility to ask because they are the internal customers of our design choices or they represent our end users, which are our external customers. They are going to be giving us input into the product design. What needs to have happened for the customers and to be able to make this be made with a certain level of quality. When we create these three diagrams and look at these three areas, modularity, layout and interactions and we work with our team, we can think of each of our teammates and think of what each can provide us in terms of design inputs. First, let's start with our customer facing teammates. This could be sales and marketing, customer service field operations. Anyone that has an understanding of the customer themselves and also where it is they are working in the use environment with modularity. Something they may come to the table with or have thoughts about is product variety. Are you designing and developing something where the customers are expecting to be able to upgrade or to have a different level of product? Like a bronze, silver and a gold where they can upgrade different modules of the product design in order to get different benefits from it, modularity could also affect the interchangeability of things too. If you think of disposables and service repairs and other upgrades, what kind of capabilities do we want to offer the customers there? Our customer facing teammates may have some strong opinions about that regarding the layout of this design concept, they come to the table knowing a bit about the competitive products. How do the competitive products meet the customer needs that might affect what users expect to be able to do? Is there an existing difference between what they currently do and what they really wish they could do. Our customer facing teammates may also look at layout and think about the interfaces of our user human and maybe other products within the use space. And as far as interactions, they may be very familiar with the use environment with the extremes that this product is going to be working in or with service and handling and delivery. They want to be able to deliver it easily and not need a refrigerated truck. For example, these are some of the perspectives that our customer facing teammates may have about this new product design and definitely design inputs that we want to be able to capture and design against. Plus nest looked at reliability. They do a lot of tests to learn and they verify that the product is reliable with our schematic and its modularity. They'll be thinking about what are the risks, what's new, what's different and what's unknown? What are the reliability goals for the whole system? And are there particular modules that need to be more reliable than others? And what are tradeoffs? Reliability engineers may help with redundancy and apportionment which are things that are affected by the modularity with interactions. Reliability engineers are going to be looking at the use environments. They'll want to be able to plan reliability analyses and testing that may affect the modularity and layout of the product. Next, let's talk about our cross functional teammates involved with production. This is manufacturing and procurement. They're working with suppliers, they're making sure that the product can be made. Our production teammates are thinking about design for manufacturing. How might it be manufactured in modules and what manufacturing processes would be needed? They also think about the capability of this being able to be produced, what tolerances would be needed? What kind of resources would be needed and do we have them or do we not have them? Would we need to outsource them and what risk would that introduce? And they also look at costs even with the incidental interactions, they're going to be looking at what's new and different and unknown and seeing if there's any special handling and storage requirements or maybe even manufacturing environmental needs. An example of that would be clean rooms for cleanliness R F shielding for electronic assemblies. Our quality teammates are going to be looking at our new product design concept with respect to quality processes and transfers, controlling variation and controlling risks and they bring knowledge about production benchmarks and capabilities. Some quality teammates take a very broad approach to product development and they're looking at the transfers of information and parts between development and production and the business. They're interested in learning what the overall quality goals for this new product are and about how we're going to meet them. Things like what quality measure is defined by a module where are natural break points to assess the quality of the product. Where might we have new suppliers and where might we be stretching the limits of our current suppliers where our user interface is with this system and what quality measures are the users themselves defining? They may also be thinking about how to design with testing in mind, either in process testing or final testing or even testing that happens in the field after release. These are a few of the things that the quality person on your cross functional team might be thinking about with new product development. And finally, project management, someone has to coordinate everybody to get the project done. They bring knowledge about the development capabilities. What are the resources and the costs and the timelines? And those are usually constrained. The product design modularity may affect project management. Maybe different teams need to be working on different modules. In order to meet the market need in the time the company needs to meet it. The project management decisions are also affected by the product layout and the interactions of the product. And finally, we share and then we iterate these diagrams for design for excellence. Keep iterating until you get the design inputs you need so that you can make a decision and then move forward with a schematic. You can get team alignment on the modules and they have very important functional interactions. We've drafted a schematic and reviewed it with our team. We've taken the inputs and we've generated a geometric layout. We present the geometric layout to our cross functional team. The goal with a layout is to get alignment on what the layout should look like. After we've gotten input from our team on the geometric layout, we take that information and draft an incidental interaction diagram. Really what we want to do with our team when evaluating this is to have an action plan to address these incidental interactions, whether it's testing them, whether it's changing something within production, so it doesn't happen or if we're want to monitor and control that with some quality measures. Doing these three diagrams with your team is going to allow you to design for excellence because you're not only designing for the end user, you're designing for all your internal customers that are needed to be able to make the product a reality. What did we cover. Today, we talked about three diagrams that you can draw to communicate design concept ideas at the early concept phase with your cross functional team. Those are the schematic, the geometric layout and the incidental interactions diagram. We can use them to assess design choices with our cross functional team. Everyone has their particular viewpoint and goals from their own department, even though we're all in a team working together toward product development goals. And we talked about how to develop and iterate these diagrams with our team for design, for excellence. Thanks for joining me for this lesson and I can't wait to see you in the next lesson.
