Documentation for Development teams

Example

'Never assume anything' is probably the most important rule when working in any environment. At akanoodles, we 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.