Lean Documentation 5

There are a number of different aspects to data recording and formatting. Each is considered separately below.

Overall structure

Structure is important for two reasons:

• it helps your users find their way around, and
• it can help to reduce the number of signatures required in the document.

The structure of your MPR is necessarily related to the structure of your MPI; indeed, the two may be combined as one document. If your instructions are just that – a list of instructions with no grouping or subheadings – it’s difficult for your users to locate the particular instructions they require. They may well end up jumping from one instruction to another very similar one, thereby skipping or repeating a set of instructions.

If, however, you group your instructions into ‘activities’ with a set of steps within each activity, this a) makes life a lot easier for your user and b) allows each activity to be signed off as a whole, rather than signing off each individual step. Note that significant individual steps should, however, be signed off individually.

For example, you might have an activity headed ‘Charge solvent to reactor’. The steps within this might detail valve switching, flow rate setting and so on. If this is a standard process with nothing significantly different from any other solvent charge, it could be signed off with a single signature for the entire activity. If, however, the vessel temperature is critical, you would need an additional signature for a step at which the temperature is recorded. (If this is a filed parameter, you would also need a second-person check.) Generally, any recorded data should have a signature attached to it (although there is also scope for grouping these, to a more limited extent).

Page layout and spacing

Page layout does require some thought. Here are some dos and don’ts.

Do:

• Be consistent. We subconsciously associate a particular format with a particular type of information, and you can capitalise on this to reinforce certain types of information. For example, you can highlight filed parameters in a certain way.
• Put key information in headers and footers, but don’t overdo it. The point of headers is that the user has instant access to information about the document (product name, processing stage, page number etc), but this information is instantly less accessible if it is cluttered. Putting the information in a table with all borders also adds clutter – keep it clean!
• Line up your data entry and signature points. It is essential that no data entry points are overlooked, either by the operator or the reviewer. They are far more obvious if they are all right-aligned, for example, rather than hidden within the text. Some sites even go to the extent of adding a grey tinted background to all areas where data entry is not required, so that the entry points stand out in white.
• Use spacing to your advantage. Firstly, add space between the lines of text (Format, Paragraph, Line spacing in MS Word). It makes a big difference to readability, and reduces the chance of your users jumping lines when reading across. Then, use space to group and separate chunks of information. So put more space between activities that between steps within an activity. Add space between bullet points so that they stand out. Put more space above a heading than below it so that it is obvious that the heading ‘belongs’ to the text following it. And use more space around higher-level headings. All this helps to structure your document, and, subtle though it is, does improve usability markedly.

Don’t:

• Fully justify text. This creates uneven spacing between words and makes it ‘jumpy’ to read. Simple left-justified text is easier on the eye.
• Overuse UPPER CASE. When we read, we read the shape of the word as much as the shape of the letters. Upper case words all have the same shape, and reading becomes significantly slower.
• Sacrifice layout just to reduce the length of the document by a page or two.

Data entry

We’ve already mentioned the desirability of aligning data entry points, but of course this won’t always be appropriate. There will always be some cases in which a table or other format is the best way to record a set of data. In this case, consistency again becomes the key. Tables recording similar sets of data should be laid out in the same way and look the same (same border/shading format).

The other rule about data entry is that you should do as much as you can for your user. If a calculation is required, lay it out neatly in the master record, with obvious spaces for the data and subsequent results to be entered. (Calculations should also be second-person checked.) Here are some more examples:

• If the number of significant figures/decimal places is important, make a space (such as a box) for each figure expected. Include dots, dashes, spaces, etc to match the instrument read-out.
• Where the operator has to select an option (such as Pass/Fail, Yes/No, a.m./p.m. etc), use tick-boxes. Asking the user to circle or delete one option is less clear and prone to mistakes.
• Highlight key entries (such as filed parameters). Again, do this consistently, so that the operator knows, for example, that all critical process parameters are in bold blue text, for example.
• Include limits for parameters, so that the operator can see immediately if s/he is required to take action. So, if asking the operator to record the batch temperature, put the acceptable temperature range in brackets.

These are just some ideas to improve your manufacturing documentation. In all of these, the focus is on ease of use, to reduce both the amount of time wasted and the error rate.