A Why-What-How Tool for Development and Documentation of Operating Procedures David G. Novick European Institute of Cognitive Sciences and Engineering 4 Avenue Edouard Belin 31400 Toulouse, France novick@onecert.fr ABSTRACT * DSTOP, the Design Support Tool for Operating Procedures, is a relatively simple software tool for support of designers of new interfaces and their procedures for use. DSTOP is based on two complementary models: the documentation coherence maxims and the situated-act model, which distinguishes domain actions from interface actions. Use of the tool involves the writing of operating procedures using a kind of grid, where the operating procedure runs from top to bottom and is divided horizontally into why, what and how elements. The why element represents the operating procedure's goal; the what represents the operating procedure's situated act; and the how represents the interface action(s) required to effectuate the act. The tool has been used to develop prototype operating procedures for computer-based aircraft cockpit interfaces. DSTOP adds new functionality associated with the coherence maxims, including explicit representation of variants of terms, and explicit tracking and display of procedures (and their why-what-how components) in which any of the variants is used. Keywords Authoring tool, operating procedures, rationale, acts, actions, coherence maxims 1. INTRODUCTION Developers of new interfaces, particularly for safety-critical applications such as aviation, do not currently have much tool- based support for creating the content of the procedures for using these interfaces. Ideally, designers would have means to co-develop the interface and its documentation so that the each is consistent with, and informs the design of, the other. Recognizing this need, Aerospatiale Matra Airbus launched a four-year project to provide methods and tools for co-design of interfaces and documentation. At Aerospatiale, interface designers and human-factors specialist work with test pilots, line pilots and instructor pilots in a participatory design process. So as part of this project, Aerospatiale looked to create a new tool to support this process. This paper reports one of the project’s central results. There are tools available for checking compliance with standards for controlled-languages, but these do not really address the issue of what the language is supposed to represent. Tools also support consistency in documentation (e.g., Novick & Juillet, 1998) but this is again more form than substance. And the developers of tools that automatically generate manuals from specifications (e.g., Barth, 1997) do not claim that they produce * Author’s current address: Department of Computer Science, University of Texas at El Paso, El Paso, TX 79968-0518, USA, Novick@cs.utep.edu realistically usable manuals or procedures. The lack of support for the content of operating procedures is due, in large part, to the fact that writing operating procedures remains a craft based on domain knowledge and experience. Methodologies for development of operating procedures, at least in aviation, tend to be at a higher level than the formulation of specific steps. For example, the most prominent approach, Degani and Wiener’s (1997) “Four P’s” model incorporates the organization's philosophy of operations, their business policies, procedures that effectuate the operations consistently with the policies, and the crews’ actual practices on the flight deck. Degani and Wiener’s emphasis on documentation and communication is important because procedures do not have an embodiment outside of documentation communicated to users; they exist only by virtue of knowledge and use. Within the design process itself, however, Degani and Wiener’s model does not offer specific guidance on to write the actual procedures. Similarly, an approach proposed by Drury and Rangel (1996) for reducing automation-related errors in aircraft maintenance and inspection concentrates on identifying error types and opportunities in the procedures. It starts with a set of underlying practices: describing functions neutrally with respect to whether the function will be automated, including users in the design team, and maintaining awareness of technical human factors. With these factors in place, the approach has four steps: listing system functions, listing alternative allocations for each function, listing errors for each function, and system integration. Again, while useful for design and redesign of systems, this approach lacks specific guidance for writing the procedures that make the system work. Accordingly, this paper reports an effort to create a documentation design-support tool that • Supports the co-design process for safety-critical interfaces and their documentation, • Embodies a design model for operating procedures, • Supports consistency in the documentation, and • Encourages use and participation in adaptation. The result is the Design Support Tool for Operating Procedures (DSTOP), a relatively simple software tool to support engineers and writers who develop and document operating procedures. The tool embodies a why-what-how design approach based on the situated-act model (Novick & Perez-Quiñones, 1998). The tool complements the why-what-how approach through support of key aspects of the documentation coherence maxims. And the tool is light-weight (i.e., user-extensible and non-coercive), so it reduces some of the chief obstacles to user adoption. The tool has been used to develop prototype procedures for computer- based aircraft cockpit interfaces.