Although a lot of standards exist, not all of them are suitable for everyone; that said, some of them are extremely useful.
IPC-7351B is used for footprint creation (and many implementations permit adding height dimensions allowing tools to export to files suitable for mechanical analysis to ensure everything fits within a particular housing - this ability has saved me a lot of trouble a number of times in the past). This standard also has a footprint naming convention that reflects the physical characteristics of the device.
Implementing this standard is very useful when using external fabricators and assemblers (the usual state of affairs for smaller companies) as all can agree on pad sizes and so forth for various devices.
There are standards for schematics although the only one I have used (and it was contractually required because those projects were for a US govt agency) is the IEEE STD 91 for logic symbols.
Most places I have been at developed schematic and signal naming conventions internally to meet their own needs and as such there are many ways to do this, but some things are pretty much agreed as you can see from this canonical answer.
For PCB and assembly documentation, I personally suggest (and myself use) the guidance from IPC-D-326.
Whatever you use for signal and component naming needs to be consistent so don't have both TR
and Q
for transistors (both of which are widely used); use one or the other or people will become confused (a situation I have seen on occasion). The same rule goes for IC
and U
(both widely used for integrated circuits).
There are many ways to implement net naming conventions, but the key is that they should a)
be descriptive and b)
be short enough to be readable.
As an example, some packages accommodate bars over \$ \overline {signal names}\$ although the same can be achieved with text (such as a trailing #
symbol) for negated signals. There is no single correct method.
Your outputs are perhaps the documents where standards matter most (because that information will go elsewhere if you sub out the assembly and fabrication).
Most of the better contract manufacturers and fabricators will accept ODB++ format. It has advantages over the multiple file approach of gerbers, pick and place files and drill drawings as all the information is in one place. That is not to say that using the gerber approach is wrong; it is simply a different method of getting the information necessary to your suppliers.
For any drawing (schematic included) I would suggest you will always need blocks for the project name, sheet name, company name and (should you have or need one) a CAGE code.
There should also be a revision block with entries for the revision ID, implemented by, checked by and authorised by names.
Be liberal with free text to explain things that may not be obvious (without making the sheet unreadable).
Anything beyond that is going to be based on experience and opinions so I am not going to go there.
The overall message is that the documentation needs to be easily readable and complete for all the design documents.
Most IPC standards cost money (some are free) but there are many online resources that cover what is in them. IPC-7351 compliant footprint generators in particular are often bundled with CAD tools. You can find an explanation of what it is here.