Game Design Logs

If you still practice or encourage the outdated practice of writing long design documents, you are doing your team and your business a grave disfavor. Long design docs embody and promote an insidious world view: They make the false claim that the most effective way to make a game is to create a fixed engineering specification and then hand that off to developers to implement feature by bullet-pointed feature.

Great game development is actively harmed by this assumption.  Pre-allocating resources at an early stage interrupts the exploratory iteration needed to find the fun in a game. A written plan that stretches months into the future is like a stake through the heart of a good game process. Instead of quickly pivoting to amplify a delightful opportunity found during play testing, you end up blindly barreling towards completion on a some ineffectual paper fantasy.

Yet, there is still a need for documentation.  Why?

• We need a persistent repository of decisions: Teams include many people and conversation occurs asynchronously.  Without centralized documents, you end up with a fragmented conversation where many decisions made in one-on-one conversations are lost to the broader team forever.   
• We need a shared vision: Documents also helps forge a common vision of the next iteration.   In a situation where everyone has strong and varied opinions, it is essential that someone can lead the team to by unambiguously stating what comes next.  Apparently even God needed documentation. 

Design logs

What I do now is write a little something I call a 'design log.' Game design is a process of informed iteration, not a fixed engineering plan that you implement.  The form of your design documentation should flow from this philosophy [...]

Read more: Game Design Logs