Just generally all under the umbrella of signal quality.
Consider the chip's design itself, it's made of pins and bondwires. Use the shortest pins you can get (prefer TSSOP over SOIC over DIP).
Try to avoid transitioning multiple pins high or low simultaneously. This is particularly hard to avoid on, say, bus latches; at least they usually have schmitt trigger inputs, alleviating some concern with signal bounce and risetime.
Consider the entire net route, its drivers, receivers (input pins), ground support (keep it near ground plane as much as possible), and height above ground and trace width (which define the transmission line impedance). Avoid tree routing; prefer linear (point-to-point-to-point) routing.
If the signal's minimum pulse width is much longer than the electrical length of the net, and there are no significant DC loads on the trace (which for TTL, means having a low fanout; for CMOS, it's pretty much whatever), source termination can be considered. Note that the waveform at any intermediate node has a stairstep shape, as the incident and reflected waves cross it twice (which takes up to twice the electrical length of the net, hence the requirement that the pulse widths be much longer than this duration!).
Note that input pins have capacitance, so act to load down the trace. If you have multiple inputs on a net, try to space them evenly so that they act more like a lumped-equivalent transmission line. The trace impedance can be a little higher in this case, since the average including pin capacitance will be lower (impedance is sqrt(L/C), and the pins act to increase C). There may still be ringing due to the between-inputs lengths, which can be dampened with additional resistance (say on a few of the inputs, or a small R+C at the end, or a FB at the driver(s)).
Speaking of ferrite beads (FBs), be careful using these; they have, not so much a long time constant, as, effectively, a distributed time constant. In series, this will give nice, soft, rounded edges, which is good for reducing EMI on cables, but can be ill advised for high speed signals. FBs are available in many values, so pick an impedance appropriate to the application -- for just taking off some ringing perhaps, a low value (say 10-30 ohms @ 100MHz) might be good, while for slower signals (especially going onto cables), larger values are an excellent choice (say 100 or 300 or 1k ohms).
And for cables, you might even add some parallel capacitance (or R+C) to provide additional filtering and dampening. And maybe some ESD clamp diodes, because the outside world is a nasty place.
As for nets that can't so easily be source-terminated, load or source-load termination is an option. This is quite traditional among TTL -- the relatively high driver voltage (roughly 0.4 to 3V typ.) and smaller input threshold range (0.8-2V) means some loss can be tolerated along the signal path. A source-load terminated medium has, as the name suggests, a matched driver impedance (Zo at the ends, or Zo/2 in the middle), and termination at the ends (Zo for each end that doesn't have a permanent driver also attached*).
*Because Thevenin and superposition theorems. A source at 0V (AC) and a series resistance of Zo, is... literally the definition of a termination resistor. (More specifically, with 0V correlated to the driving source in question. If they happen to be synchronized, they're not uncorrelated, and the effective impedance will be something else.)
Back in the day, divider resistor packs were quite common, something like 390 ohms pullup, 150 ohms pulldown -- the parallel combination being a perfect match to ribbon cable, when wired with alternating signal and ground, and the Thevenin equivalent voltage being perfect for TTL inputs. The old ST-506 hard drive interface used exactly this for the control signals; the terminator was socketed, so it could be inserted in the last drive along the chain. (The data signals however were preserved with better signal rate and quality, using RS-422 differential transceivers and point-to-point links -- hence one multi-position control cable and two separate data cables between the controller and a pair of drives!)
If you put a (IEEE 1284) parallel port on your project, you can consider using just such a termination with it; the transmitters are either 5V TTL, or 3.3V LVCMOS (typically 74HC family), either way having fairly comparable drive capability, suitable for load termination like this.
Which also tells you exactly how to construct it -- the old school way is literally an I/O address decoder, a couple bus latches, a bus interface (if full bidirectional), and, usually a 7406 or something (open collector) for the control signals I think? (In PCs, this was quickly integrated into the system (SuperIO) chip, then later on, eliminated entirely.)
Ahem, anyway, signal quality doesn't need to affect your design much, or at all; it's not something you need much schematic consideration of. For the most part, it is a separate and independent step, part of layout and routing.
If breadboarding, don't ignore it too hard -- your jumper wires are traces all the same, albeit with rather awful impedances, and relatively high coupling between them, making things more vulnerable. Make sure the supplies are well bypassed and stitched (if using physical supply rails, tie them together at both ends of the board, say). Maybe slip on a ferrite bead every so often, make sure the signals don't bounce too much.
Best part is, all this can be viewed on a typical scope (100MHz maybe isn't quite enough, but 200MHz or more is good), so you can see where signal bounce, supply noise, and common mode noise, are present. You can always add or remove jumpers, and slip on ferrite beads as needed. (Adding termination resistors would be harder to do!)
I once breadboarded a 4MHz Z80-CPU, with RAM, ROM, and a couple (74LS) bus latches, one pair of which drove an LED matrix display; it would often run fine, for days or weeks on end, but once I coded a LFSR (a type of random number generator), it would hang much more frequently (within days to hours). Presumably, some bad combinations of data were causing the buses or supply to glitch; maybe improved bypassing, or grounding, or ferrite beads on some signals (or all of them?..), would've fixed it. It goes to show you, something might look perfectly okay with average data -- the LED matrix routines were very repetitive -- yet an underlying problem hides in plain sight (in this case discovered by fuzzing with random bus data).
On another occasion, I had made an SPI peripheral module on a separate board, and plugged it into a breadboard with an ATMEGA; it was a disaster, just gibberish going through. Slipped a ferrite bead on to SCK, MISO and MOSI, good as can be. ATMEGA has faster pin transition times than some of what we're talking about here; with 74HC I think being, either a little bit slower, or comparable to it?
Tim