Throw lots of ground test points at the board so that you always have one nearby when scope probing fast or low-level signals. These do not tolerate long ground wires to the probes. If there is room, a connector for a logic analyzer can save a lot of pain.
I always do a continuity check of all power and ground pins on a bare board as soon as it's available. This doesn't take much time, and makes sure the PC design software or the PCB manufacturer didn't miss something. I also check the Gerbers before they go out to the PCB house.
If you have a package with a large ground pad on the bottom of the chip, expect that the assembly house will forget to solder it for the prototypes. In many cases, that's the only ground connection for the chip. If possible, extend the PCB artwork for the pad out from under the chip so you can heat it up with a soldering iron.
If you have programmable parts, always bring out spare I/Os to test points (vias). These are invaluable for debugging FPGA logic in real time.
Draw your schematics as if you're going to be the one debugging the board. Number your passive components in a sensible way so they're easy to find in the schematics -- I like to number all components in the same sequence as the pages of the schematics. Don't use automatic numbering: the hours you saved by not numbering the components by hand will become days added to debugging.
Draw component symbols to match the package pinout. This will make it a lot easier to debug. For BGAs, match the pad sequence on the chip itself. For Xilinx FPGAs, you can get this from the graphical chip editor. For others, BSDL will probably get you the information.
Fourth important dimension is to talk to your friends of what you are doing and how it will work and what problems do you have. Review process and talking to some part to friends outside is also desired. Main advantage of this is self realization of mistakes. When one explain it to friend, and when he asks few questions, one self realize mistakes to be fixed or design to be enhanced.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.