Design Process for Half-Life

I came across this Gamasutra article while looking for ideas about how to flesh out the first draft of our design doc. It outlines Valve's process and decision-making logic in creating Half-Life, and has a few quotable gems, like this one, which I think speaks a bit to the iterative tuning excersize we did in class on Friday:  

Letting players see other characters make mistakes that they’ll need to avoid is an effective way to explain your puzzles and add tension and entertainment value.

And this one, about play-testing:

To do this, we added basic instrumentation to the game, automatically recording the player’s position, health, weapons, time, and any major activities such as saving the game, dying, being hurt, solving a puzzle, fighting a monster, and so on. We then took the results from a number of sessions and graphed them together to find any areas where there were problems. These included areas where the player spent too long without any encounters (boring), too long with too much health (too easy), too long with too little health (too hard), all of which gave us a good idea as to where they were likely to die and which positions would be best for adding goodies.