An acquaintance recently messaged me asking for advice on writing game design documentation. Immediately, childhood memories flashed in front of my eyes - pages upon pages of notebooks filled with with meticulously detailed game ideas and mechanical interactions. It was a melancholic image of heaps and heaps of theoretical game ideas that never saw the light of day.
Writing design documentation is like rearranging your paint palette. It is inarguably useful time spent that makes the actual design work easier. However, at some point you need to actually put paint to canvas and make a mess to create your game.
So, keep your writing crisp and to the point.
Break up your documents into digestible chunks. Use an internal wiki or database of notes. Make sure the whole team can access the pages.
Add sketches and reference images where appropriate. Pictures communicate with a glance what an entire page of words may only suggest vaguely.
Allow team members to update the database pages themselves. Let them see who has contributed and who has last edited a page - that way they know who to follow up with for more details.
An active messaging thread is a sign of healthy team communication. Direct messages will always be the fastest way to communicate within a team - don't feel discouraged if people prefer to message first, then look up documentation later.
If you find yourself sending a link to a documentation page in response to a teammate's question, that's when you know it's a useful page of information.
I cracked my knuckles and composed my reply.