Designing an effective, intuitive coding layout is not always as easy as it seems.

Often, the choices made in coding selections will color the ultimate work product, so much care and attention goes into crafting specific issue codes and responsiveness instructions that distill various requests into easily understood components. That list will then circulate through the firm, with various stakeholders taking on specific items of concern to their individual focus. These additions are sometimes helpful, sometimes confusing and need to be fully evaluated as part of the protocol and review prep process.

Invariably, someone will notice that there are just a few too many tags. The list is getting long. In an effort to improve things, they’ll start trimming “unnecessary” choices. For many, the first to go is “Not Privileged”. For some reason, the same people never seem to be willing to cut their six different privilege subtags.

Affirmative Tags like “Not Privileged” are an absolute necessity. They help ensure the document receives a full and considered review. Without requiring a call on an important section like privilege, it’s far too easy for a fast-paced reviewer to short-circuit their analysis and move to the next document.

This lesson was driven home on one of my first reviews.

I was reviewing in a converted storage space at with a team of reviewers who had been working at the same large law firm for quite some time. While our instructions were to tag all applicable documents as privileged, regardless of responsiveness, far too many team members let the analysis slide on non-responsive documents. In the firm’s normal coding instructions, priv calls were not required on non-responsive families. This review was being conducted in conjunction with a second firm, though, and the instructions in the matter were different.

Someone removed the “Not Privileged” tag during the setup process. This prevented the platform vendor from requiring a priv call on every document, setting up a dangerous situation where the calls were not being reliably made. It didn’t help that the priv section required scrolling to the very bottom of a very lengthy coding form in a low-responsiveness matter. Sometimes people would remember to tag the priv call if highlighting made it clear that a document required, but many didn’t bother with the non-responsive documents. I fear some may not have remembered to look out for non-highlighted concerns even on responsive docs.

After several productions had been made, an updated request was received. The request was easily resolved with a quick database search (it may have been as simple as “all documents between Person X and Person Y during Month Z”) and the review team had already examined the documents. Without circulating the documents back through review, the search was run and the population bundled into a production. What had previously been a non-responsive population of documents contained several privilege landmines, none of which had been tagged as such. Without the required affirmative call, it was far too easy for the team to miss the (seemingly unnecessary) coding.

Fortunately, the issue was spotted before the production went out. A quick privilege review was conducted and a non-trivial number of documents changed. The result could easily have been far different.

When setting up coding options, fight to keep the affirmative calls, even if they seem redundant or unnecessary to some. If your platform supports, enforce a coding constraint that requires the tag to be applied before moving to the next document. Doing so will improve coding accuracy.