1. Revise - Theoretically you now have the first two parts of a game design document: a statement of purpose and a features list. Look them over for any inconsistencies or missing information and fix that if you can, or mark it (I use bright red text) as something that needs to be fixed when you can figure out how.
2. Prioritize - Look through your features list and separate it into Core features that you absolutely must have, and Non-Core features that you like but will not start to implement until the core features are done. You can also re-arrange topics within the features list if you think they are more logical or useful in a different order. For example, perhaps the GUI and game modes section should be near the beginning instead of near the end.
3. Format - Copy your features list and paste it into your document, so you now have two. Remove all but the headings from one. If any of the headings seem confusing, clarify them. Congrats you just made a table of contents. Depending on what kind of word processor or other program you are using to make your game design document, you can go through and make each table of contents entry hyperlink to the appropriate feature.
4. Revise Appendices - Review your appendices - is there stray stuff in there that should be filed into appropriate places in the features list? Are there any things you know you'll need an appendix for that you don't yet have one for? (E.g. list of locations, list of NPCs, list of weapons, list of armor, list of enemy types, list of crafting resources, list of crafting recipes, list of quests...) Make more appendices for those. Rearrange the appendices until they seem to be in the most logical order.
5. Brainstorm - Go through one feature at a time, then each appendix; for each one, add any other useful and relevant information you can think of. The goal is to get the document as complete as you can make it without outside help, before looking for that outside help.
6. Research - If there is some feature you are interested in but don't have much experience with as a player, research what games have that feature. Read about how the feature works in those games, and consider playing one or a few to experience how the feature works. You may do this part first or multiple times if you like.
7. Copyedit - If you have really long or confusing sentences, improve them. If you have really long paragraphs or no paragraphs, cut up your wall of text into more manageable chunks. Spellcheck. Beware of homophones and use of apostrophes. Have you used consistent formatting for headings and lists? The goal of this step is to make your document as readable and polished as possible before showing it to others.
8. Seek Feedback - The kind of feedback you need will differ depending on what role you intend to play in your game's development, and how complete you've managed to get your design document. You may prefer to recruit a co-designer who will add a lot of their own thoughts to the design document before beginning development. Or you may want to hire a consultant, paying them to sign an NDA and give you all the suggestions they can come up with for your design without becoming a part of your team or having any rights to future income from the game. Or you may want to describe either the general outline of your game or a specific problematic area on a public forum to get volunteer feedback. Or you may want to begin development immediately, either by your own efforts or by recruiting or hiring a skilled programmer or artist.
9. Development - Whoever is the most experienced programmer involved with the project will need to use this design document to make a programming plan: Name the languages, libraries, engine, database, etc. to be used, break the core features into proposed code objects, and plan how those code objects will communicate with each other. Whoever is in charge of the story should make sure enough of it has been created to guide the artist(s) in producing art assets appropriate to the story. Whoever has the most experience with GUI design and/or art will need to set standards for the still images, animated sprites, and/or 3D models and textures the game requires, and use this design document to make checklists of all the art assets that need to be created. As pieces of the game are completed you can mark them as completed within the design document, for example by turning the text relevant to them blue or green.
Now, alas, you have reached the end of the help I can give you. If anyone thinks of a topic I have missed or forgotten here, please let me know in a comment. Otherwise, good luck and happy game designing! ^_^
