Don't let the document do the talking for you. The game design document is not a blueprint for making an awesome game. It is a set of theoretical choices on gameplay, with a theoretical fun final objective. It will change a lot during development, and new information will modify its content rapidly.
That doesn't mean there is no point in writing one; even if it gets changed often, you still need to start somewhere, and the first versions of the design document are critical to shaping the overall vision and strategy of the project. However, many people will interpret it differently -- one sentence will mean something totally different to another team member. Engineers may need more information to understand something that is perfectly clear to an animator.
The design document is the starting point of your collaboration with the rest of the team; it is not the final result of your work. Make sure that when you put out a design document for the team that you go over it with the relevant department leads and people working on that feature. Yes, this means that you must schedule a meeting before they start working, and go over the whole thing in detail.
It really helps if everyone at this meeting has read it beforehand. During the meeting you will get a flurry of questions about stuff that you thought was perfectly clear in the document; this is normal and, in fact, healthy!
It means that you were not precise enough for certain people or that there was an ingrained assumption about the feature inherited from previous discussions. This is what this meeting is designed to iron out, and get everyone on the same understanding about what exactly this design is trying to achieve.
It also allows you to solicit input from the implementation group on how to execute features. The meeting should result in clarifications and small changes to the doc, and you should integrate those changes as quickly as possible and update the feature doc for the participants to review as quickly as possible after the meeting -- memories fade fast.
That process turns the document from a draft to a Version 1, and you are now off to the races. Talking through the doc will save you enormous pain down the line, and gives the team the chance to shape the design and inject their own ideas. You want this to happen -- trust me. The best games come from this collaboration. You must be confident enough as a designer to...
Ask for opinions and take other people's ideas on board. Be open and willing to acknowledge better ideas from others on the team, especially ideas outside the design group. This does not mean design by committee, nor should you hold a massive brain storming session with the entire team -- this will just result in a mess and make you seem uncertain and indecisive.
You are the designer; you are being paid to design the game. It is your responsibility, but all the ideas do not have to come from you; in fact, the best games are the combination of all the best ideas from the entire team. If you manage this process properly, whereby you can keep the design coherent yet at the same time adapt good ideas from others into it, you will have much better game DNA.
If your process is insular and exclusive of outside input, you will end up with an inbred design. It may look healthy and whole until released into the wild; then its crippling flaws will become obvious. On the other extreme, if design decisions are made by a committee, you end up with a Frankenstein game that is basically everyone's favorite personal feature from their favorite game forcefully stitched together in a painful and unnatural way. It never works.
Managing that middle ground takes confidence and experience, but if you are designing what you know (as opposed to someone else's idea of fun) it will be easier to navigate this tightrope. And it is a tightrope, because opening the floor to design ideas can be tricky if you are not confident enough about your design and you start to see a lot of people suggesting alternatives.
If you understand what you are trying to achieve, then you will quickly be able to earn the confidence of the team by explaining your decisions and making them see why you made those choices. Remember that people outside of the design team don't spend all their time thinking about design issues, and so they don't have the big picture that you are supposed to have as the designer. It's easy for them to look at a single feature and come up with a "better" idea outside of the context of the entire game system.
This is an opportunity for you, not a challenge to your ideas. This is where you start giving them a hint at how complex and interwoven the gameplay big picture is, and how much you have a grip on understanding it. It's okay to not have the answer to all the questions that come up during development, but you should have a few scenarios, or options, in mind.
This process should be informal. People should feel free to mention ideas to the design team at any time, without any expectations either way. Make them understand that you are comfortable listening to ideas and that you won't consider such a thing a challenge to your work. Be open and friendly about sharing the design, and your job will be much easier. To manage that process well you need to...
Be objective about your own ideas. Just because you are the designer doesn't mean that you are going to have all the best ideas for the game. You will need a lot of help, and if you shut out others from being part of that process, you will lose a massive resource: the accumulated brainpower of the entire team! In order to cultivate that collaborative relationship with the team, you have to learn to tame your own ego. You must be honest about your ideas and those of others.
It's easy to get defensive, as a designer, when you have all the experience and the job title but someone from an unrelated department comes up with something that is frankly better than what you had chosen. You have to be able to honestly admit to yourself first that this is a good idea, and then vocalize it to the rest of the team if you think it fits with the overall game.
It's not going to make them lose respect for you; on the contrary, it will increase their trust in your decisions when they can see that you are being objective and leaving your ego at the door. Vocalizing it also important -- publicly acknowledging the merits and source of the idea is very important to earning the respect of the team.
If you take someone else's idea and secretly stick it into the design, you will have earned nothing but contempt on two levels, first because you don't have the honesty to admit when you are wrong, and second because you are taking credit for someone else's idea. Even if it's not true, and you had no intention of doing either, nothing will tank you reputation with the team faster.
Being able to honestly evaluate the merits of a design idea regardless of authorship is key to being a good designer; there is no way in hell you will ever be able to make 100 percent of the design decisions 100 percent correctly, so listen to the team! Objectivity is also important to the people who pay for all of this...
Respect the business. Game development can be complex because of the uneasy mix of business and entertainment. In some entertainment industries, this marriage is well managed due to decades of experience honing that relationship. Yet there are still spectacular failures in the movie industry, despite over a century of refinement.
Things will not change in game development any time soon either. Technology is one factor; changes in the business model and evolving tastes are others; mainly problems stem from the easy-to-unbalance relationship between the business and the game people.
One way that you, as a design leader, can help maintain that balance is to understand the factors that are at the foundation of your project: the business conditions. This is probably the most important skill you will need to be an effective leader in design. This doesn't mean that you need to get inside the numbers that management deals with; it just means that you should know the lay of land -- the strategy behind your project.
A good tactician understands what the prevailing conditions are at the strategic and logistical level. In dev terms, you should be designing within the budget, within the technology scope, and to the projected release plan. This is tricky; I have seen some designers become more a part of the marketing team than the dev team as a result of being too preoccupied with the sales strategy side of the job.
Don't try to do upper management's job, but at the same time be aware of their plan and expectations on budget, and let them know you understand it. They need to know you are objective as well as passionate. This really comes down to your features should fit the scope, whether it's a $500,000, $5 million, or $50 million game.