Brain-Friendly Principles for Document Design

Whether creating Work-as-Prescribed in our documents, or Work-as-Instructed in our training materials, it is important to consider good cognitive practices. If we start from two principles we quickly can start doing some amazing things.

  1. Organize resources so it’s easy to understand. Reduce cognitive load by breaking information down into small, digestible chunks and arranging them into patterns that make sense to the individual. Always start by giving an overview so individuals know how all the smaller chunks fit together.
  2. Use visuals. The brain has an incredible ability to remember visual images so you must exploit that as you look for ways to reinforce key learning points. Create tools that are primarily visual rather than word-based. Use images in place of text (or at least minimize the text). Use videos and animations to help people understand key concepts.

We can drive a lot of effectiveness into our processes by structuring information to make complex documents more transparent and accessible to their users. Visual cues can provide an ‘attention hierarchy’, making sure that what is most important is not overlooked. People tend to find more usable what they find beautiful, and a wall of text simply looks scary, cumbersome, and off-putting for most people. I am a strong advocate of beauty in system design, and I would love to see Quality departments better known for their aesthetic principles and for tying all our documents into good cognitive principles.

Cognitive Load Theory

Cognitive load theory (CLT) can help us understand why people struggle so much in reading and understanding contracts. Developed by John Sweller, while initially studying problem-solving, CLT postulates that learning happens best when information is presented in a way that takes into consideration human cognitive structures. Limited working memory capacity is one of the characteristic aspects of human cognition: thus, comprehension and learning can be facilitated by presenting information in ways minimizing working memory load.

Adapted from Atkinson, R.C. and Shiffrin, R.M. (1968). ‘Human memory: A Proposed System and its Control Processes’. In Spence, K.W. and Spence, J.T. The psychology of learning and motivation, (Volume 2). New York: Academic Press. pp. 89–195

Structure and Display

Information structure (how the content is ordered and organized) and information display (how it is visually presented) play a key role in supporting comprehension and performance. A meaningful information structure helps readers preserve continuity, allowing the formation of a useful and easy-to-process mental model. Visual information display facilitates mental model creation by representing information structures and relationships more explicitly, so readers do not have to use cognitive resources to develop a mental model from scratch.

Leveraging in your process/procedure documents

Much of what is considered necessary SOP structure is not based on how people need to find and utilize information. Many of the parts of a document taken for granted (e.g. reference documents, definitions) are relics from paper-based systems. It is past time to reinvent the procedure.

The Program Level in the Document Hierarchy

A fairly traditional document hierarchy, in line with ISO 9001 and other standards looks like this:

Document hierarchy

This process tends to support best an approach where there is a policy that states requirements to do X, a procedure that gives the who, what, when of X, and work instructions that provide the how of X, which results in a lot of records providing X was done.

But life is complicated, and there are sets of activities that combine the Xs in a wide variety, and in complicated environments there may be multiple ways to bundle the Xs.

This is why I add a layer between policy and procedure, called the program, which is a mapping requirement that shows the various ways to interpret the requirements to specific needs.

Document hierarchy with Programs

The program document level shouldn’t be a stranger to those in the GMP world, ICH Q11 control strategy and the Annex 1 (draft) contamination control strategy are two good examples. What this document does is tie together processes and demonstrates the design that went into it.

The beauty of this document is that it helps translate down from the requirements (internal and external) to the process and procedures (including technology), how they interact, and how they are supported by technical assessments, risk management, and other control activities. Think of it as the design document and the connective tissue.

The Building Blocks of Work-as-Prescribed

Work-as-Prescribed – how we translate the desired activities into a set of process and procedure – relies on an understanding of how people think and process information.

The format is pivotal. The difficulties we have in quality are really not much different from elsewhere in society in that we are surrounded by confusing documentation and poorly presented explanations everywhere we look, that provide information but not understanding. Oftentimes we rely on canards of “this is what is expected,” “this is what works” – but rarely is that based on anything more than anecdotal. And as the high incidence of issues and the high cost of training shows, less than adequate.

There is a huge body-of-knowledge out there on cognitive-friendly design of visuals, including documentation. This is an area we as a quality profession need to get comfortable with. Most important, we need to give ourselves permission to adapt, modify and transform the information we need into a shape that aids understanding and makes everyone a better thinker.

Work-as-Prescribed (and work-as-instructed) is the creation of tools and technologies to help us think better, understand more and perform at our peak.

Locus of Understanding

Looking at the process at the right level is key. Think of Work-as-Prescribed as a lens. Sometimes you need a high-powered lens so that you can zoom in on a single task. Other times, you need to zoom out to see a set of tasks, a whole process, or how systems interact.

This is the locus of understanding, where understanding happens. When we take this position, we see how understanding is created. Adopting the locus of understanding means going to the right level for the problem at hand. When we apply it to Work-as-Prescribed we are applying the same principles as we do in problem-solving to developing the right tools to govern the work.

We are conducting knowledge management as part of our continuous improvement.

An important way to look is distributed cognitive resources, which means anything that contributes to the cognitive work being done. Adjusting the locus of understanding means that you can, and should, treat an SOP as a cognitive resource. Some of the memory is in your head and some is in the SOP. Work-as-prescribed is a cognitive resource that we distribute, routinely and casually across the brain and our quality system in the form of documents and other execution aids.

Other tools, like my favorite whiteboard, also serve as distributed cognitive resources.

So, as our documents and other tools are distributed cognitive resources it behooves us to ensure they are based on the best cognitive principles possible to drive the most benefit.

As an aside, there is a whole line of thought about why some physical objects are better at distributed cognitive resources than electronic. Movement actually matters.

Taking it even further (shifting the locus) we can see the entire quality system as a part of a single distributed cognitive system where cognitive work is performed via the cognitive functions of communicating, deciding, planning, and problem-solving. These cognitive functions are supported by cognitive processes such as perceiving, analyzing, exchanging, and manipulating.

Cognitive Activity in Work-As-Prescribed

The tools we develop to provide distributed cognitive activity strive to:

  • Provide short-term or long-term memory aids so that memory load can be reduced.
  • Provide information that can be directly perceived and used such that little effort is needed to interpret and formulate the information explicitly.
  • Provide knowledge and skills that are unavailable from internal representations.
  • Support perceptual operators that can recognize features easily and make inferences directly.
  • Anchor and structure cognitive behavior without conscious awareness.
  • Change the nature of a task by generating more efficient action sequences.
  • Stop time and support perceptual rehearsal to make invisible and transient information visible and sustainable.
  • Aid processibility by limiting abstraction.
  • Determine decision making strategies through accuracy maximization and effort minimization.

Driving Work-As Prescribed

As we build our requirements documents, our process and procedure, there are a few principles to keep in mind to better tap into distributed cognitive resources.

Plan for the flow of information: Think about paths, relationships, seams, edges and other hand-offs. Focus on the flow of information. Remember that we learn in a spiral, and the content needed for a novice is different from that of an expert and build our documents and the information flow accordingly. This principle is called Sequencing.

Break information down into pieces: Called, Chunking, the grouping together of information into ideally sized pieces. When building Work-As-Prescribed pay close attention to which of these chunks are reusable and build accordingly.

The deeply about context: How a tool is used drives what the tool should be.

Think deeply about information structures: Not all information is the same, not every example of Work-as-Prescribed should have the same structure.

Be conscientious about the digital and physical divide: Look for opportunities to integrate or connect these two worlds. Be honest of how enmeshed they are at any point in the system.

We are building our Work-as-Prescribed through leveraging our quality culture, our framework for coordinating work. Pay attention to:

  1. Shared Standards – Ways we communicate
  2. Invisible Environments – Ways we align, conceptually
  3. Visible Environments – Ways we collaborate
  4. Psychological Safety – Ways we behave
  5. Perspectives – Ways we see (and see differently)

Principles in Practice

When design process, procedure and task documentation leverage this principles by build blocks, or microcontent, that is:

  • about one primary idea, fact, or concept
  • easily scannable
  • labeled for clear identification and meaning, and
  • appropriately written and formatted for use anywhere and any time it is needed.

There is a common miscomprehension that simple means short. That just isn’t true. Simple means that it passes a test for the appropriateness of the size of a piece of content of providing sufficient details to answer a specific question for the targeted audience. The size of the content must effectively serve its intended purpose with efficiency, stripping off any unnecessary components.

We need to strive to apply cognitive thinking principles to our practice. The day of judging a requirements document by its page length is long over.

Constituents of cognitive thinking applied to Work-As-Prescribed

References and Related Documents in Procedural Documents

It is pretty standard advice that relevant references to other documents should be listed in a separate section of the procedure. The reasoning is that when some standard operating procedures are intimately linked to others – the information contained in more than one document is necessary to complete a task – it is useful to include a cross-reference section in each document. Many also say that this section reinforces the SOP’s authority.

Another fairly common piece of advice is to have this, or another, section in the procedure identify the documents used in the development of the procedure, such as regulatory documents or technical/validation reports.

My take is that neither belongs in a process/procedure (SOP/WI). We should be looking to streamline requirements documents, and these sections are just cruft.

If you have electronic document control systems then cross-references should be handled trough hyperlink. Users are quite comfortable with hyperlinks and will easily navigate between documents.

Listing of regulations and other requirements belongs in a separate design document (ideally part of the document control system), and again add little value to the execution of the document.

There are a lot of so-called “best practices” about documents that stem from the days where everything is paper, and it is okay to move beyond them.

Review of Process/Procedure

Review of documents are a critical part of the document management lifecycle.

Document Lifecycle

In the post Process/Procedure Lifecycle there are some fundamental stakeholders:

  • The Process Owner defines the process, including people, process steps, and technology, as well as the connections to other processes. They are accountable for change management, training, monitoring and control of the process and supporting procedure. The Process Owners owns the continuous improvement of the overall process.
  • Quality is ultimately responsible for the decisions made and that they align, at a minimum, with all regulatory requirements and internal standards.
  • Functional Area Management represents the areas that have responsibilities in the process and has a vested interest or concern in the ongoing performance of a process. This can include stakeholders who are process owners in upstream or downstream processes.
  • A Subject Matter Expert (SME) is typically an expert on a narrow division of a process, such as a specific tool, system, or set of process steps. A process may have multiple subject matter experts associated with it, each with varying degrees of understanding of the over-arching process.

A Risk Based Approach

The level of review of a new or revised process/procedure is guided by three fundamental risk questions:

  • What might go wrong with the associated process? (risk identification)
  • What is the likelihood that this will go wrong? (risk analysis)
  • What are the consequences? How severe are they if this goes wrong? (risk analysis)

Conducting risk identification is real about understanding how complicated and complex the associated process is. This looks at the following criteria:

  • Interconnectedness: the organization and interaction of system components and other processes
  • Repeatability: the amount of variance in the process
  • Information content: the amount of information needed to interact with the process

What Happens During a Review of Process and Procedure

The review of a process/procedure ensures that the proposed changes add value to the process and attain the outcome the organization wants. There are three levels of review (which can and often do happen simultaneously):

  • Functional review
  • Expert review by subject matter experts
  • Step-by-step real-world challenge

Functional review is the vetting of the process/procedure. Process stakeholders, including functional area management affected by the change has the opportunity to review the draft, suggest changes and agree to move forward.

Functional review supplies the lowest degree of assurance. This review looks for potential impact of the change on the function – usually focused on responsibilities – but does not necessarily assures a critical review.

In the case of expert review, the SMEs will review the draft for both positive and negative elements. On the positive side, they will look for the best practices, value-adding steps, flexibility in light of changing demands, scalability in light of changing output targets, etc. On the negative side, they will look for bottlenecks in the process, duplication of effort, unnecessary tasks, non-value-adding steps, role ambiguities (i.e. several positions responsible for a task, or no one responsible for a task), etc.

Expert review provides a higher degree of assurance because it is a compilation of expert opinion and it is focused on the technical content of the procedure.

The real-world challenge tests the process/procedure’s applicability by challenging it step-by-step in as much as possible the actual conditions of use. Tis involves selecting seasoned employee(s) within the scope of the draft procedure – not necessarily a SME – and comparing the steps as drafted with the actual activities. It is important to ascertain if they align. It is equally important to consider evidence of resistance, repetition and human factor problems.

Sometimes it can be more appropriate to do the real-world test as a tabletop or simulation exercise.

As sufficient reviews are obtained, the comments received are incorporated, as appropriate. Significant changes incorporated during the review process may require the procedure be re-routed for review, and may require the need to add additional reviews.

Repeat as a iterative process as necessary.

Design lifecycle

The process/procedure lifecycle can be seen as the iterative design lifecycle.

Design Thinking: Determine process needs.

  • Collect and document business requirements
  • Map current-state processes.
  • Observe and interview process workers.
  • Design process to-be.

Startup: Create process documentation, workflows, and support materials. Review and described above

Continuous Improvement: Use the process; Collect, analyze, and report; Improve