We’ve all created some sort of documentation in order to have a concrete representation of our thoughts and ideas. A physical piece of paper we can use to communicate designs and solutions in order to integrate them into the conversation of a project. Unfortunately, not all documents will have you along to explain the intricacies of your thought process or the brilliance of your design. Some documents end up traveling off-site to remote colleagues or the client.
This is when the written word becomes vitally important as it is substituting for your verbal explanations. To assist you in improving your next set of design documents, here are two ideas to start you off (more to follow in a later post):
Establish a purpose
Why is this document being created? Is it to get funding for a project? Specifications for a development team? What story are you going to tell?
Once you know the document’s purpose it’ll become much easier to identify the necessary information and the necessary sequence in order to tell that story and give it coherence.
In addition to the document’s focus, it’s a good idea to give the reader context, i.e., how this document fits in with the overall process. Providing a brief introduction is enough to establish the context. Or, if this document is a continuation of information learned earlier in the process, summarizing previous documents or their pertinent sections establishes a relationship between what was and what is.
Know your audience
What do they want to get out of document? What do they need to help them render/get approval for a decision? Answering these questions sets expectations on both sides and assists you in determining the types of information to be included.
Consider the corporate culture/methodology since it may determine the document output. Is a .pdf acceptable? Do they need a Word document? Do they use wiki pages for their documentation? Does the document need to conform to their internal process? It’s best to get this knowledge up front rather than learning about it 5 minutes before the deadline.
Write to your audience. If technical jargon is their native language, then by all means include it in your writing. However, don’t include jargon just for the sake of having it there. Any jargon used, whether technical, business, etc., is used to support the purpose of the document, not to impress the reader.
Considering these questions before starting your document establishes the document’s goal. Once established, it’s much easier to create the document’s framework and content. More on this later.
