Lessons Learned from Product Design Reviews (aka Technical Reviews)

Posted in Featured Post on by .
electronics product design review

If you’ve ever been asked to sit through a product design review, you may realize that it can range the gamut, from a rather simple email review to a multi-day formal product design review. We asked one of our engineers to share their experience with product design reviews, including what to expect and lessons learned.

Some initial observations of the process include:

  • Projects or products that are complex, requiring high reliability or where safety is concerned should absolutely go through the full formalized design review process
  • Less complex products can benefit from a simplified adaptation of the design review process
  • Good design reviews help to make the product fully functional and help to cut costs by having an agreed upon plan with all departments involved in the product lifecycle
  • Too often, design reviews are looked at a merely as a “check-the-box” in order to reach the next production milestone

Here is a look at a simplified product design review process focusing on requirements, preliminary design and detailed design.

Requirements

This is the first step in the product design process. Setting requirements helps define product goals. Some requirements may be very formal sounding, with legal speak such as “will” or “shall”, while others may be a bulleted list. In either case, it should list broad features without taking into account the actual design, but should be specific where needed. Examples of things to have requirements for include:

  • What will the product do? What is its function?
  • Target cost (may be a cost range at this point)
  • If battery powered, what is the battery life expectancy?
  • Is there a specific processor or internal instrumentation?
  • What will it connect to (sometimes specific connectors are required)?
  • Will it need to be waterproof, rugged, etc.?

When doing a systems requirements review (SRR), invite all team members. It’s important to get as much information and feedback at this stage. At a minimum invite the following key players:

  • Engineers who will be designing electrical, software, hardware and mechanical parts
  • End users of the product
  • Finance people who will be paying for the development
  • Other departments that may have ideas that could be useful, such as marketing or customer service

The preparation for a SRR may just be a list of requirements, it can have some sample competitor information or even a demo of a similar product. During the SRR brainstorm and compile all ideas – at the end of the review you will determine what stays and what goes. After the list has been compiled, create an updated requirements document to start the product design portion of development.

Keep in mind that it’s typical for feature/function requirements to conflict with target cost. When it can apply, a requirement should state what is minimally acceptable and what the ultimate goal is. Usually, due to costs and development time, the final solution will be somewhere in between.

Preliminary Design

Using the requirements document as a guideline, it’s time to start the product design phase. At this point, you will probably find that some things are easy to do, some things are very difficult and some of the requirements just don’t make sense. Don’t put too much effort into the design at this point, just make sure you can present a plan to everyone involved that can be completed. Identify major components that will be used and major features such as size, connector locations, look and feel of any software screens, etc. at this stage. Create a block diagram and a very high-level bill of material (BOM). Don’t focus on resistors or capacitors unless they are expensive parts during this phase. The goal is to present the planned design to the whole team to make sure nothing was forgotten and everyone agrees.

Preliminary Design Review (PDR)

This needs to have more material than the SRR, but as long as the product is not too complex, a presentation of the data along with supporting documenting should suffice. Some elements to include:

  • Block diagram of the design – identity critical components
  • High-level costed BOM (nothing under $0.25 – estimate all of that in one misc. line item)
  • Estimated labor plan to build
  • Mechanical rough design
  • Estimated unit cost
  • Document to show that all requirements were met or, if not, why and a suggested path forward

Be sure to invite include all (or at least most) of the engineers that worked on the job, test people if applicable, users and again others that can provide value. Debate what is required, then update the PDR package to include all accepted changes. It is very likely that there will be some disagreements at this time. Decide which ones have to be resolved now, and which can be marked as action items and document them.

Detailed Design

Once the preliminary design is more or less agreed upon, start the detailed design. This phase involves selecting all components in detail, paying attention to tolerances, power handling, etc. For electronic printed circuit board (PCB) assemblies, full schematics, layout files, and BOMs should be determined. For mechanical components, full CAD or 3D files should be completed. Some bread boarding should have been done to test circuits. 3D printed or machined mechanical components should have been built to test fit. If software or firmware is needed, it should be complete to the level that was agreed upon. In reality, most of the time, everything is not perfect, but deadlines are forcing the design to be complete anyway. In this case, make a list of things that are not quite right, but can be tweaked later.

Critical Design Review (CDR)

The CDR is the final design review before production begins. If it will be short, go ahead and invite everyone (engineers, users, marketing, etc.). This stage may involve some heavy technical discussions. If this is the case, break it up into two sections:

  • Technical portion – invite engineers who will understand what is being discussed. They may have very specific suggestions on different components to use, power handling, etc.
  • Remainder – invite everyone to this part. The technical portion discussed should be summarized and available.

Some elements to include:

  • Technical portion
    • Schematics
    • Layout
    • 3D files
    • Source code
  • Remainder
    • Summary of technical portion
    • Feature description
    • Known issues
    • Demo if available
    • Costs
    • Anything left to do (regulatory approvals, user manuals, packaging, etc.)

Depending on the product, this may be a couple of hours or a couple of weeks. It is important to gain consensus as the next step is production. You may decide to go back and do some redesign, proceed as is or build some units to be able to field test, allowing you to then make changes.

Successful Product Design Reviews

Whether it is a SRR, PDR, CDR, or any of the other types of product reviews, strong communications throughout the product design process is critical so that issues are addressed in real time. A good design review process up to this point will produce the best first production piece possible.

ACDi is committed to helping our clients get their functional products to market as quickly as possible. If you need assistance from our engineering team to help facilitate that process, contact us today.

Leave a Reply

Your email address will not be published. Required fields are marked *