Documentation Review (Doc Review) is the process by which artifacts produced during discovery are validated against themselves and each other.
In a previous article, we discussed at a higher level what is done during discovery to ensure quality. We discussed making sure that all of the documentation ‘speaks with one voice’ so that during implementation, there is a clear and concise interpretation of the build.
During Documentation Review, the Information Architecture (IA) is considered the canon build document and serves as the central reference point for all the other documentation. The Creative Brief (CB) is the only other document, as it is legally binding, that can override and/or direct the IA and so the first comparison should be done between these two documents.
Creative Brief vs. Information Architecture
Being as though the CB is a descriptive document, the methodology in which the CB and the IA is compared is using a more definitive approach.
As an example, if the CB mentions an ecommerce component, the IA will identify the various components (fields, machine names, modules, etc.) in detail that are associated with that ecommerce component.
As another example, if user roles have been identified in the CB, they will be thoroughly defined in the IA.
Once we apply this process to these two artifacts, the outcome is a clear understanding of any shortcomings in either document and a more complete IA and descriptive brief as we prepare for the build.
Validation of the IA
Once the CB and the IA have been cross reviewed, you can then validate the IA.
This process is best compared to baking. Many cakes use similar ingredients, flour, baking soda, etc. However, there are many other ingredients for cakes that yield different cakes entirely. You probably wouldn’t put icing on a pound cake for example. The IA identifies all the ingredients for all the cakes that are to be baked, as well as identifies all the cakes themselves that are to be baked.
The IA is structured so that both content types, page types (content types or pages that require unique builds), and user accounts are specifically identified. It also identifies all of the individual components that will appear within the content types and the page types. The development team will then review these, and build the various components and assign them to their proper places.
The internal validation review is done by making sure all of the various page components are properly reflected within the content and page types (cakes) and that the user account privileges are accurately represented. The result of this review is the assurance that all of the components needed to build out the content types, the page types and the configuration of the user access roles have been properly documented.
A documentation review is pertinent to the success of the build as they ensure clarity on what is being built. Because discovery artifacts are potentially drafted by different team members, at different times, it’s pertinent that these reviews be done to ensure document consistency.
