Everyday Usability 8

I was discussing quality system documentation with a colleague yesterday when it dawned on me that usability can (and should) apply to quality systems. An example I later identified is shown below:

Acceptance = No... Let's think about that for a minute. Typically, when a person is looking for acceptance - Will you marry me? No. Can I hang out with your clique? No. Am I tall enough to ride any rides? No. - the response is expected to be "Yes", not "No". Recall our second post about the DoubleWide Grill's kitchen doors. The greatness of their door signs was that it used strongly identifiable language (Yes and No) to instruct servers to enter one door and not the other. Why, then, would someone decide to place "Acceptance = No" into a quality system document? The mind associates "No" with being unacceptable, leading to incorrect documentation. In addition, it is quite easy for the author to change the phrasing of the question such that "Acceptance = Yes".

This topic takes us into the theory of quality system development. An auditor once noted that it is always fascinating to observe how humans come up with a variety of solutions for the same set of regulations. And that is the beauty of quality systems - many different business practices can be molded to be compliant! During a project, someone stopped me when trying to map a process, stating "I'm not really comfortable with this. Typically, quality just tells us what we need to do and we take care of the rest".

The misfortune of that previous statement is that the quality system architects clearly did not consider the users as part of the system. For the system to work effectively, the quality system should represent a marriage between the quality system documents and their users. If they do not interact well, audit findings will abound. Sure, a company could write the regulations word-for-word into their procedures, but without considering the scope the system according to the users needs the system will fail.

An example? ISO 13485:2003 presents design controls as a very segmented, rigid, bucketed process. In reality, (as presented so well in the FDA's CDRHLearn courses found here: http://www.fda.gov/Training/CDRHLearn/ucm162015.htm) the phases are seen more as bell curves, interacting with the other parts of the design process. If a document author wrote the procedures without considering their use and context (i.e. Design Transfer will begin in some form when establishing the Design Inputs and Outputs), the system will fail to be efficient and may potentially be seen as nonconforming. While nothing requires quality system document authors to consider the users, the acknowledgement of usability in writing the procedures will result in a smoothly operating quality system with less frequent findings during internal and external audits.

-RTK