Part 1: Why Your PCB Design Review Process Is Obsolete and What You Can Do About It
Odoo • Image and Text

A printed circuit board (PCB) design review is a practice to review the design of a board for possible errors and issues at various stages of product development. It can range from a formal checklist with official sign-offs to a more free-form inspection of schematic drawings and PCB layouts. Some companies do it completely in-house, while others get help from design firms and contractors. In many cases, they involve their contract manufacturers (CMs) early in the process to ensure the manufacturability of the board. Our users concur that a design review helps catch mistakes early, decrease the number of board spins and manufacturing iterations, and reduce product development costs and time to market.

While the benefits are obvious, due to the time pressure to get the board out, the design review process may be rushed, errors overlooked, resulting in faulty prototypes, board re-spins, and product delays.

The common methods used to conduct a design review with feedback captured on PDF printouts or via long email chains mean that more precious time can be spent tracking the feedback than actually correcting issues. The shift to remote or hybrid work further complicates matters, as locking everyone into one room to conduct a design review, the preferred method in many companies, is seldom feasible.

For this article, we will not delve into what to check during a design review process but rather look at how a review process itself usually unfolds and how to optimize it to get the most out of your time.

How do most organizations conduct PCB design reviews today? 

Here at Altium, we talk to hundreds of our users, and for many, a design review follows a similar scenario. They hold a formal meeting or a video call lasting a few hours to a day to get every stakeholder to review the design. This process can be repeated at different stages of product development. They use several types of tools to capture, document, and track feedback:

Option 1: Paper and red pen

Here is how one of our users described it:

“I send people PDFs of schematics. The firmware guy might get printouts or PDFs of schematics and then redline it on paper. Then the design engineer would come in and make those changes. Maybe that paper gets lost. Maybe it goes to the recycling bin; maybe it gets scanned somewhere. And then, the same happens in the design review. We print out the pieces and sit down at a table with the sheets. Everyone’s got a red pen, and they’re crossing off things, and you take that, and it exists in your office. Maybe you scan it, and maybe you don't, but you incorporate the feedback into the design, but there’s no record of that incorporation having happened. Because it's all hard copies, it's very volatile, and it's subject to being lost.”

Option 2: Screenshots and email chains

The feedback is captured in a screenshot with accompanying commentary. This feedback is usually shared via email, sometimes messaging tools like Slack or Skype; some users even put it into PowerPoint slides. There are usually clarifying questions and status updates that need to be exchanged, and as a result, this method usually generates long and unwieldy email threads.

“With contract manufacturers, we might send them Gerber files, and then they're sending us back screenshots with Microsoft Paint written on them, saying “like this, and this, and this.” And that's living in your email and that subject to getting lost to never being found again.”

Option 3: Jira and other project management or ticketing systems

We’ll let another Altium customer describe it:

“I intensively used Jira. I created tasks for every correction. For a recent project, I created 95 tasks in total! I needed to put a description, make a screenshot, and put some marks there for every task. I use a two-screen configuration—on one, I have Jira, and on the second, Altium Designer.”

Why are these methods problematic?

When feedback is captured on paper or through long email chains with screenshots, it becomes laborious to consolidate it to track who provided it and what has been incorporated into the design. To keep everything under control, engineers have to waste time on a lot of administrative work. However, hours of busy work cannot guarantee an optimal outcome if you don’t improve the reliability of the process itself. Even the most thoroughly conducted design review can fail to prevent faulty prototypes from being produced simply because feedback can be missed or the wrong version sent to the contract manufacturer. When there is so much volatility in the process, mistakes can be overlooked despite best efforts.

Moreover, specific industries, such as medical devices and automotive, can be subject to additional scrutiny and regulations from government agencies in different jurisdictions. All communications, approvals, and changes to the design of a device must be documented and available for auditing. In such cases, tracking down feedback, changes, and approvals is no longer an option and can turn into a very time-consuming process.

What is the alternative?

In many domains, from manufacturing to software development, effective tools and methodologies have been developed to achieve reliability and agility in the process. While electronic devices have been at the forefront of transforming the world as we know it, the process of hardware development itself has been late to the party of digital transformation. We decided to change that with Altium 365, our electronics design platform, because you should be spending your time designing the technologies of tomorrow, not tracking down twenty different email chains.

Altium 365 provides centralized cloud storage and version control for your designs and libraries. In a nutshell, you could say it is a GitHub for hardware that also helps you collaborate with your mechanical team, manufacturers, and other project stakeholders. Below is a diagram created by one of our users explaining what Altium 365 is.

Check out Part 2 to see what your PCB design review would look like if you ran your project through Altium 365.

Share this post
Altium Quick Tips - Constraint Rule Violations