Remember Pavlov's experiments with dogs, demonstrating that they could be classically conditioned? With no negative undertone intended, this classical conditioning can provide a very positive effect to readers when used throughout documentation. What I mean by this is, classical conditioning by way of consistency, so the reader understands a document's layout, structure, formatting, terminology, and design so well, that they unconsciously know what is coming next. Using consistency creates a flow for the reader, allowing them to focus more on the requirements and solution design than trying to understand the flow of the document and how the pieces fit together.

This consistency is sometimes difficult to achieve, especially when multiple people are working on the same project, incorporating their own writing and design styles. This inconsistency can be and should be avoided with a single reviewer, or by creating and adhering to a set of consistency "best practices." The following can easily be used to start creating this set of "best practices" for large teams, or even for a single-BA-shop looking for document standardization:

• Verb Tense
  Some BAs prefer to state requirements with "needs to", while others use phrases like "should support". While either could be argued as the "proper" way to state a requirement, I argue for consistency. No matter how a requirement, an assumption, or a question is stated in a document, the end result should be that all are stated consistently. This consistency helps not only build a flow for the reader, but provides an instant understanding to know if they are reading a requirement, an assumption, or a question.


• Document structure and formatting
  In the documentation we use at our company, when describing our use cases, we restate the requirement at a high-level. We have another section that describes how this use case and subsequent proposed design will affect the business. In a use case summary section, we describe the proposed solution design at a high-level. Lastly, we state the proposed design, following it with assumptions, questions, and metrics. The key is not only verb tense, as mentioned above, but consistency of these sections across all sections in the document. For example, the first section which restates requirements uses the same verbiage used to define requirements. The business impact section uses future tense, since it describes how the design will affect the business in the future. Proposed design sections use future tense as well, since they describe how the design will be accomplished. All sections are in the same order and use the same section heading formatting and spacing, allowing the reader to expect the next section's contents.
  
• Diagram usage, structure, and formatting
  Pictures are worth a thousand words; and so are things like process flows and wireframes. Utilizing diagrams in documentation may take longer to create in the short term but usually save hours in the long run. Inconsistent use of diagrams, their structure, or their formatting, however, should prove more detrimental to the reader's understanding of the documentation. If a mockup of a use case is created for all but one use case, the reader will spend more time wondering where the missing mockup is than understanding the use case. In this case, if some items cannot be visually designed, the reason should be stated in the same location where the mockup would go. If one process flow diagram runs horizontally, create them all flowing horizontally. If a specific color is chosen to represent a system or a process, use the color consistently throughout documentation.


• Terminology and section references
  When referencing existing sections in a document, I generally like to add hyperlinks to the sections. For one, this adds great quick-links to dependent information, but it also breaks up the blocks of text, making the text easier and faster to read. Consistency of both the usage and referencing verbiage is very important here as well. If these links are used, they should be used throughout the entire document, or not used at all. Not using links in places where they are expected by the reader forces them to assume it's not a dependent section. For example, if we have a "Log In" section, and we reference it later as "Log In", and later again as "Log In", the reader will not make the association with the second reference to the main section. In addition, the same goes for the way these references are made. If we make one reference to "Log In" and a later reference to "Log In and Log Out", both which refer to the same section, the reader will assume it to be a separate reference altogether.

Although the above examples provide ways to increase consistency throughout documentation, these are just a few examples to consider. The end-goal is to keep the reader engaged in the purpose of the documentation rather than being forced to understand the flow due to inconsistencies. Although consistency won't provide the classical conditioning to make your clients salivate, you'll have improved your end-result, and leave with a happier client.