Feedback on design review checklist

I spoke w/ Chris a while back on Amp Hour about design review checklist best practices. Well, we recently added a feature to AllSpice which auto-populates a checklist for new design reviews. As part of that I’ve added a demo checklist people can fork to get started. I spent a good amount of time compiling this list from various sources, and adding some of my own best practices.

I made it all markdown compatible, so if people find it useful, feel free to use it (click “Raw” to get the source). I just ask that you link back to us and submit any improvements you make.

Main Sources:
http://aqdi.com/wordpress/PCBChecklistLive.htm
https://pcbchecklist.com/

The idea is that this should really cover only common issues and minimize the number of words (any details should be linked to externally. For example, if someone has best-practices for part naming link to an external page with those specs).

Did I miss any big subjects? Anything I included that I should get rid of?
I also saw this CE thread, so I’ll read through and see if I can find any good items to add.

1 Like

One thing that’s useful in design level checklists is to have a “no change from prior design” checklist item.

I.E., you did it once, and the design hasn’t changed, so you won’t be paying it an excess of attention in this revision.

1 Like

I love this checklist! Definitely going to adopt it.

I have my own “don’t make that mistake again” pre-release checklist. You’ve covered the majority of things on it, but here are some as well:

  • Make sure the project has a clean BOM with accurate part numbers for everything in it.
  • Check that any optoelectronics, or any other parts that might have weird reflow requirements, are thusly noted in the fab drawing (we had a bunch of boards recently where the LEDs required a particular profile, and neither we nor the CM noticed that it might be a problem before baking them all to death)
  • Make sure any and all flat flex/FPC connector pinouts line up with the mating cable, top/bottom contact connectors are specified correctly, and same/opposite side cables are specified correctly. Use paper to do it.
  • On ground planes, pour any pours you’re going to make, and thoroughly stitch them to avoid resonant structures. I usually do this last so I can manually optimize stitching vias on thin sections/between tracks/in corners/etc.
  • Add a picket fence to GND if you are going to.
  • Verify that your tool is set up with the correct design rules for your vendor (you should have done this at the very beginning, but it’s always possible you didn’t, or changed vendors somewhere in the middle and most things are “close enough” but some are off.
  • DRC actually passes

I have a handful of checks for “stuff that should be included in the manufacturing package” as well, but it can be a little tool-dependent.

1 Like

Checklists can get a bit crazy if they try to cover everything. Here’s one based on an article in EDN magazine 30 years ago (but still has some gems).

http://nextcloud.dalescott.net/index.php/s/9tqo2sGz2Mgwc5m

1 Like

Yes, but how do you know you are using the checklist correctly!! You can easily skip a step and miss a crucial step!

You have to use the circle-x procedure on your checklists. Without it, your checklists are useless. Better, someone watches you perform the circle-x procedure on the checklist to make sure you are circle-x-ing correctly.

I have spent much time circling steps and X’ing them off. I’ve spent more time watching people circling steps and X’ing them off. It’s the only way to ensure completeness.

1 Like

One thing that’s useful in design level checklists is to have a “no change from prior design” checklist item.

Hey Nash! Yeah, I think that’s a great idea. I might add a suggestion in the comments. I think the best practice would be to mark the line item with a strikethrough and a note to communicate you’re skipping it, like:

~[ ] Review PCB outline~ [No change]
^ should render as a strikethrough in markdown

You have to use the circle-x procedure on your checklists

@jbdatko I like this idea. I think similar to above, maybe bold and WIP note would be helpful for the bigger tasks so that no one does double-duty. If you’re using Jira/GitHub/AllSpice you could also @tag someone in the checklist item to ask for a review on a particular item.

Checklists can get a bit crazy if they try to cover everything

@dale Yeah, it’s tough to hit that balance. One nice thing about having in a simple markdown text (as opposed to HTML web form) is that users can strike out or delete sections where are obviously not relevant (like PCB for schematic-only modifications).

Here’s one based on an article in EDN magazine

Ha, this checklist is a bit more morbid than I was expecting :scream:
Maybe the wrong url?? :smile:

I have my own “don’t make that mistake again”

@alexw Oh yes, this is great - I knew I could find some folks here that were keeping their own lists. You are much more diligent than I am while doing designs. Will add these for sure.
Good call on temperature profile’s! I have also melted some plastic LEDs in the past. And the Flat Flex note… I’m getting PTSD reading through your list :flushed:

1 Like

95% of the purpose of this checklist is to keep track of big screwups that Never Again.

2 Likes

That’s the idea.

Checklists don’t prevent new mistakes. They prevent the old mistakes from returning.

A point that a prior boss had to be reminded of frequently when his checklist obsession didn’t turn into a panacea against all bugs.

Actually my checklisting also comes from a former boss. My self-documentation as well. His position was always that the documentation and notes should be straightforward and thorough enough that if he died tomorrow, it’d be a minor hiccup for continuity. The secondary reason being that he’d never remember anything well enough to replicate it exactly, and he ALWAYS needed to reference prior work at least once.

I can sometimes look at a design idea I did 1 year ago, and it takes more than just a minute to discover what the heck I was doing :slight_smile: