The first key point of the talk for me was how they decided early on what their Gameplay Pillars would be and then every decision was made to work with and enforce those pillars.  I think every design team starts out with this goal but we aren't always focused enough on the core of those pillars and often let things creep in that don't truly fit.

One of the examples they gave is how buildings in Assassin's Creed IIwere sometimes 4 stories tall when they were only 2 stories tall in Assassin's Creed.  So, they were finding in focus tests that players weren't using the rooftops nearly as much as before and this means the Gameplay Pillar of Navigation was suffering.  After analyzing the problem they found that the climbing mechanic being the same as before meant that it took twice as long to get onto those rooftops.  So, long story short, they halved the time it takes to get on the rooftop and the play tests went way up in the Navigation category.  Making a tweak to a Gameplay Pillar meant the entire world was affected in a positive way with a small change.

The way they approach design documents is something I'm interested in seeing more details on.  From what I could tell, they use very shortly worded specs that speak to the implementers and always try to answer things with a yes or no.  Basically, a programmer who looks at the spec for the money system has a literal blueprint for what he needs to build and there is less room for interpretation.  This is great in theory, but I didn't get the information on what processes they went through to get to that point and what heartache that may have caused.

It's incredible to think that they were able to make such a solid game on the short time schedule they had with the amount of features they were mandated to put in.  A team of over 300 is extremely hard to deal with, I know this from The Godfather Game, not to mention being at three different studios.  Kudos to them on a job well done, I know I enjoyed playing it.