- Part 4
You’ve moved steadily through the process of creating a product, including designing a prototype. So far, your product specification is reasonably sound. You’ve created a high-level plan for the development of the system and a strategy for dealing with any risks you may have uncovered so far. You’re well on your way to a fantastic product.
As you develop your product you’ll need to move through a design review process. Generally, there are three review milestones.
Each stage of the design review process is critical. With proper assessment and review at each of these stages, you can progress with a higher level of confidence towards the final product.
To get to a preliminary design review, start with your Product Specification. Look through the detailed requirements of your product specifications and analyse them in detail to assess technical options and risks. These can be in the form of Use Cases or statements that describe how a feature is expected to operate. The crucial point is that each Use Case must have an objective test aligned to it, a physical, measurable metric that can tell you the requirements has been met.
During this stage of the process, you will also need a Project Risk Register. On this register, you will keep track of all the risks you currently see in your plan: any problems that might crop up along the way, challenges you see in the process, and other potential issues. Include information about how you plan to eliminate or mitigate them. Examples quite often involve isolating a specific technical question to spend time resolving, or investigating an element of software that has many integration points and has the potential to burn a lot of time.
You learned a great deal from the Works-like and Looks-like prototyping exercises. Now, it’s time to turn what you’ve learnt into design decisions, including:
In order to move through the Critical Design Review process, you need clear, detailed requirements. This will enable you to write down the Architecture Design of the product and system. The Architecture Design may include detailed flow charts, process flows, schematics, and block diagrams that represent your design choices and how the system hangs together. This is also a good point to write detailed test cases for individual component parts of the system based on the design choices you’ve made.
Note that with any connected hardware product, it’s vital to think about the integration points and how to design and test them. The Architecture Design shows how the system looks in parts: hardware, firmware, software, and mechanics. You must put detailed planning and thought into how the parts work together and with each other. For example, a well-defined API when a mobile app is talking to a piece of embedded firmware on a device needs to integrate seamlessly with the whole and work effectively with the entire system.
Step One: Order the pieces of your product. Pick up the components, the PCB’s, sample plastics, and mechanical parts. This is where your Bill of Materials is created: the recipe for your device.
Step Two: Put it all together. This first time you put the entire system together is crucial. At this step, there will probably be things that aren’t quite right. The PCB fitment in the first enclosure might not work as smoothly as you’d hoped. The feel of the enclosure material might not be exactly what you had in mind. The mechanical performance might not quite meet the stated requirement. This is to be expected. You still have plenty of time to work out the kinks and make small, but vital, changes that will improve the overall quality of your device.
This will also be the first time you’ve embedded the firmware onto the hardware. Again, it is unlikely to deliver core functionality smoothly the first time. There will be bugs and glitches to work through as you develop and test features of the device. It’s all part of the process of delivering a product that will meet the needs of your consumers.
Step Three: Compare the performance. Look at the performance of the device you’ve created compared to your test cases. Chances are, you will need to iterate and improve performance. Put it in front of people and test their reaction.
You’ve put together a device that meets all of your requirements. Now what? At this point, you’ll move on to the Release Design Review stage. During this stage, you will run customer trials in the field against your original use cases and requirements. Here you’ll discover how your device performs when customers encounter it for the first time. See how it holds up with actual use. Through this review process, you’ll get a better understanding of what your design can accomplish and how it works in the real world.
Take the feedback from this step and use it to help develop any final changes needed to your device. As you finalise the design, you’ll prepare for Validation tests and, ultimately, handover to a contract manufacturer. To learn more about the Validation process and handover, check out Part V of our series, coming soon.