Hi everyone. So for this video we're going to be discussing planning for prototyping. When we look at designing prototypes, or planning for developing a prototype, there are a few different steps that you have to go through. Now these are all in your text, and I find that they don't just work for physical projects, but they can be good for developing a service or a software as well. So, first step is define the purpose. What is the purpose of developing this prototype? So there are four different reasons why you would develop one, learning, communication, integration, and milestones. So, with learning and communication, these have to do with everyone being on the same page within your design team. So the designers, engineers, the customer. Also learning, and you can see how the customer's behaviors might come out, depending on different facets of the software or different elements. So understanding customer behavior is very important, and understanding what sets off different triggers, what makes them angry. Okay, integration. So with integration you'll be taking a look at, with software products, take a look at how it'll integrate with other systems that you want to work with. So when you're looking at commercial off the shelf products, like COTS integration, that is kind of a specialty. You need to know how to do different kinds of troubleshooting, know how to, maybe reverse engineer some aspects. And when you look at milestones, it's important to have the milestones for the prototype. So that way when you're designing for manufacturing or developing a full scale product, you know where the most time is going into different elements of the product. So you can plan for this. So determine performance metrics, whether it's speed, weight, pressure. It'll all vary, but for a software and for website-based and applications the performance metrics will likely have to do with speed and data. And maybe some other ones, as well, but, yeah, it'll all depend on your project. So examine manufacturing costs. Now, even if you've got a software product, take a look at the development costs and then also the distribution costs as well, and how you're going to do that. So here's a planning template, and this is in your textbook. So what we can see is the name of the prototype and the purpose. So the example was a PackBot Wheel Geometry Impact Test. So we can go through there, take a look at what the purpose is, confirm that the wheels absorb shock to withstand impact and protect the PackBot and its payload. So, yeah, a great thing about prototyping though as well is that you really get to do the design of experiments and integrate that with robust designs so you can make sure the product works under non-ideal conditions. For the level of approximation in correct wheel spoke geometry, materials, and platform load, that's where it's good to have some really technical folks involved so they can really help you with that. For the experimental plan, you can build, and this is for the PackBot. Build 12 test wheels using six different materials, each with two spoke shapes, mount the wheels to test the fixture, conduct impact tests. So when you're doing the experimental plan, test each of the items or different variables under different conditions and make sure you log everything and that you've got this test mapped out. Don't just kind of hack away at it and then take a guess because that's where you'll end up with a whole bunch of errors and glitches and problems in your plan. So testing requires some good planning and being very thorough. So, here's an example, then, of the schedules. So, August 1st, select wheel designs and materials. August 7th, complete design of test fixture. The 14th, wheels and test fixture constructed. And, yeah, so just have a schedule as well. It's important to make sure that you do stay on schedule because it's so easy to get stuck in different stages and not actually achieve anything. So Step 2 is establish a level of approximation. So when planning a prototype, it'll require you to define the degree to which you need to approximate the final product. So this is where it's important to have those customer specifications and metrics. And what works best, a physical prototype or an analytical prototype? It'll all depend on your product. So with outline and experimental design, which is the third step, a prototype can be considered an experiment. So make sure that you've properly planned out the design of experiments with the robust design sorts of testing as well. And good experimental practice helps ensure the extraction of maximum value from the prototyping effort. If you're developing a service and you're trying to develop your company, still try and take a look at developing scripts, mapping different customer behaviors, how they find you, how they're coming to your office. So these sorts of tips aren't just for physical products. You can just be flexible and apply them to yours, and make adjustments whetr necessary. So, a lot of these strategies and steps that we're giving you throughout the course, they can be applied to a number of different projects and different industries. So, you just have to be able to play with them a bit and not be too concrete. So with Step 4, you create a schedule for procurement, construction, and testing. So building and testing a prototype can be considered a subproject within the overall development project. So make sure that when you develop that it's part of the whole plan. So look at how much you're going to put into the prototype. How much money do you have to put aside for the other aspects? So really try and keep your financials in control, and understand how much you should put into a prototype versus the rest of the company, very important. So, scheduling your prototype can be beneficial, definitely. But, so three dates are going to be important because of the funds when the parts are ready to assemble. So, this is the bucket of parts state, okay. The same sort of thing can work with software as well. So if you've got different sorts of small functions that you want to perform different things within the software you can still have that bucket of parts state but just do it differently. Yeah, software. Same with services as well. Just stay flexible with it, but apply the same theories throughout, okay. So the team defines a date when the prototype will be tested, is the Smoke Test date. Give yourself a good amount of time before you actually have the test date. So give yourself at least a week where you can have it developed and then have room to go back and take a look at different things. Because you really don't wanna run out of time, especially if the customer is gonna be involved in the prototype testing, okay, cuz that can be embarrassing. So the team defines a date when it expects to have completed testing and produce final results. So these are the three important dates. So in summary, define the purpose, know why you're developing a prototype, look at the level of approximation. You come up with the experimental design and testing and then look at your scheduling. Make sure you give yourself enough time to go back and fix something as well before you do the testing in front of the customer. Thanks. Bye.
