You’ve seen it. The plodding step of the programmers, the downturned eyes, the life seemingly sucked out of them — the telltale signs that mean only one thing: it’s time to read the design document. While writers naturally have an easier time of ploughing through copious documents, an e-mail I received from a repeat client reminded me that a little help can go a long way.
After indicating where to find the documentation, our client made a number of fabulous suggestions. While his suggestions may seem like additional reading for the weary, a few sentences more can make the difference between a smooth collaboration and a bumpy one.
1. Indicate what to read first. While reading from beginning to end may work for some people, it’s nice to know upfront a good starting point. It’s a good way to emphasize what is most important to you and your writer.
2. Suggest a natural work flow. While each person may work differently, suggesting an order for completing tasks helps the writer better understand your vision and helps him/her focus on what to read in the documentation.
3. Walk through the entire project. Sometimes neither the documentation or contract accurately delineate what the project entails. Furthermore, even when working with a repeat client or known colleague, a brief runthrough of the project and the supporting documentation is helpful to avoid unpleasant surprises. For example, if a writer is accustomed to working with a team on a project, he should know ASAP if he will now be working alone.
With these suggestions, your next contractor or colleague can attack documentation with a renewed purpose. What successes have you had in guiding others through your documentation?
Chris Peterson’s favorite line of game dialog came from Mortal Kombat for the arcade. More Guess that Game Dialog to come!