‘Never assume anything’ is probably the most important rule when working in any environment. I often work with remote development partners and make a point to over-communicate and provide clear, unambiguous documentation to streamline delivery and keep costs down.
We like to annotate our designs with four critical pieces of information:
What is it? Usually, a brief description of the thing so it can be easily identified.
What does it do? An explanation of its functionality and range of operations
What happens after I’ve done it? The description of what occurs after the event, process, or result
Does the ‘system’ need to send something or get something? Technical detail of where information is sent or obtained from, such as text from a CMS, information sent to a database or elements from repositories
Below are some examples of the type of documentation we produce minus the data specification sheet, which details data points.